• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Designing classes and methods for a bricks game

 
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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".
reply
    Bookmark Topic Watch Topic
  • New Topic