Archived

This topic is now archived and is closed to further replies.

Talib

Help - Game code layout

Recommended Posts

Depends entirely on the game.

A simple platform game (Mario/Sonic etc) might be (very simplified version):



Switch GameMode
{
case TITLE_SCREEN:
DoTitleScreen();
break;

case PLAYING_GAME:
DoMainGameLoop();
break;

case GAME_OVER:
DoGameOver();
break;

... etc ...
}

DoMainGameLoop
{
while (Player.Alive == true)
{
> Check Keyboard for input
> Update enemy positions
> Check for collisions
>
>
> Update player status
}

}



Basically you should sit down and think about the kind of game you are writing, and then split it up into manageable chunks. Each of these chunks might become individual functions, or groups of functions. The core of any game is (virtually) always a loop which will continue until the game ends. Each iteration of the loop you check user input, player status, enemy status etc.. and make sure that the screen reflects the current state of the game.

Obviously this is a VERY simple introduction, but your question was a little vague. Hope this helps a little!

Share this post


Link to post
Share on other sites
You can use a class based structure which i always find its nice and managable

class CGame {
CGameState *state;
};

class CGameState {
public:
virtual CGameState Run()=0;


};


class CGameState_Menu : CGameState {
public:
virtual CGameState Run();
};

class CGameState_Run : CGameState {
public:
virtual CGameState Run();
};




In the CGame you create a pointer to a CGameState, then each frame you can call CGameState::Run()

It returns a CGameState, if its different from the current game state you can delete the current and switch it by allocating the pointer = new CGameState_Run or _Menu..


Hope this helps.
Any questions.. email me ash@ubercheese.com.

Share this post


Link to post
Share on other sites
I believe it could be like this:

- App initialization (form, window, message handler, etc) (init 3D device if you use it for the menu''s)

- Pregame menu (options, start new game, quit, view highscores)

- Start game (create an instance of the game class when you choose start, set up game loop, initialize game, load data files)

- Play game

- Exit game

- Exit app

If you divide the stuff between application and actual game you can separate their data and have a more logical structure. It''s tempting to make something that compiles by making only the game. But then it starts as soon as you run the exe and quits when you lose.

By having a separate game object you can have a menu first, pause it to show the menu again, support save and load and have the player start a new game after he has lost.

Share this post


Link to post
Share on other sites
I totally agree with the previous three posts, my 2D rail-shooter followed this format, though due to the time constraints of the project I was forced to use switch statements in my frame move (where i update the keyboard and mousestate) and the render. Whenever the game mode changed, I sould send a PostMessage() with my predefined message ID and invalidate and restore based on the current game mode and updated new game mode.

The best idea is of course (as previously posted) to figure out what type of game you want to make, and find a game within the same genre as yours and see how they handle things such as menus, key layout etc. to get a feel for what a user of your end-product might expect.

Best of luck,

Permafried-

Share this post


Link to post
Share on other sites