Jump to content
  • Advertisement
Sign in to follow this  
AlysiumX

Building my first game(Game code layout)

This topic is 2466 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello all,

I am currently working on my first game. Being my first, of course its a pretty simple concept. What I am really focusing on currently is the over all layout of the code. I am new to game programming but not programming in general. Anyways what I am doing with my GameStateManger currently is either genius or complete stupid so I wanted to hear other opinion to see if they think it is good or not, so here it is.

I current have built a GameStateManager class. Now for the game states I am building an individual class per game state. The logic behind this is that I will clear one game state out of memory before going to the next thus keeping the game running smoothly. That sounds good in theory but I am interested to hear if I am not looking at things correctly or just over complicating it.

example :
GameState manager
public static void UpdateGameState(){
switch(state){
case OPENING:
Opening.Update();
break;
case TITLE:
Title.Update();
}
}

Opening && Title Classes
public static void Update(){

}



p.s. I know at this point it won't really matter because the game is simple, but I would like to scale up as I create game and don't want to eventually hit a wall, so its good to know this stuff before hand.


Thanks

Share this post


Link to post
Share on other sites
Advertisement
That design actually looks pretty similar to what I did for a small text adventure project that I worked on a while back.

I suppose that it would depend on how you handle it... what kind of a game is it? Will it have graphics? How do you handle events in the game? If something in a room changes, how do you keep track of that?

I can tell you how I handled the text adventure:

(1) There was a parser and an interpreter. The parser's job was to take the information supplied by the user and break it into distinguishable commands. It viewed things as: "command" "description" "object" for 3 inputs, or simply "command" "object" for 2 inputs.
First it took the command and compared it to the list of legal commands. Then it would take information from an object library that I created. Each object would have characteristics that described it: Is it a "place" or a "thing". If it's a place, then places have several commands which are legal such as: w "west", n "north", s "south", enter, etc. Objects also have legal actions associated with them. If something is legal, something logical happens which causes the player to interact with the environment.

(2) The interpreters job was to handle exceptions and actions for generalized behavior such as; what options are set that change the game behavior? The parser sent information to the interpreter, which the interpreter used to communicate with objects to figure out what to do.

Mine was a very simple model. My parser wasn't as sophisticated as Zorks, and this design had a few problems with it. Every time I created a new room, I had to specify the specific behavior of the room every time. But for a simple model it worked pretty well. I was proud of it.

I ended up scrapping what I was doing 2 times before I settled on the model I described above. (I was also just learning how to program for the first time back then)

Share this post


Link to post
Share on other sites
Yes its a graphical game. Its kind of an arcade type game though, and even though levels are pretty simplistic and really just the same graphics with more enemies, I planned on having a level manager to handle it all. Basically I would have a "Playing" gamestate that handles loading the level, the player, the hud, and all other stuff that you have when playing. But while in other game states, those objects would not be loaded.

Share this post


Link to post
Share on other sites
You may find my latest article interesting.
It is fine if you want to clear one state out of memory before loading another. But how do you plan to do that with a bunch of static functions? That defeats the whole purpose of object-oriented programming.
Read to find a better solution. The code may be C++, but it works in C# as well.


L. Spiro

Share this post


Link to post
Share on other sites

You may find my latest article interesting.
It is fine if you want to clear one state out of memory before loading another. But how do you plan to do that with a bunch of static functions? That defeats the whole purpose of object-oriented programming.
Read to find a better solution. The code may be C++, but it works in C# as well.


L. Spiro


While a great article is too opinionated. Game complexity will determine a games loop, and for the most basic of graphic games what he did
works fine.

your article is like suggesting a vertex of function pointers on the stack for a game of hangman. and NOTHING ELSE IS ACCEPTABLE... pahlease....

Share this post


Link to post
Share on other sites
The only 2 opinions ever expressed were:
#1: That making a gargantuan switch case and (possibly also) calling static functions is an inferior idea to polymorphism.
#2: That singletons/globals are a bad idea.

Both of these are also facts, however, not just opinions.

I don’t know what you mean by “vertex of function pointers”, especially since I made no mention of vertices nor function pointers, but as for what is acceptable, you may need to read it again.
I clearly stated that there are various ways to go out this type of system and even expressed possible alternatives here-and-there for those willing to take shortcuts for smaller games.


I don’t see why you are so offended when this type of advice was specifically requested by the original poster.

p.s. I know at this point it won't really matter because the game is simple, but I would like to scale up as I create game and don't want to eventually hit a wall, so its good to know this stuff before hand.

I am speaking from experience. I scaled up, and then hit a wall. I had to rethink my organization and start over.

Early on I learned how not to hit walls at least, but it took some revisions to make it actually user-friendly and to address all the needs I had encountered before, many of which were not mentioned for the sake of brevity.

At no point along the way did I ever fall back on, “This is fine for what I am doing.” The things I was doing wrong was due to lack of experience, not the lack of desire to explore and improve.

The person who says, “This is just Hangman, but I could use this opportunity to gain some experience that will be valuable down the road, and try to get as “proper” a foundation from it as I can,” gets the pot of gold at the end of the rainbow.


L. Spiro

Share this post


Link to post
Share on other sites
I would recommend:

istate.h

class IState
{
public:
virtual ~IState( ) { ; }

virtual const char* GetName( ) = 0;

virtual void Call( ) = 0;

virtual void Shutdown( ) = 0;
virtual bool GetIsShutdown( ) = 0;
};


basestate.h

class BaseState: public IState
{
public:
BaseState( );
virtual ~BaseState( );

void Call( );

void Shutdown( );
bool GetIsShutdown( );

protected:
virtual void Initialize_( );
virtual void Run_( );
virtual void Shutdown_( );

bool isInitialized_;
bool doShutdown_;
bool isShutdown_;
};


basestate.cpp

BaseState::BaseState( )
{
isInitialized_ = false;
doShutdown_ = false;
isShutdown_ = false;
}

BaseState::~BaseState( )
{
;
}

void
BaseState::Call( )
{
if ( !isInitialized_ )
{
Initialize_();
}
else if( doShutdown_ )
{
Shutdown_();
}
else
{
Run_();
}
}

void
BaseState::Shutdown( )
{
doShutdown_ = true;
}

bool
BaseState::GetIsShutdown( )
{
return isShutdown_;
}

void
BaseState::Initialize_( )
{
isInitialized_ = true;
}

void
BaseState::Run_( )
{
doShutdown_ = true;
}

void
BaseState::Shutdown_( )
{
isShutdown_ = true;
}


statemachine.h

class StateMachine
{
public:
StateMachine( );
~StateMachine( );

void RunState( IState* state );
void ShutdownState( const char* name );
void Update( );

void Shutdown( );
bool GetIsShutdown( );

private:
Vector< IState* > states_;

bool doShutdown_;
bool isShutdown_;
};


statemachine.cpp


StateMachine::StateMachine( )
{
doShutdown_ = false;
isShutdown_ = false;
}

StateMachine::~StateMachine( )
{
;
}

void
StateMachine::RunState( IState* state )
{
states_.InsertBack( state );
}

void
StateMachine::ShutdownState( const char* name )
{
for( uint32 i = 0; i < states_.GetCount(); ++i )
{
if( stools::IsEqual( name, states_[ i ]->GetName() ) )
{
states_[ i ]->Shutdown();
return;
}
}

FAssert();
}

void
StateMachine::Update( )
{
for( uint32 i = 0; i < states_.GetCount(); ++i )
{
if( doShutdown_ )
{
states_[ i ]->Shutdown();
}

states_[ i ]->Call();

if( states_[ i ]->GetIsShutdown() )
{
states_.RemoveAndDelete( i );
}
}
}

void
StateMachine::Shutdown( )
{
doShutdown_ = true;
}

bool
StateMachine::GetIsShutdown( )
{
return isShutdown_;
}

Share this post


Link to post
Share on other sites
Then you can just inherit BaseState into your states and have them run pretty well with automatic shutdown and initialization.

Also, why the hell after so many years is code pasting not working... Come on guys!
(By which I mean the lack of whitespace support that makes it nearly unreadable)

Share this post


Link to post
Share on other sites
Thanks for the comments, I think i will fold the gamestates into the actual game class. After that I can create instances of gamestate classes. When a gamestate switches I can then dispose of the object.

I am using java btw not c# but I'm sure much of what was written would still apply.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!