[tinkezione]

Hi there,

in action games that require constant screen update I use a thread to run the main game loop. Inside the loop the game speed can be controlled with the use of some MILLISECONDS_PER_TICK variable like this:

..........
long startTime = System.currentTimeMillis();
repaint(0, 0, WIDTH, HEIGHT);
serviceRepaints();
long timeTaken = System.currentTimeMillis() - startTime;
if (timeTaken < MILLIS_PER_TICK) {
synchronized (this) {
wait(MILLIS_PER_TICK - timeTaken);
}
}
..........

One very fancy tip to make the screen update faster is to update any String items only when necessary. Drawing with drawString is insanely slow and can drag the execution of your game loop remarkably.

Kind regards,
Tinke / FN

[Eight888]

I'm just working on a few game demos following the guidelines set out by the Guidelines_for_Game_Developers_v1_0.pdf file from Forum Nokia.

The one thing I can't figure out is where to put my main game loop. I need a bit of code that is continually updating and doing things like changing the game world or controlling non player characters.

Whats the best way to do this? If I just create a procedure with a

while (OK_TO_KEEP_RUNNING_GAME) {
// do main game loop here
}

then obviously this will seize all of the execution time and stop the midlet from processing events such as KeyPressed. Is this ok? I.e. should I continue with this sort of procedure and process the user input inside my main game loop instead of responding to a KeyPressed event?

Thanks,

8

[Eight888]

Quick extension to this. I went ahead and created a thread in my main game screen FullCanvas to handle the main loop.

I'm guessing this is the correct way to do it (works fine for Applets) but I wouldn't mind hearing a confirmation from someone just to set my mind at ease.

Cheers.

8

[dmford]

Having a loop to handle updating the game is fine, the key events will still work, like all events. In my games I have a Timer (which executes a TimerTask) to control the speed of the game, when the timer task calls my updateGame() procedure I simply check booleans in my program (set by the key events) to see if keys have been pressed and act accordingly.
I also have a seperate class to handle the graphics output (FullCanvas) which I think is a tidier way of programming, with each loop of the game I get the canvas to repaint() and then update the game itself.

Good Luck.

[pbergius]

Hello,

I normally create at least three classes:
- MIDlet
- Canvas/FullCanvas
- GameControl

MIDlet just launches the application and creates the two other classes. Then it passes control to GameControl.

I put the main control loop in GameControl as the name implies. I create (dynamically) an image there which is the size of the screen. I pass all keyPresses from Canvas to GameControl. In GameControl there are basically two types of methods:
- method(s) to respond to keyPresses (like, set current position of a piece 1 position up)
- drawLoop to draw game items in their current positions and maybe some animation. This loop might be in a timed thread or TimerTask if there are autonomous (non-player controlled) items moving around.

Canvas just has a paint method to draw Image and reference to the Image object from GameControl I'm drawing on. This way I can use FullCanvas or Canvas depending on the device.

When you get these sorted out, you can create few more classes, like one to hold, store and retrieve settings and current state of the game to RMS, another to hold language strings and finally one to send high scores and load additional levels (in an own Thread) to a server.

Regards,

Petteri / Forum Nokia

[Eight888]

Petteri,

Do you normally use the one canvas for all your graphic displays?

At the moment I've created a splash screen canvas, an options/start menu canvas and an in-game canvas. Problem is: when ever I call setCurrent(displayable) to move between screens you can see the application menu (7650) flash into view for a split second. :(

Aside from a few little quirks this seems to be quite a simple platform to write good games for. My first few demos have come together impressively quickly.

Eight

[dmford]

I normally have 4 classes,

Midlet, Game, GameCanvas and GameData.

The Midlet sets the Canvas to the screen, the Game class extends Runnable so it can be run as a lightweight process. The Game reads and changes the information in the GameData class and the Canvas simply looks at the GameData to determine what to draw and where to draw it.

I think all our methods are suitable and you will eventually develop a style of your own. GL.

[pbergius]

Hello,

I have similar structure to dmford's for my game midlets. I have
- MIDlet for starting and stopping application and creation of the other objects
- GameCanvas (either FullCanvas or Canvas, selectable according to device) for just painting the image I want to show
- GameControl for contolling the functionality of the game
- Settings for language strings, game settings and high score list saving/loading

You really don't need any more than one canvas instance (or two if you implement both FullCanvas and Canvas) as all it does is to draw the game image in paint method and catch and pass the keypresses to GameControl. GameControl has a mutable image, which it manipulates and copies to the image, which canvas instance draws after repaint method is called.

Regards,

Petteri / Forum Nokia