Skip to main content
added 275 characters in body
Source Link
Sean Middleditch
  • 41.9k
  • 4
  • 90
  • 133

You technically will always want a continuous loop. What you may consider is making that loop wait for user input events before redrawing the screen or processing game logic.

If the game is not real time and doesnt need animations to always be playing, it's absolutely a good idea to be event driven.

(Update for clarity): Note that by event driven I mean that the loop should call to the platform's "block and wait until an input message occurs" API. Not sure what that is on Android. On many platforms, it means calling a "Get" function rather than a "Poll" function.

You technically will always want a continuous loop. What you may consider is making that loop wait for user input events before redrawing the screen or processing game logic.

If the game is not real time and doesnt need animations to always be playing, it's absolutely a good idea to be event driven.

You technically will always want a continuous loop. What you may consider is making that loop wait for user input events before redrawing the screen or processing game logic.

If the game is not real time and doesnt need animations to always be playing, it's absolutely a good idea to be event driven.

(Update for clarity): Note that by event driven I mean that the loop should call to the platform's "block and wait until an input message occurs" API. Not sure what that is on Android. On many platforms, it means calling a "Get" function rather than a "Poll" function.

Source Link
Sean Middleditch
  • 41.9k
  • 4
  • 90
  • 133

You technically will always want a continuous loop. What you may consider is making that loop wait for user input events before redrawing the screen or processing game logic.

If the game is not real time and doesnt need animations to always be playing, it's absolutely a good idea to be event driven.