Game state manager question
Author
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)
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.
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.
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.
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.
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
