Sign in to follow this  
Nairb

Unity Game States Without a Stack

Recommended Posts

This post is largely inspired by this thread: http://www.gamedev.net/community/forums/topic.asp?topic_id=361171 I have yet to find a way of managing game states that I really liked. I always had a distaste of the stack method, because juggling back to previous states lower down in the stack is messy. For instance, if I have a menu A which leads to another menu B which leads to C and then to D, but I want a button in D that sends me straight back into A, the stack method does not seem particularly intuitive (obviously those aren't states in the truest sense, but the principle is similar). The method I prefer, and the one which I've been playing with, is more similar to a process manager. Code Complete has something like this. The Enginuity articles also have something similar, although they seem functionally a bit different. Basically, states can be a collection of processes. When you want to change states, you remove some processes and add others. Processes can remove themselves and spawn other processes. Processes can also have children, which only receive events when the parent process is active. Obviously, there is a base process manager which accomodates adding/removing processes. In fact, I have come to like thinking of a game more in terms of an operating system - with processes and resource management and extensibility and such. So I was wondering if there were any major flaws in my thinking or if there was some more you could suggest. Cheers, --Brian

Share this post


Link to post
Share on other sites
Ok, i've never done this with a "menu" system, but something I liked for an adventure game is a "state vector".

for the most part it was a std::vector<string> that I store strings in to represent any information that the game needed to keep track of.
This worked like store("livingroom_light_on"), you would later check that for some trigger event and swap it with "livingroom_light_off". The main benifit of this vector of different strings being that there were no hardcoded states, and there were no limits to the states you could move to.

This could be expanded to a vector of functors that point to all the functions you want to call each update. (Menu1, button1, button2, main_gameloop)

The problems? There is no elegant way to add/remove lots of states (like a whole menu of items), but this could be reduced to having the menu object be the
only state functor that you add to the state vector. Again, there is some added management over a stack, since you still have to have your button
delete the current menu from the state, and add the other menu.

But, at the same time, you can add several menu's or windows into the state vector with each managing itself. You don't have to make up speciial states
for when you want to show an invintory and have the player window open behind it and still running.

I don't think is it the most elegant design, but I found it to be more flexable than a stack when i was making my adventure game.

--edit, re-read your post, and made note that what i said above sounds kinda like the proccess manager idea.
But I think that the process manager should be something seperate, since i think of a process manager controlling the threads that stream in data, take care of resource management, and your main thread. Where as a state manager is linked more to the flow of the game than the lower level managment of resources.

Share this post


Link to post
Share on other sites
I'd go with a list...

I'm currently using the stack method in a game I made for school homeworks and the best thing I've seen that it could be improved is to be able to have a state that is a list of states to implement "layers".

If you're doing it in a (pure) stack only the top element is available. A list would give you access to other states and it will be possible to "sort" the states. If you want to disable a state you could have a flag somewhere to do that. Having a state being a list of states allows interesting things like, for example, the game itself running in the back of a in-game menu. Having the state manager as a state and a list allows the same as having a state being list but can provide more flexibility with the states.

By changing to the list method (from the stack) you will need to see this more like different layers. This is a good way to have a layers in the game, then a layer for the rendering for the UI, then maybe add a layer with a menu, all those could have acces to the game through a pointer.

Share this post


Link to post
Share on other sites
My question would have to be: why do you need to store the previous scene in a menu to begin with? Just use scene pointers, allowing them to switch freely based on options availiable. Then you can do pretty much anything cleanly.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nairb
I always had a distaste of the stack method, because juggling back to previous states lower down in the stack is messy. For instance, if I have a menu A which leads to another menu B which leads to C and then to D, but I want a button in D that sends me straight back into A, the stack method does not seem particularly intuitive (obviously those aren't states in the truest sense, but the principle is similar).

In my project I handle such a situation by allowing the top level states (those on the stack) to have child states of their own in a sorted list. Thus it is a hybrid between a stack and a list state scenario. In your situation I would let the menu A be the top level state on the stack and let menues B, C and D be children of A. This way any one of the child menues could send a TerminateChildren command to A. To qualify for being a child state a state would need to exist fully within the context of another state.

Share this post


Link to post
Share on other sites
Quote:
Original post by PaulCesar
My question would have to be: why do you need to store the previous scene in a menu to begin with? Just use scene pointers, allowing them to switch freely based on options availiable. Then you can do pretty much anything cleanly.


If you want the game to continue in the back when a menu is displayed it could be easily implemented that way. Every layer is independent so I wouldn't even have to care about a scene pointer that way.

Bringing a state to the front would mean to bring that state on the top. Also, like in a process manager it would look like a tree because each states can have childrens and will manage them.

The states would look like they are squeduled and they will run until they send back the control to the manager. If a state blocks (in any of the ways it could) it would block the whole game but anyway this would mean that something is wrong.

Every state layers would act like if they were threads on the same CPU since we implemented a way to have each states to be run (kinda reminds me my first process scheduling experimentation when I tried to make a operating system long time ago). Maybe priorities could also help ordering which state should run first (children shouldn't have higher priorities than parents) so you don't have to reorder anything.

Share this post


Link to post
Share on other sites
I'll use the term 'task' for this discussion, but note that it is the same as 'state' or 'process' above.

I don't like the stack-based approach very much. I prefer to have a manager which exposes the following interface:

registerTask
activateTask
deactivateTask
deregisterTask
tick

Tasks are registered by name. In C++, normally this means passing a name string with an instance of a Task object to link with it. In Java, I usually provide a second form taking a name string to use as a key and a string which is the fully qualified Java name of the class to instantiate ("mypackage.MyTask", for example) - dyanmic instantiation allows for easy configuration of tasks via external data files (this can be done in C++ by implementing and registering TaskFactory instances rather than Task instances). Using dynamic instantiation, you can implement a flexible configuration system that associates menu items/key strokes/events/whatever with different Tasks, thereby eliminating the need to hardcode any flow at all. Or, you could go with something much simpler that just registers all available Tasks at initialization and leaves it up to each task how to manage flow. The other methods of the TaskManager all accept a string which was the key used to register a Task.

Each task exposes the following interface:

init
activate
deactivate
deinit
tick

When a Task is registered, the TaskManager calls the Task's init method (instantiating it first if using a dynamic system). This is for one-time initialization (which can be anything you deem appropriate). The manager then stores the Task instance away in a hash map for later use.

When TaskManager.activateTask is called, the manager finds the task in the registry. It then calls the Task's activate method. This is where any intialization not handled by the init method should take place. The Task is then added to an active Task list.

Each frame, the game loop calls TaskManager.tick. The manager iterates the active task list and calls the tick method of each task it finds. There is an issue with sequencing here. You could implement it so that when tasks are activated, they are added to the back of the active list. This makes it so that tasks are always ticked in the order they are added. Another option is to assign priority numbers to each Task and use those to sort the active list. Another thing to keep in mind is that you might want some Tasks to temporarily halt processing of the active list, preventing other Tasks from being ticked. For this, I have the tick method return a boolean. A return of false tells the TaskManager to stop iterating the task list.

The rest of the system should be obvious. TaskManager.deactivateTask finds the Task in the registry and if it is active, removes it from the active list and calls its deactivate method. It does not remove it from the registry. TaskManager.deregisterTask removes a Task from the registry and calls its deinit method. In C++, if you are using factories for dynamic instantiation, the manager should also delete the instance. Otherwise, you should put the repsonsiblity on the caller and return the Task instance pointer.

I find this system to be more flexible than a purely stack-based approach. You can do some neat stuff with it. Assuming that you separate the actual game state (and by game state in this case I mean player stats, entity positions, etc...) from the Tasks, then you can get even more flexibility. One Task could be used to handle the management and display of the game world, while another task could be used to overlay the UI. You could split things up further, having one Task manage user input and player state, another to update game logic, another to render the game world, and a final one to display the UI. This basically breaks up the game loop into different Task objects, keeping things logically divided and pluggable. When a menu is displayed, an additional Task can be added to the list to show it. You can override the exisiting Tasks to display only the menu, or pause the game logic so that game world and existing UI are still displayed behind the menu but nothing is updating. Lots of different things you can do.

This system can be as simple or as complex as you want it. For a different perspective, take a look at Scott Patterson's article in Game Programming Gems 3: An Object-Composition Game Framework.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Partner Spotlight

  • Forum Statistics

    • Total Topics
      627667
    • Total Posts
      2978533
  • Similar Content

    • By Kurupted Playz
      Hey, I'm looking for some people that can help me with a game that I'm making that is a 3d platformer.
      I mostly need someone for character design and animation,  I can do some coding but if you can do coding as well you're still welcome because I'm still not the greatest at coding just yet.
      if you need to contact me add me on discord @ Kurupted#1206
       
    • By Jcyshadow97
      Hi,guys.I m working on a Fantasy RPG.Currently i m work alone on the project.I really need someone can make UI stuff.If someone can handle it please feel free to contact me on email: 270514974@libero.it.
      Thank you guys and sorry for my english.
       
       



    • By STRATUM the Game
      Hey, everyone! This is my first post here.
      I would like to know what you think about my project called STRATUM. It's a 2D platformer that is heavily based on storytelling and boss fighting while trekking through the world.

      Everything in STRATUM takes place in the first century AD, in a world that wraps our own universe, called  The Stratum. A parallel Universe that is the home of the Christian deities . In this game you will play as a Dacian warrior, unfamiliar with everything in this world, you’ll get to know and understand The Stratum together with him.
      The main thing that I want with STRATUM is to reinvent the known lore and history of the Christian deities and realms. 
      The story is unconventional, it plays down a lot of the mysticism of Hell or Heaven and it gives it a more rational view while keeping the fantastic in it. What do I mean by that? Well, think about Hell. What do you know about it? It's a bad place where bad people go, right? Well, that's not the case in STRATUM. I don't want to describe such a world. In STRATUM, there is a reason for everything, especially for the way Hell is what it is in the game. "Hell" is called The Black Stratum in the game.
      This world is not very different from Earth, but it is governed by different natural laws.
      The story will also involve the reason why this world entered in touch with ours.

       
      What do you think about all that I said? Would you be interested in such a game? I have to say that everything is just a work of fiction made with my imagination. I do not want to offend anyone's beliefs.
      I want this to be a one man game. I have been working alone on it (this was my decision from the beginning) from art to effects to programming to music to sound effects to everything.
      I also have a youtube video HERE if you want to see the way the game moves and the way my music sounds.
      Please, any kind of feedback will be highly appreciated. If you have something bad to say, do it, don't keep it for yourself only. I want to hear anything that you don't like about my project.
       
    • By LimeJuice
      Hi, it's my first post on this forum and I would like to share the game I am working on at the moment.
      Graphics have been made with Blender3D using Cycle as a renderer and I am using Unity3D. It's a 2D game, one touch side-scrolling game for iOS and Android.
      Here some pictures, and you can have a look to the gameplay on this video :
      Feedbacks ?
      And if you want to try it, send me your email and I will add you to the beta tester list!
       
       








    • By Kirill Kot
      An adventure indie game with quests in a beautiful, bright world. Characters with unique traits, goals, and benefits. Active gameplay will appeal to players found of interactivity, especially lovers of quests and investigations.
      Available on:
      Gameroom (just open the web page and relax)
      AppStore
      GooglePlay
      WindowsPhone

  • Popular Now