Sign in to follow this  

Unity Game States Without a Stack

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

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

This topic is 4391 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.

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  

  • Forum Statistics

    • Total Topics
      628738
    • Total Posts
      2984464
  • Similar Content

    • By INTwindwolf
      THE PROJECT

      INT is a 3D Sci-fi RPG with a strong emphasis on story, role playing, and innovative RPG features such as randomized companions. The focus is on the journey through a war-torn world with fast-paced combat against hordes of enemies. The player must accomplish quests like a traditional RPG, complete objectives, and meet lively crew members who will aid in the player's survival. Throughout the game you can side and complete missions through criminal cartels, and the two major combatants, the UCE and ACP, of the Interstellar Civil War.
      Please note that all of our current positions are remote work. You will not be required to travel.
      Talent Needed
       
      Unity Engine Programmer
      Website Administrator
      3D Animator
      We have made great strides in the year 2017! INT has received a comprehensive face-lift compared to the start of the year. We look forward to a productive, fruitful year 2018!
      Revenue-Share
      This is the perfect opportunity to get into the game development industry. Being an Indie team we do not have the creative restrictions often imposed by publishers or other third parties. We are extremely conscientious of our work and continuously uphold a high level of quality throughout our project.
      We are unable to offer wages or per-item payments at this time. However revenue-sharing from crowd-funding is offered to team members who contribute 15-20 hours per week to company projects, as well as maintain constant communication and adhere to deadlines. Currently the crowd-funding campaign is scheduled for the year 2018. Your understanding is dearly appreciated.
       
      Thank you for your time! We look forward to hearing from you!
       
      John Shen
      HR Lead
      Starboard Games LLC
    • By Apollo Cabrera
      Energy particles being harnessed by collection multi-hedron energy matrix. Whuuuttt?
      Love it :)
    • By AndySv
        Total Music Collection (http://u3d.as/Pxo)   THE COLLECTION CONTAINS:   Mega Game Music Collection   Universal Music Collection   Huge library of high quality music for any project! All at an incredibly low price!   - 2,5GB of high quality audio - 100+ different music tracks - Loop and short versions   Action, fantasy, casual, horror, puzzle, epic, dramatic, romantic, positive, inspiring, motivational and more!
    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064

      View full story
    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064
  • Popular Now