hi all.

i've been working on a framework similair to Britt L. Hannah's article on object oriented design (link), and there's one thing that bothers me a bit.

first, a side question that directly builds up on the main one.
in what order do the different parts of the game's logic have to update, and what are they? i'm talking about input > AI > movement/physics > collision > what else? > animation? i've searched the forum and tried googling, but i don't know how to phrase my search to find what i'm looking for.

the part the bothers me about the article mentioned is that it proposes all entities have a list of their possible and current actions, and when an entity is updated, all it's current actions are executed. problem is, entities are updated in sequence, and so their actions are updated in sequence, but in the wrong order relative to other actions, so you get an action update order like this:

e1.input > e1.AI > e1.physics > e1.collision > e1.(whatever else it has) > e1.animation > e2.input > e2.AI > e2.physics > e2.collision > ... > e2.animation > e3.input ... etc.

how big a problem is updating actions "intertwined" like that, where you do collision of entity2 before physics of entity3? isn't that a big flaw of the proposed design?

i appreciate any comments or thoughts.

The general order of things is input -> update -> render.

You can obviously break that down as required input -> update AI -> update movement/collisions ->update animations -> render etc.

I would personally have all the entities update input, then AI, then physics etc - I can't see the advantage to updating all for 1 entity, and then the next, I can only see it causing major problems... did the article mention why they recommend this approach?

no, the article is relatively generic on the subject, it mostly just proposes an idea without specific implementation details.
what i was wondering about was that breakdown. obviously you have to do movement before collision, animation last (because animation state could change in any of the steps before), but all the inbetween stuff is what i'd like to know. what are the dependancies inside the update method ? or are the only important ones movement/physics, collision and animation, and everything else is in between those ?

Well, I haven't read the article, but I think when it mentions an entities possible actions, it goes more to decision making, entities do not directly check collisions, it would be terribly inefficient.
The order usually goes Input - > decision making - > game logic and events - > collision / physics - > animations / graphics pre-render process - > render


However this is the rather ideal order and it very much depends on how these systems are implemented in the engine and libraries in use, if you are doing it from scratch I would recommend following this order, however truth is since this order is a cycle, it isn't such a big deal which action takes place first, I've seen engines that do graphics pre process first and then process input and so on.

The "all entity's current actions" suggests the author is considering a multiple script or behavior structure, like unity uses for instance, in which an entities actions are ruled by multiple objects with rather simple behaviors that create a composed larger behavior, so you must update "all the entity's current actions" on game logic update