In most game architectures I have seen, you typically have two main "phases" - Update and Render.
During the Update phase, you do all of your game AI, animation, input handling - basically, do anything that is going to change the state of the game over a single frame. By the end of the update, you want everything to be where it is supposed to be for drawing the frame.
During the Render phase, you want to take all of the objects in the game and draw them where they are supposed to be on that frame. Ideally, during the Render phase, absolutely no changes are made to the game state. This is fairly important, because sometimes you want to render exactly the same scene multiple times - if the game is paused, to generate shadow or reflection maps, etc.
So far this seems relatively straightforward, but things are not always that easy. In particular, to synchronize AI with physics, the order that things happen in during the Update phase can be critically important. To make sure things happen in the right order, I tend to break the Update phase into several sub-phases:
- Update - called once per frame
- Process input
- Do animation
- Apply forces to physics objects
- If the game object transform does not match the physics transform, forcibly move the physics object
- PhysicsStep - may be called multiple times if frame time is greater than physics step time
- Called before every physics step
- Apply forces that vary based on object position / velocity
- You may get collision callbacks during the physics simulation
- Called after every physics step
- Limit motion, velocities
- Respond to any collisions you received during the PhysicsStep
- Update game object positions from the current physics positions
At this point, hopefully you have everything where it is supposed to be and can give the Rendering phase the most up-to-date positions for all of your objects and are ready to get on to the next frame's Update.