Is a sequential update method really acceptable and is there a sane alternative?

Question

A sequential update method is the update method pattern (e.g. as described here) where all game entities have their update methods called sequentially, even if this means the order of the entities ends up impacting the end result.

This has two obvious downsides (simplified, of course):

1. Order matters, which also makes its results technically incorrect (since you're meant to be simulating simultaneous action).

2. Because it is sequential it can't be parallelized very easily.

Simplicity is always good, and it really does shine on that front. Still, is it really acceptable? Do real-world games actually use this?

As far as finding a more acceptable solution (which thus far I haven't): The previously linked article mentions Double Buffering as a possible solution, and most alternatives I've thought up thus far seem to boil down to some form of that.

Based on my own research and experimentation, alternatives to the sequential update method have problems of their own:

1. Simple double buffering isn't enough in practice. Changes from multiple sources end up overriding each other, so some way to cumulate them is needed (incrementing a value in the next buffer instead of just writing to it). At best this means a tiny bit of extra complexity, at worst it ends up being order-dependent again.

2. Complexity spirals out of control. Say you seperate out the physics into its own series of order-independent updates (e.g. move entities, check collisions, adjust positions), it quickly follows to do the same thing for every mechanism, which ends up becoming unmanageable.

Physics seem to want to be order-independent the most, though - and maybe I just haven't looked in the right places - I wouldn't know of good way of seperating physics from other updating logic. I've been going in circles on this for a while now. Maybe I'm missing something really obvious here.

My problem boils down to how to deal with update ordering. More specifically, is there a way to structure a game update that is order-independent (and parallelizable if possible) that doesn't drastically escalate complexity? If not, is there some reasonable middle ground? E.g. doing only the physics in a seperate order-independent update and everything else in a naive order-dependent sequential update.

Answer 1

Still, is it really acceptable? Do real-world games actually use this?

Absolutely. Almost every game does, in some fashion.

Only simple games will actually put "every object" into a single list and update that in one big go. As you (and the book) notes, that can scale poorly, and doesn't handle some things, such as physics, that are going to want to deal with the simultaneous interactions.

The GPP book is describing patterns at a conceptual level, not documenting implementation (except when providing a specific implementation as a simplified example). Real-world games do use the described method all over, but often in slightly different, more-specific ways.

For example, most games will put objects into buckets based on object type (actors, physics bodies, particle systems, renderables). The buckets will be processed sequentially. Within each bucket, objects may be processed sequentially. Both the objects and the buckets are using the "update method" pattern, but at different levels of abstraction.

In cases where order doesn't matter, the pattern is fine. In cases where it could (like physics), variations on the technique are used. Concerns about parallel updates can be handled by sorting the objects as well, either into independent "islands" within an above-described bucket or because one knows that the update of two different buckets can be done at the same time because they don't depend on one another.

But all of those are built upon the basic idea of "telling each object in a set to process one frame of behavior." The pattern is just the name we give the basic shape of that solution.

I haven't seen a good way of seperating physics from other updating logic. Do you do physics first, then everything else? Or the other way around? Do you do some things before physics and some after?

Generally input drives some game logic which may drive physics which may drive additional game logic which drives rendering. You can do some (or all) game logic before physics, or after, or a combination of both. Each approach produces slightly different results; whether or not it matters depends largely on the nature of the game and what game systems are in there, doing stuff.

It's true that all objects don't actually get updated at the same time. But it doesn't matter: the user does not see the results of that update until the frame is drawn, at which point all objects are updated, so it looks like they were all updated at the same time. This is generally good enough.

I've been going in circles on this for a while now. Maybe I'm missing something really obvious here. Eitherways any help would be appreciated.

It seems to me like you're just stuck overthinking it. It's not a perfect system, it's true, but it's generally good enough that it works. Do you actually have a specific problem a sequential update is causing you, in your game? There may be a solution for it -- and if you asked a question specifically about that, I'm sure you'd be able to find people here who could help you with it. But if you're just worried about the abstract, theoretical idea that the technique has downsides, I'd try to push past that. All techniques will, and accepting that -- learning to pick which downsides impact your specific game the least -- is part of the whole process of making games.