Lecture 13
----------
Godot categorizes its elements differently than other game engines
- nodes & scenes vs much more complex divisions (entities, prefabs, worlds, etc)
The more complex divisions come from entity-component architectures, or
entity component systems architectures
Games care about performance
cache-friendly code?
Modern computer architecture, memory
- CPUs are MUCH faster than RAM
- thus, we have caches: faster memory between RAM and the CPU
- different kinds, L1, L2, L3
- L1 is smaller and faster than L2
If your code is going to go fast, it should be cache friendly
Classic object-oriented code (can be) very cache unfriendly
(ECS is a path to cache friendly code, basically)
How do you use cache most effectively? Key insight:
- data is loaded into cache in bulk
- request one byte, get 64 bytes or more (cache lines)
How cache behaves is a black box
- very complex
To get good cache performance, you want spatial and temporal locality
T: if x is used, it is likely x is used again sooner rather than later
S: if x is used, y is used where y is close to x
Imagine a for loop traversing an array
- while accessing element 1, elements 2, 3, and 4 may be loaded into cache when 1 is loaded
- so access to 2, 3, and 4 will be much faster <- spatial locality
- but, if you accessed the array randomly, will have to go to main memory
much more frequently
Main memory has high latency but also high bandwidth
- takes a while to get one byte, but gets lots of data for each access
- you never just get one byte
Never underestimate the bandwidth of a truck or a boat with LOTS of hard drives (spinning or SSD)
- but its latency is crap, a week to get the first byte
bandwidth is average bytes per second, latency is time for first byte (or roundtrip cost)
latency matters for games, i.e., how long does the system take to respond to pressing a button
- measure of responsiveness
Classic objects are, from a storage point of view, just structs
Imagine doing an operation on lots of objects
- only need a few properties of each object
- this is very cache-unfriendly, because you aren't using most of the object
- but whole objects will be put into cache
- load 512 bytes but only use 16
- waste of bandwidth
ECS is an architecture to turn this around to make it cache friendly
(assuming you do operations on small portions of objects at once)
instead, split up the objects into components, and keep components in arrays
- so, if you loop through components, you'll be cache friendly
Unify components using "entities", i.e., a unique ID to group togother components
Instead of an object with properties ID, A, B, C, and D, instead you have
- array of A's
- array of B's
- array of C's
- array of D's
- each element of the arrays also has ID
- or use the array index as the ID
So, looping through A's is very fast
The "system" part is the code that processes each property
- i.e., physics system just deals with physics-related properties,
- because they are stored separately, can be accessed all at once,
fast, without looking at the other data associated with the entities
Godot doesn't do this because it isn't so simple for developers
- less generality
But its objects are at a higher level, really just an interface
Underlying servers can be cache friendly as you like
- e.g., physics server
Really, ECS is a pattern of has-a OO, rather than is-a OO (inheritance)
Note that JavaScript is very has-a OO (why it has no real classes)
ECS is a game dev specific pattern to "data oriented" code