Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Is there a commonly-accepted general approach to the order of processing logic updates?

My current 2D platformer has objects that implement different concerns, including the following:

  • Notifiable - can be event-driven and scripted
  • Collidable - can interact with solid tiles (eg NPCs)
  • Intersectable - exists in 2D space and can intersect with the player (eg doors)

In general the order of events in a game loop is:

  1. Get input
  2. Act on input and update stuff
  3. Render

I'm not sure what order to do things in point #2. I've concluded moving things like moving platforms that the player can stand on first is a good idea, but I don't know when to consider scripting. The scripting in my game can give NPCs behaviours (walk between here and there), suspend player input for 'cutscenes', show dialog screens, and move the player to a new level.

share|improve this question
    
I'm thinking after render you put an extra step which checks if anything didnt get rendered or done. Just a check so that something else doesnt break. –  Exikle Sep 19 '13 at 3:28
add comment

1 Answer

up vote 5 down vote accepted

You seem to have a handle on this already.

My current 2D platformer has objects that implement different concerns, including the following:

Notifiable - can be event-driven and scripted Collidable - can interact with solid tiles (eg NPCs) Intersectable - exists in 2D space and can intersect with the player (eg doors)

Intersectable - exists in 2D space and can intersect with the player (eg doors)

Separating entities by concern this way will go a long way to figuring out step #2.

The simplest answer to what goes into step #2 is it depends. You may have other steps in there that deal with networking, or streaming data, auto-saving, et cetera. But that kind of an answer doesn't help, either.

I've concluded moving things like moving platforms that the player can stand on first is a good idea, but I don't know when to consider scripting. The scripting in my game can give NPCs behaviours (walk between here and there), suspend player input for 'cutscenes', show dialog screens, and move the player to a new level.

You already have an answer to this question. Your separation-by-concern method can be used to separate individual script actions into their own queues, and be processed at appropriate times.

NPC scripts like walking can be processed at the start of the frame to give their usual "update" cycle something to do. Any entity-changing script can be integrated into the overall cycle in this manner. Where you do it (start of frame, end of frame) is up to you and what works best for your cases.

For the script actions that stop the game, like playing cutscenes or moving the player to a new level, the sensible thing to do is let the frame play out, and process them at the end of the frame. Do any resource clean up/loading and carry on from there.

The end effect is that you construct an API that the script consumes, and the surface of that API is a scheduling mechanism for the the actions that your loop will execute at appropriate times. This allows you to easily decouple script execution and game execution.

Keep it simple and integrated into how your loop is structured. Make the fact that it's coming from a script be an irrelevant part of the process. Don't let it dominate your game cycle.

share|improve this answer
    
Thanks for a very insightful answer - much more thoughtful than I was expecting! I like the scheduling idea. Maybe some sort of 'Game Event' queue that scripts add to, and then the main loop consumes at the start/end of each tick, thereby giving all active scripts the chance to finish. –  Deejay Sep 19 '13 at 8:04
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.