GeeCON Prague 2014*
The moose likes Game Development and the fly likes Designing classes and methods for a bricks game Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Game Development
Bookmark "Designing classes and methods for a bricks game" Watch "Designing classes and methods for a bricks game" New topic
Author

Designing classes and methods for a bricks game

Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
This is a continuation of a project that is discussed in a previous thread. However, I decided to start a new one as I'm moving on to a different topic. I hope no one minds that I'm using this forum as a cardboard analyst, so to speak. Hopefully it will help me to organize my thoughts somewhat. Still, if anyone has any comments and/or suggestions, please feel free to pipe in. I might even have some specific questions along the way.

Anyway, I'm rethinking my design based on some suggestions in the previous thread. My original design was something like this:

Bricks - simple class with main()
BricksFrame - main window, creates a menu and a BricksPanel
BricksPanel - Main panel inside BricksFrame that handles the majority of GUI objects. (This is my typical approach when I write Swing apps so that I can easily change to an applet if I want to later.) In this particular app, there are not any Swing controls beyond the menu. The panel is primarily used for painting other objects in the game.
Ball - contains data and methods to move a circle around the panel. Ball implements Runnable and most of the work is done in a run() method (i.e. moving the ball to a new position each time interval.
Paddle - contains data and methods for a user controlled "paddle" that moves along the bottom of the main panel. Paddle extends KeyAdapter in order to listen to KeyEvents. Originally (i.e. before I posted my question in the aforementioned thread), Paddle only implemented the keyPressed() method from KeyAdapter and responded to left and right arrow buttons to move the paddle.

With that high level description, Paddle is the class that is currently causing problems so that I am rethinking my design. I recently added a boolean flag to Paddle. This flag is set to true when keyPressed() is fired and set to false when keyReleased() is fired with the same key that originally fired keyPressed(). In order to get continuous animation, I also changed Paddle to implement Runnable and started another thread that loops forever, checking the flag to see if a key is pressed at the moment. If so, it moves the paddle in the corresponding direction.

The problem with this approach is that the ball slows down when the user holds down a key. I think the separate threads for Ball and Paddle are the core of the problem. So I'm trying to come up with a way to create a single thread to handle all of the animation.

At the moment, my idea is to add an Animator class that extends runnable and stores a list of AnimatedObjects. So I'm also introducing AnimatedObject as a new super class for Ball and Paddle.

Does this sound like a good approach? Any feedback will be helpful. Well, I've got to go for now. Thanks in advance for any comments.

Layne


Java API Documentation
The Java Tutorial
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

Originally posted by Layne Lund:

Does this sound like a good approach? Any feedback will be helpful.


Yes. Virtually all "real" games will be written this way, with a single animation loop that hands out "ticks" of time to a pool of time consumers.

I'm a little concerned, though, that adding a second thread causes such a noticeable slowdown; it really shouldn't unless you're busy-waiting or otherwise doing a lot of computation in each thread, or maybe doing synchronous painting instead of just calling "repaint".


[Jess in Action][AskingGoodQuestions]
 
GeeCON Prague 2014
 
subject: Designing classes and methods for a bricks game