Question

I’m building a simple 2d game,and I’m wondering if some better coders than I can suggest a good way to design its basic architecture.

The game is pretty simple. There are many types of units on the screen which shoot, move, and perform hit detection. The screen zooms in and out, and there is a menu UI bar on the side of the screen.

The architecture I have now looks like this:

Load a "stage".
Load a UI.
Have the stage and UI pass references to each other.
Load a camera, feed it the "stage" as a parameter. Display on screen what the camera is told to "see"

Main Loop {
if (gameIsActive){
   stage.update()
   ui.update()
   camera.updateAndRedraw()
   }
}else{
   if (!ui.pauseGame()){
       gameIsActive=true
   }

if(ui.pauseGame()){
   gameIsActive=false
}


stage update(){
Go through a list of objects on stage, perform collision detection and "action" checks.
objects on stage are all subclasses of an object that has a reference to the stage, and use that reference to request objects be added to the stage (ie. bullets from guns).
}

ui update(){
updates bars, etc. 

}

Anyway, this is all pretty basic. Just curious if there is a better way to be doing this.

Thanks,
Matthew

Answer 1

There are as many ways of building main loops as there are stars in the sky! Yours is perfectly valid and will probably work fine. Here are some things you might try:

• Where do you read the controls? If you’re doing it in your “ui.update” and then responding in your “stage.update,” then you’re adding a frame of lag. Make sure you do “read controls -> apply controls -> update gameworld -> render” in that order in your loop.

• Are you rendering using a 3D API? A lot of books tell you to do something like this when you render (using OpenGL-ish pseudocode):

  glClear()          // clear the buffer
  glBlahBlahDraw()   // issue commands
  glSwapBuffers()    // wait for commands to finish and display
  

  It’s better to do

  glSwapBuffers()    // wait for commands from last time to finish
  glClear()          // clear the buffer
  glBlahBlahDraw()   // issue commands
  glFlush()          // start the GPU working
  

  If you do it that way, the GPU can work on drawing the screen at the same time the CPU is updating the stage for the next frame.

• Some game engines continue to render frames and accept some UI (for example, camera controls) even when the game is “paused.” This allows you to fly around a paused game world and see what’s going on offscreen when you’re trying to debug. (Sometimes this is called “debug pause” as opposed to “real pause.”)

• Also, lots of game engines can “single-step” (run one frame, then immediately pause.) That’s very handy if you’re trying to catch a bug that happens on a particular event.

Hope some of that is helpful – it’s just the random thoughts I had looking at your code.