droqen's forum-shaped notebook

Blizzard's Timothy Ford explains how Overwatch uses the Entity Component System (ECS) architecture to create a rich variety of layered gameplay.

~ 1:31

Quotethe idea that ecs architectures can manage complexity on a quickly growing code base was discovered over three years of development

this is very promising! i like how ford speaks quite straightforwardly and honestly about the motivations that went into the usage of an ECS... he calls it a 'grass is greener' move, but says that they "did 'audit' a prototype first," and i love a good prototype. great.

he shows 'systems' and 'components' around 5:30, it's cool to see

~8:00

Quotewhat are the conceptual advantages of this separation between behaviour and state
. . .
imagine these are the cherry blossoms in your front yard. these trees in your front yard mean something subjectively different to you, the president of your HOA, a gardener, a bird, a property tax assessor, and a termite.

each observer sees different behaviour in the state that describes that tree; that is, the tree is a subject that is dealt with differently by various observers

yes, aligns well with my perspective brain thing (no name for this yet)

~8:56

Quoteit turns out it's much easier to describe all the behaviours of a tree when you compartmentalize individual behaviours by their subjective perceptions and this is also true of game objects.

UTILITY FUNCTIONS
- neither system nor component, but a common function that accesses components. there are roughly two types::
-- high usage, simple/pure, like 'are these two entities enemies'
-- low usage, complicated, like 'advance player movement one tick'
[~17:06]

this is a good rule of thumb! i can see how we 'high usage AND complicated' is a red flag for something that we should solve

talking about reducing coupling. great

~20:29

Quotewhen a lot of large side effects can be invoked from multiple different call sites programmers tend to spend a lot more mental energy maintaining a cognitive model of how the code works. that's what code complexity is. you want to avoid that.

solution being presented is making these sort of 'pending' actions rather than doing the side effect heavy actions right away in the function call. then there's a system or behaviour which 'churns through the array of pending [actions]' and handles all the logic of a complex behaviour in one place at one time, rather than many places at any time

oh cool, Ambient is doing the tuple thing Ford says he wishes they did (~44:15 or so)

see ECS (https://ambientrun.github.io/Ambient/reference/ecs.html?highlight=query#systems) on queries

ah the reason for Utils is that systems shouldn't call each other.

"ECS is glue. everyone is gonna touch the glue. define your terms of engagement."

set rules for how we relate to each other.

love it