Hi, I''m trying to make a simple game (2D top-down-view shooter or something like that). The "project" is still in an early phase, but already I''m bumping into design-problems. How do I split a game in different parts? I''m aware of the importance of OOP, and I know its concepts. But how do I use them? The game is going to be rather basic (hey, I haven''t done this before): player-character with simple animation, some monsters with simple AI, maps with breakable objects. I''m going to use GDI or DX for the graphics and Windows or DI for input (all depending on which one''ll give the best result). No sound for now. I would make Object- and Character-classes for objects, monsters and the player. These would be managed by a general Game-class, that deals with game logic, and uses a Graphics-class, an Input-class and a CollisionDetection-class. This seems logical to me. But how should they interact? For instance, different objects have bitmaps to represent them on the screen. Should I store this information in the Objects-class, or in the Graphics-class? I would keep the bitmap-handles/surfaces in the Object-class. Is this the best choice? I would like to keep this low-level-stuff in the graphics-class, but that would make the interface between the Object-class (which would have nothing in it, but it''s position, hit-points,...game-related stuff) and the graphics-class (which would have to keep track of the status of every object, and what bitmap to use). The first method (bitmap-stuff in the Object) is much easier: just calling something like Graphics.render(*Object) would do the trick. And it''s much easier to let each Object keep track of what bitmap should be used to draw it at a given time, resulting in a method like Object.getCurrentBitmap(). Anyway, I know most of the time, there is no "best" solution. Just some of my thinkerings. Any toughts? Suggestions? Thanks, Koen

First, take a look at gameplay and write down all of the objects in the game: the player, the baddies, the powerups, obstacles, etc. Don''t forget the big things, like the level, zones, etc. Now draw a graph. This graph will include links for containers, common functionality, etc. A level contains a number of zones, and the zones contain obstacles. The player(s) and baddies both are actors in the game. This will be reminiscent of your class heirarchy for the game.

Now list all of the functionality needed to support that heirarchy. Sound, graphics, physics, etc. These will be classes also (usually singletons) that will manage the other elements in the game within their jurisdiction. The physics engine will process move requests. The sound engine will process sound requests, etc.

That''s a good place to start.


p

But suppose an actor requests the physics-engine to move, then this physics-engine needs to know about the entire world. That way, all different classes need to be linked all over the place, making it rather difficult to change something, or to find bugs. I''d really like to make a nice OO design. I''m starting to believe the different parts of a game cannot communicate with a simple interface. Correct me if I''m wrong :-)

Koen