Game States

[1337]

In the last few days, I have spent some thoughts on game states. My goal is to write a game state manager that would suffice all the needs we can imagine right now, so that we don't have to rewrite it 10 times.

In order to an idea of the concept, I tried to draw a diagram that shows the game states hierarchically. There are 3 dark red states: They're not meant as actual states, but rather as transitions. We could do that with "OnEnter" and "OnLeave" functions, but in this case, it would very well fit in to the hierarchy.

Here's what I've got:
http://www.orxonox.net/wiki/GameStates

I imagine that whenever a child state is requested, the parent state still runs, but maybe paused (ambiguous in the diagram, because showing the settings window in networked mode doesn't pause the game, but does so otherwise, etc.).
However if you wish to change to a sibling, the old state is stopped. We can of course extend this to any state in the hierarchy (stopping states recursively).

Now, I would like get some feedback, because I'm sure the first approach is bullshit, as always

PS: Does anyone know how I can show the picture from the wiki in this forum directly? (reference with [img] didn't work)

[BadElvis]

Thanks for sacrificing your exam prep time! Looks very interesting, although I admit not understanding the whole concept by looking at the tree.

Is the network include somewhere implicitly? I can only see "Level without network".

Is it clever to separate open space levels from ground levels? The latter function will probably not be used for a long time, anyway.

aob, f.-

[1337]

Well, the tree itself is only an example. It has nothing to do with the actual one since that will be generated at startup (but hard coded). It's more about how I need to implement the tree, what it has to feature and what I shouldn't forget to consider...

But yeah, its complicated. But currently I'm not working on it due to obvious reasons
I'm sorry I can answer your actual question next week soonest..

[patrick]

so from what I understood you actually want to implement a state stack where you enter leave states embedded in other states.

I wouldn't over-engineer the state framework, a simple state stack seems sufficient for me. If you have too much states and sub-states you can also run into complicated threading issues (where different threads have different states in parallel).

you told that you want to have the state manager cope with all situations imaginable atm. What are these situations that you are talking about?

[1337]

so from what I understood you actually want to implement a state stack where you enter leave states embedded in other states.

I wouldn't over-engineer the state framework, a simple state stack seems sufficient for me. If you have too much states and sub-states you can also run into complicated threading issues (where different threads have different states in parallel).

you told that you want to have the state manager cope with all situations imaginable atm. What are these situations that you are talking about?

Thanks for the input so far. I may not have mentioned this, but I actually have no idea about this topic
About the over engineering part: That shouldn't be a problem because first of all I like doing it and second of all, it shouldn't take more than a couple of days to write the base class GameState. There will be no actual manager, so the hierarchy does that. We can then create the root node at runtime and add all the states.

About the threading: Yeah, that is a problem. Mainly because I really can't say I'm experienced with multithreading. And it is my future aim to have separate threads for certain parts like physics, rendering, etc. That especially allows for better control of the update cycles. Timing a tick in one thread was almost impossible, however yield() in combination with a precise timer should get us the required results.
My objection at the moment is to distribute the tick() through the hierarchy, so for instance the pseudo state "3D init" will have the render calls, "IO init" however won't tick anything at all because there is no need for a tick until the dedicated server has started.

About the stack: It will be a stack in the end, because I will not allow two states on the same level of the tree to be active simultaneously. The idea with the tree rather originates from the thought that it is self managed concerning state transitions.

About everything: I know it is all very vague. That's why I really appreciate input from others even though I'll probably try to disclaim it
And I guess it sure won't work in the first attempt anyway...

[1337]

something 'else': What exactly do you (patrick) mean with 'multiple threads will execute in multiple states'? I can see that, but only along one single path of the hierarchy. Is that what you meant?

[patrick]

yes, exactly. you will have differents paths at the same time (differents states at the same time)

[1337]

The idea actually is that this is not possible per design. The multithreading part will probably be in "3D init", but right now I'm not exactly having the 'big view'.
Currently the tree is programmed and I'm testing it. Implementing the states is another thing...

[1337]

Status update:

I have just more or less released the first pre-alpha of the gui branch. It contains:
- InputState (better object oriented input distribution)
- CommandLine (specify arguments and recall them)
- CEGUI (very simple start page)
- and of course GameState, the new approach to eliminating the chaos with our initialisation.

Some notes: The GameState class itself should be quite stable, but can still contain bugs. I'll have to do some more unit tests there. The actual implementations of the states are not yet finished. I especially didn't yet have the time to test the network part.

Nevertheless I would be very glad if someone with linux and gcc would take the time and install CEGUI (0.6.1) and test my branch (only compiling, running and reporting the segfault).

[1337]

Status update:

I have created a special RootGameState so that transitions now occur between ticks which was very essential.
There have also been many fixes and some new stuff.

Yet to be done:
- Finish proper time management (global Clock is written, but level-clock is still missing)
- TimeFactor is not yet applied to newly created ParticleSpawner and whatever needs to get updated because of the particles. I'm thinking of writing a callback for newly created objects. That would ease up some more 'hacks'.
- Game state suspension is far from being processed by my brain..
- Hierarchy of GSLevel, GSServer, GSClient, GSDedicated and GSStandalone is not yet the way I like it...
- GraphicsEngine has become a stub, merely serving as a global object. Which is something I generally dislike. And in this case we can dispose ourselves of it, but that requires some major changes in the level objects code.
- Deinitialisation doesn't yet work for GSGraphics because I'm still fighting with Ogre::Root to only shut down the things created in Ogre::Root::initialise().
- Network states don't work due to game state unrelated reasons (probably just needs the update from the network branch)
- A lot more I can't think of right now.

Despite all these task I can confirm that it works very well and really like it because the game states give our whole start maneuver a good taste of hierarchy and structure.

A BIG FAT NOTE: I WILL NOT MERGE BACK TO THE TRUNK UNTIL AT LEAST ONE LINUX USER HAS TESTED THE BRANCH!
That branch also includes CEGUI and it would be a good thing to do that merge quickly.

[beni]

This sounds pretty good. I see you have pretty much to rewrite.

I'm also testing your branch. Cmake works, but when I compile I get some errors due to a missing CEGUILua.h.
I therefore deinstalled CEGUI v0.5.0 and installed CEGUI v0.6.1 instead. (Would be cool if you could restrict the CEGUI version in the CMakeList file.) I used the same configuration parameters as before, when using v0.5.0. There have been some runtime errors after all.

Compiling worked with v0.6.1 of CEGUI.
After svn up in my media directory, orxonox worked flawlessly as far as I can tell!!

Remember though, because of CEGUI v0.6.1, the new version of orxonox will not work on tardis!!

[1337]

Great! At last a beta tester Thanks very much

about CEGUI:
yeah, I know that. Which is why I didn't restrict to CEGUI 0.6.1

Tardis comiles flawlessly by the way with 0.5

You will have to add CEGUI LuaScript module to 0.5 in order to make it comile.

EDIT: There might be an issue when using CEGUI 0.6.1 and lua 5.0 or CEGUI 0.5 and lua 5.1. However, I cannot tell. It's just that I need to modify the lua state created by CEGUI (or vice versa, doesn't matter) in order to be able to access our c++ functions via tolua.

[beni]

I see, the CEGUILua module is important then.

The problem is unfortunately that Ubuntu does not has simple packages for this. But I'm sure this problem will be solved somehow.

However I found some bugs in your branch after all:
Enemies do not work at all and particle effects won't die anymore. This means those fires stay even after the enemies are shot down. Also when I hit a asteroid the small explosions reoccur after some seconds.
I dunno if this is your problem, or somebody else's.

[1337]

enemies: have to look into that.
particle: I modified the timer class lately to work with uint64_t....

thanks very much for the report. already fixing..

EDIT: uint64_t has been fixed to int64_t (classical mistake when counting down to below zero...)
But I can't fix the enemy problem since it works for me. What exactly does not work? Does it in the trunk?

[beni]

Nevermind. Everything seems to work now...