Sign in to follow this  
Hydr0city

Managing a linear campaign with game states

Recommended Posts

I'm using a LIFO stack for keeping track of the game state, where each state is a class inherited from an abstract state class. This is the first time I'm designing a single-player "campaign" for a game (FPS style), so I was wondering if my intuition on how to do it is correct.

I was thinking to have a "level" state, which is an abstract class, and to create a child class for each different level (and perhaps the child class also inherits the game state class, I'll figure that out once I get to coding).

So the flow of the game states would look something like this:
[code]
Enter menu state
Push game state
Push first level state
Pop first level state
Push second level state
Pop second level state
// etc...
Pop game state
Pop menu state
[/code]

I know that this will work, but how is this compared to, for example, how a AAA game would manage a campaign?

Share this post


Link to post
Share on other sites
Unless the game play from level to level is different, I wouldn't use different classes for different levels. I'd have "running a level" game state that you construct with the data for different levels.

Share this post


Link to post
Share on other sites
I see your point, however I'm just afraid of the game state file becoming to large and complicated. The main reason I'd separate each level into its own class is to keep it cleaner and more organized (data used in every level would be in the parent class). I guess it's really just preference when it comes to this. I was just wondering if there's some kind of convention that should be followed when programming a game with a linear single player, for performance reasons.

Thanks.

Share this post


Link to post
Share on other sites
[quote]data used in every level would be in the parent class[/quote]

And here's the problem. The state class shouldn't contain the level data at compile time. Rather, it should be loading in the data from an external source. That's why it was suggested that you use the constructor to pass the data into it.

I would suggest a loading screen state. The level state could be given a level ID (like an integer or string representing the level's file or handle) and it will tell the game to load the appropriate data according to the ID. You would increment the ID by one to go to the next level, or if using strings, put your level's names in an array.

Share this post


Link to post
Share on other sites
Sorry for the misunderstanding, by data I meant objects such as the camera, scene managers, input devices, etc. All the resources are loaded at run-time, and it can easily be optimized for each level (I'm using Ogre3D).

The loading screen state is a good idea, I'll play around with a couple of setups to see what can be done. Thanks for the advice.

Share this post


Link to post
Share on other sites
I'm just having trouble imagining what you would do with different level classes, unless game play was actually different in each level. In most games level data is just that: data. You have a main game state of some sort that either loads the data from file or is passed the level data and runs the level. So what exactly would you put in your different level classes that would justify having separate classes?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this