Structure of a game?

Started by
6 comments, last by Kris2456 19 years, 10 months ago
I was wondering. How would i go about making a structure for my game. I realise that i would have to have: Intro Main Menu Sub Menus Game But how would i go about programming these "states" into OpenGL. I am using NeHes code. ------------ "Here lies a toppled God, His fall was not a small one, We but built his pedastle, A narrow, and a tall one" Frank Herbert (Dune:Messiah)
------------ "Here lies a toppled God,His fall was not a small one,We but built his pedastle,A narrow, and a tall one" Frank Herbert (Dune:Messiah)
Advertisement
Different for style of game but for a level style platformer or shootem up try this

-----------------------------------------------
void Draw()
{

switch( status )
{
case MENU:
{

call the main menu routines
break;
}
case INIT:
{

InitLevel();
InitPlayer();
status=GAME;
break;
}
case CREDITS:
{

show credits
break;

}
case HELP:
{

//Call the help screen
GameHelp();


break;

}

case OVER:
{

call the gameover function

break;
}
case GAME:
{


this is the meat

check end of level
check end of game
check input etc
break;
}
}

engine.Render();
}

------------------------------------------------
setting the status as needs be
Great, thanks for that. Ive got it working with an enum. I was wonderinf if it is better to do it with classes?
------------ "Here lies a toppled God,His fall was not a small one,We but built his pedastle,A narrow, and a tall one" Frank Herbert (Dune:Messiah)
There''s always a state machine, with objects for states (design patterns).
make a class called State. Make a class called StateMachine which has a pointer to a State. Make a bunch of classes, derived from state, representing the various states the game can be in. For each event you want to respond to (mouse move / key press / next frame / whatever) you call a function on StateMachine, and it calls the equivalent function on the current state. That way you don''t have switch statements all over the place. I do it like this. I''m not 100% convinced that I like it, but it does mean I''m unlikely to accidently do something that should only happen when in state GAME when Im actually in state GUI.

Generally, states will have OnEnter() and OnExit() which get called when you change from one state to another. I find Tick() which gets called once per frame is rather handy too.
quote:Original post by Squirm
There''s always a state machine, with objects for states (design patterns).
make a class called State. Make a class called StateMachine which has a pointer to a State. Make a bunch of classes, derived from state, representing the various states the game can be in. For each event you want to respond to (mouse move / key press / next frame / whatever) you call a function on StateMachine, and it calls the equivalent function on the current state. That way you don''t have switch statements all over the place. I do it like this. I''m not 100% convinced that I like it, but it does mean I''m unlikely to accidently do something that should only happen when in state GAME when Im actually in state GUI.

Generally, states will have OnEnter() and OnExit() which get called when you change from one state to another. I find Tick() which gets called once per frame is rather handy too.


No no no... You need a linked list controlling those states with each of the states having a function pointer to a state function. Then you can push and pop the states you need when you want them.
Take back the internet with the most awsome browser around, FireFox
Design patterns <- I''ve already heard of some of theese, but I would really love, if someone could point me to some informations about theese patterns. I mean some list with some explanation about what each pattern means.

PS.: I''ve already heard of the google =), but I beleive you have to have some source from you''ve learned it.

Oxyd

- Unreadable code is code written on a piece of paper, but not the one, in which the programmer is using a space in the place you don''t.
- Real programmers aren''t afraid of goto
I wrote a little tutorial on something like this a while back - http://tonyandpaige.com/tutorials/game1.html.

Hope it helps,

Tony
sakky : Why do I need a linked list of states? I don't see any time when I would want to iterate over all of them - they just need to exist somewhere, somehow... [sudden flash of insight - ah, you mean the current state is a stack of states, not that you have a list of states to choose from. I thought of that - I haven't tried it yet.]

Also, one function pointer? I have quite a few state functions, and rather than do it all by hand, I derive all my states from a common base class and let the vtable do all the hard work

[edited by - squirm on June 6, 2004 5:05:39 AM]

This topic is closed to new replies.

Advertisement