Game Loop Question

Hey everyone,

I’m working on a space strategy game that will be run using a rather simple game loop (or, you could say, an extremely primitive game “engine”). This game loop will involve multiple screens. When the program begins, an Introductory Screen will be displayed with the following options: New Game, Continue Game, Load Game, and Exit. The Introductory Screen will be an instance of a class that extends JPanel. For right now, only New Game and Exit will work. Upon pressing the New Game button, I want the Introductory Screen object to disappear (i.e. have its memory resources freed up) and a New Game Screen to appear (i.e. an object of the appropriate class be created). This screen will contain options for the new game (such as number of stars, number of players, etc.). There will also be a Begin Game button that will dispose of the New Game Screen object, and generate the game universe desired by the user. I’m hoping to do all of this from a main game class. So my question is, given what I have described above, what would be the best way to implement it in Java? I’m mainly talking about handling the screen object creation/destruction. If I have been too vague in this post, please let me know and I will try to be more specific

Thanks,
Rob

[quote]Hey everyone,

I’m working on a space strategy game that will be run using a rather simple game

So my question is, given what I have described above, what would be the best way to implement it in Java? I’m mainly talking about handling the screen object creation/destruction. If I have been too vague in this post, please let me know and I will try to be more specific

Thanks,
Rob
[/quote]
Two choices:

(a) Do all the Swing stuff first with Swing events, then dispose it all and go into your real game loop which will be an active graphics render/flip loop.

(b) Do it all in a game style render flip loop and write your own menu handling code with menu images painted in a paint prgoram.

Option (a) might be easier and take less art. Option (b) is what most games do because it provides pixel-level control over what the user sees.

Hey Jeff,

Thanks for your reply!

Currently I am using JButtons to go from one screen to another. If I stick with that, then I would need to use Option (a). The main game itself also uses Swing components right now, however. Would it be better to change this?

I figure it wouldn’t be too hard to go with Option (b), have every screen be a pre-made image file, with “buttons” in the form of picture areas that change color when you move and/or click the mouse on them. Am I right here?

Finally, I think my code so far is implementing pretty much what you describe in Option (a). However, there is a problem when I run the program. Right now, I have it set to load up an introductory screen first, which contains a “New Game” JButton. Upon pressing that button, the intro screen is disposed of (via scope), and a new game screen is loaded. This screen contains a “Begin Game” JButton which does nothing right now, but will be used to actually generate a new game. What happens is this: the program works fine until I press the “Begin Game” button on the new game screen, and then the introductory screen is partially re-drawn! I don’t know how this can happen – the intro screen is no longer supposed to exist! Do you know what’s going on here? I can send you the code if you’d like.

Thanks again!

  • Rob

[quote]Currently I am using JButtons to go from one screen to another. If I stick with that, then I would need to use Option (a). The main game itself also uses Swing components right now, however. Would it be better to change this?
[/quote]
Likely yes. unless this is a very slow paced game (turn based or puzzle variety) I think you are likely to find that Swing will give you neither the performance nor the control to do things like
animate smoothly.

Yep. Typically game developers either draw a background, and button art they BLT ontop of it or they draw two complete images, one with buttons up and one with them down. They then BLt pieces of the buttons down one over the buttons up one as necessary.

I’d need to see the code, My guess is that you are managing to use a peice of video memory that still contains data from the previous image and hasn’t been over-written.

Are you clearing that panel or whatever the screen is?
]

Actually, it is a turn-based game.

I just got Developing Games in Java by David Brackeen. Very good book so far, with many reusable code examples. One such piece of code is for a simple game loop. However, it seems that what is provided in the book is geared for games that are constantly being re-drawn, such as platform games. So should I still implement an animation loop in my turn-based game? If I don’t use one, is there a way to draw, say, a static background image only once?

Also, I’m switching from making my game a windowed application to making it a fullscreen one. I read in DGJ about how you shouldn’t have Swing components paint themselves in fullscreen mode. Does this only apply to constantly-animated games like platform games, or does it apply to turn-based games too?

[quote]Yep. Typically game developers either draw a background, and button art they BLT ontop of it or they draw two complete images, one with buttons up and one with them down. They then BLt pieces of the buttons down one over the buttons up one as necessary.
[/quote]
Right. I’m thinking of either doing that or continuing to use JButtons but with custom images for them. What do you think?

[quote]I’d need to see the code, My guess is that you are managing to use a peice of video memory that still contains data from the previous image and hasn’t been over-written.

Are you clearing that panel or whatever the screen is?
[/quote]
I got that fixed, actually. Yeah, I think what you described was the problem. Thanks!

  • Rob

Most modern turn based games still atually run a constant game loop. Withotru it yould have avery boring static screen between each move. By consinuosly looping through the engine you can make your game world “alive” and do idle animations and such.

The “turn-basedness” is just that they only accept input one-turn at a time.

Or to look t it another way “real time” games are really just turn based games with a turn-timeut roughly the same as the frame rate.