2D game design

[badkarma1399]

Hello!

I have taken several years of high school programming classes, which though helpful, seem to leave how how to implement and manage larger stand alone applications. A few of my friends and I want to design a game like those found on the SNES, donkey kong, mario etc, (but with guns) and nothing too fancy. Anyways, I'm trying to figure out the best way to assign responsibilities and break the game up into classes. (this is in Java, simply because i know it the best).

I've uploaded a flow chart of the different classes so you can see what I've got so far:
http://www.imagehosting.com/out.php/i726942_Image2v.jpg

The blue buttons are single classes, the "Image" one is the double buffered game image, and the silver ones are specific enemies, objects, or weapons etc. Maneger classes contain methods for their objects, and the engine integrates it all together.

Anyways the question, how is this layout? Is there anything structurally wrong or is there simply better way to organize everything?

Thanks, and just post if anything is unclear.

 

[DaveSimmons]

I don't get much of a sense from that of what each object is, what it does, or how they fit together.

Here's how I'd break apart a 2D game:

(content)
Sound effects
Bitmaps - tiles & sprites
Levels

(code)
Level data set / state definition
User input reading (mouse, keyb, gamepad) - stored for use by level state update
Graphics engine (rendering of current level state, setting of collision detection)
Level state updating (scripting/AI, movement, firing, collisions, terrain destruction, spawning of objects)


A single object like an "enemy" has properties like
- its type (such as a squirtle)
- location and current motion
- health if not one-shot kills
- its sprite/bitmap (and the position in a cycle if animated)
(these might be looked up from a table, based on the type)
- which behavior pattern / AI script it follows
- stats like max damage or top speed

Having an enemy manage itself might seem like a good idea but it makes more sense to me to have a main state update function that runs once a frame and processes all objects.

 

[badkarma1399]

yea, I should have been more clear. Basically, i'll explain a bit more in depth:

Main Class: Constructs game window object, Buffered game image object, and holds/displays menu and game objects.
Silver boxes: Pretty much what DaveSimmons described above. A single object like enemy with name, location, health etc.
Manager classes: Basically, these hold an array of their respective objects. So for lets say the terrain Manager, it holds an array of all terrain objects. Further, its provides methods to check the terrain objects for collisions against the player etc. An example: TerrainManagerObject.CheckForPlayerCollision(PlayerObject); Something like that. So if the CheckForPlayerCollision is set to return a boolean, and it returns true, it means the players on the ground etc. Manager classes would have methods like this.
Engine: Basically holds the main game loop, which is responsible for level state updating and graphics updating. Also responsible for input reading. For state updating, it would use methods from manager objects to do the actual state modifying, the Engine would just call them and organize them into something Useful.
Level: Gathers level data from .dat files and creates terrain/enemy objects for the Engine to use
Window: Just a window to hold the game in. Uses Jframe.
Image: Contains the next frame to be displayed. All drawing is done to it. Then its sent to window to update the frame. Engine/Menu objects are responsible for updating it and sending it to window.

Sorry for the length and thanks for the reply btw.

 

[ppdes]

Don't forget that there are countless game making frameworks out there. Going from scratch means doing an enormous amount of work that's already been done.

 

[Munky]

The diagram you posted seems too "abstract" (no pun intended), and over-complicated at the same time. I've written some games on my own, and usually here's how I break it down:

Engine: I do not have a separate "engine" class, but rather I break it up into pieces, with each piece responsible for some task or object, such as display, sound, camera, user input, and such. This is separate from the "main" class or loop.

Objects: group data and associated methods into logical classes, especially when there are multiple instances of such objects. For example I'd have classes for terrain (or levels), character models, textures, shaders, etc. Each class contains assoiated functions to load data, render, check for collision, update states, etc.

Main: the main class is only responsible for initializing and managing global data, and to coordinate how the various pieces fit together.