Jump to content
  • Advertisement
Sign in to follow this  
5quirrel

Game state manager question

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

Good Day to all, Posted in the beginner forum but have no reply so i thought of trying out here.. I wish to implement a game state manager for different states of a program. I looked through the form and other available websites. What confuses me is the use of singletons in some of the examples. For what i have learnt, i could have a vector of function pointer for each state, and a state manager class. Or i could have 2 classes, game state and game state manager, then i would inherit the game state class and create singletons and pass them into the manager vector list. Which is a better alternative for making a game state? Is creating singletons the same as making a global instance?(such that it uses up the RAM)

Share this post


Link to post
Share on other sites
Advertisement
Okay, I didn't do any research prior to replying your message. I base on what I know. The information might be wrong but I am sure someone will correct me. Thanks in advance. :)

First of all, I would like you to look at the Finite State Machine design pattern. Its handle exactly what you need.

Singleton is a design pattern too. It have several advantage over global instances.

By making a singleton class, you are assured that your class never get created more than once. Things like manager are generally singleton. State, depend on your design, might be singleton worthy, but i wouldn't recommend because of the next advantage singleton have over global instance.

Singleton is only created when needed and availability is guaranteed and global. If state is a singleton, you might create the state instance when you are not suppose to because you accidentally access it. Of course, this does not stop you from using singleton. or modify singleton to suit your need.

I recommend having 2 classes, game state and game state manager. The reason is simple, its easier to handle creation, update, transition and destruction. but from my experience, it take experience to have a clean framework for that. It might also introduce a bit of complication. It all depend on your requirement.

Is creating singletons the same as making a global instance?
yes and no.
No doubt both will uses up memory. The only difference is when it is created.
With global instance, you must create the instance yourself. everytime you access it, you might face with the problem of it not been instantiated. While with singleton, this problem is eliminated.

Share this post


Link to post
Share on other sites
If you want a StateManager (which sounds like a glorified stack), that is fine. However I can't see anywhere in your posts any reasons why this should be global, let alone a Singleton.

What kind of game are you making? Most games don't have that many states, and so it can actually be easier just to throw a few functions together, along with some kind of "CurrentState" enum to figure out which state you are in, and which to move to. In this case any kind of "GameState" or "Manager" is massive over-engineering of the problem.

Share this post


Link to post
Share on other sites
quite frankly, implement an API, register it with lua and let lua handle the "gamestate"

The mentioned API should should support all kinds of basic entity operations
like creation...

Implement some mechanism to switch between game and pregame and write the rest in lua

The only information about gamestates you need to store is some position and orientation data of entities to implement gamestate updates and to interpolate between frames

Just make sure you store your information inside an entity with lua (e.g.: simple key/value pairs)

the server/client synchronization will handle the rest

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!