Jump to content
  • Advertisement
Sign in to follow this  
Hydr0city

Managing a linear campaign with game states

This topic is 2224 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

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:

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


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
Advertisement
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
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
Sign in to follow this  

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!