Concept for making a state manager
Hi all,
In the journey of making my DIY 3d engine, I've come to the point where the spaghetti of switches, booleans and if statements have to come to an end :) time for a state manager
So I've read several tutorials, picked up some ideas and now want to bring them into practice (without copy/pasting just a solution and really wanting to understand it).
This is my plan:
- create a State class, having virtual functions for loading, updating, rendering, handling messages and cleaning up
- I make a class statemanager, containing a vector of state objects
- in these state objects I assign my existing render, message, update, load etc functions a pointers to the matching functions in the appropriate state objects
- I make a class statemanager, which:
1. keeps track of the current state (integer with enumerations?)
2. has functions to switch the state, next/last, absolute ID (enumeration)
3. Has the same functions as the state object (load, render, update, etc.), which will be pointing to the current state in the state objects vector. Meaning that my main loop can simply always call stateManager->update, render etc.
I see some challenges in this approach, but for now I'm just curious if I'm on the right track with this approach.
Things I'm not sure of is how to keep the code clean and readable, where I have to assign the existing functions to the state objects, within the vector, within the stateManager class. Same for the initialization and clean up functions, how do I know which states are going to be used and/or have been used. Maybe just a mIUsed bool within the state class
In the journey of making my DIY 3d engine, I've come to the point where the spaghetti of switches, booleans and if statements have to come to an end :) time for a state manager
So I've read several tutorials, picked up some ideas and now want to bring them into practice (without copy/pasting just a solution and really wanting to understand it).
This is my plan:
- create a State class, having virtual functions for loading, updating, rendering, handling messages and cleaning up
- I make a class statemanager, containing a vector of state objects
- in these state objects I assign my existing render, message, update, load etc functions a pointers to the matching functions in the appropriate state objects
- I make a class statemanager, which:
1. keeps track of the current state (integer with enumerations?)
2. has functions to switch the state, next/last, absolute ID (enumeration)
3. Has the same functions as the state object (load, render, update, etc.), which will be pointing to the current state in the state objects vector. Meaning that my main loop can simply always call stateManager->update, render etc.
I see some challenges in this approach, but for now I'm just curious if I'm on the right track with this approach.
Things I'm not sure of is how to keep the code clean and readable, where I have to assign the existing functions to the state objects, within the vector, within the stateManager class. Same for the initialization and clean up functions, how do I know which states are going to be used and/or have been used. Maybe just a mIUsed bool within the state class
It looks like you're on the right track to me - however, I'm confused as to why you would make a StateManager class with a vector of states in it? Couldn't you just put a BaseState* in your world object, and then in your world.update you call BaseStatePointer->update(), etc?
It just looks like a (possibly) unnecessary level of encapsulation to me, but your big picture seems good. This article really helped me understand state machines; although it's implemented with SDL, I think you'll be able to grasp it:
Hi john.
Thanks, I've read the article. I think the difference here is that the functions for switching states in the article are global functions, in my approach I encapsulate them in a statemanager class. Also in the article when a state is changed, the constructor is run each time/ new object is created, I'm not sure I want that, because then after switching from menu to game, the scene etc. Will be reloaded.
I'm gonna do dome playing around and let you the result.
Thanks, I've read the article. I think the difference here is that the functions for switching states in the article are global functions, in my approach I encapsulate them in a statemanager class. Also in the article when a state is changed, the constructor is run each time/ new object is created, I'm not sure I want that, because then after switching from menu to game, the scene etc. Will be reloaded.
I'm gonna do dome playing around and let you the result.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement