Take the 2-minute tour ×

Im developing a game on Java, and wanted to keep my code separated in packages for the hud/gui and the game logic so that code can be reused in some other project, and where objects to be drawn call methods from another class or classes (maybe a "rendering context" like a group of classes just made for the drawing or something like that), the problem is that i can't find the best way to achieve this, because I've researched the web (also this forum) and the design patterns but despite some looked interesting (like Model-View-Controller), I couldn't find something that suits me, neither the common approach to solve this problem.

I've been told to make the objects to implement some drawable kind interface, and in another class called by this objects, some object which implements drawable and inherits from canvas, for example, so that if i would want later to change the objects drawing or displaying methods for another one better, for example from awt to swing, to be able just rewritting those classes and dont need to worry about my objects code, any help would be greatly appreciated, thanks in advance!

share|improve this question
add comment

1 Answer

What I do is typically along the lines of:

Create your game objects completely independent of all things visual. I'm going to use chess as an example. Each chess piece inherits a "GamePiece" interface and knows it's valid moves, what "color" it is (not visual color, but what "side" it's on), etc. But these pieces do not have any code related to drawing themselves. None. Basically pretend like you're playing a game inside the computer and never need to draw it. Design your whole game this way. You'd need a GameDirector that manages the various pieces, the GameBoard, and abstract Players. But still, no visual representation. There's a lot of leeway in exactly how you design your class hierarchy but leave the visuals out of it.

You communicate state changes by raising events, this is key. So when a player moves, an event is raised. When the GameDirector detects checkmate, an event is raised, etc.

Then you have a GameRender class that contains a GameDirector. It listens for these events and updates the visual scene accordingly (whether it's a simple 2D thing or complex 3D animation). This class can optionally have sub-components that are responsible for rendering sub-components of the game but that's not strictly necessary.

share|improve this answer
I usually go one step further and implement a Game object that contains a GameRenderer and a GameState. The Game object takes care of setting up a timer and an event dispatcher, and mediates between the GameState and the GameRenderer. –  tdammers Sep 21 '10 at 8:34
Oh yeah definitely, especially if your game doesn't involve continuous updates (physics calculations, etc). Then the Game object can use the timer to manage the progression of the game. I've found that doesn't work for games with intense game loops though -- it's better to let the GameState object update to its heart's content and have the render rendering as fast as it can. I might just be doing it wrong though :) –  colithium Sep 21 '10 at 9:03
add comment

Your Answer


