Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Game states  (Read 2641 times)

0 Members and 1 Guest are viewing this topic.

N1ghtly

  • Jr. Member
  • **
  • Posts: 96
    • View Profile
Game states
« on: August 25, 2011, 12:27:05 am »
I'd like to know if it's a good design to have your class Game contain a stack of gamestates(with each it's own data and update and render functions) and make the gameloop check wether the state should be changed or not. I think it could be an efficient way of preserving different stated...

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Game states
« Reply #1 on: August 25, 2011, 03:36:07 am »
It's always a question of size.
When your game is really small, maybe you'll be able to put everything in one Draw and Update function and still have a nice overview between all those if-statements.
Okay I don't know how you handle diffrent states, but what you probably basicly do is use one method but react diffrent to the active 'state'. So why not exclude it?
Use for each state a own method, yes maybe you will this way have to init somethings more than with the other design, but making a abstract state-class of which other abstract classes can be deriven will help you minimize those repetion.
I recommend it for 'real' projects.  :wink:

I made myself some thoughts about preserving states, but didn't end up with some code just ideas, but maybe not the most efficient ones. :D

My idea was that there could be four data structurs:
- array/std::vector - containing loaded states
- queue - containing states to activate in the next update loop of the statemanager
- queue - containing states to deativate in the next update loop of the statemanager
- stack - containing the running states

So you should be able to deativate/activate any loaded state out of any state. (If you programm the statemanager right ^^)

Don't know if it will work or if it is any good. It would be my first own statemanagement system so I'm also new to this...  :?

But there is already implemented stuff like the GQE -> http://code.google.com/p/gqe/
Browse through the code to see how he's done it!

eXpl0it3r

EDIT:
I've seen that there's another similar discussion running here.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

N1ghtly

  • Jr. Member
  • **
  • Posts: 96
    • View Profile
Game states
« Reply #2 on: August 25, 2011, 11:03:52 am »
Thanks for the input!

I was thinking of having an array of pointers to game state.
I'd keep a variable to know which state to call, and when control needs to be passed over to another state, it can change the global integer currentState so that next time we loop, the next state would be called.
My only problem with this design was: what if i need to draw my game area in the background of the menu?

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Game states
« Reply #3 on: August 25, 2011, 11:54:14 am »
Then you'll have to think about two diffrent menus.
One that is the main menu, which gets shown in the beginning where no game is loaded and one that is build into the gamestate...
Maybe you could also let your statemanager draw two states at once and set a transparenty. Or you can give your states diffrent sizes.
Anyway it will complicate the thing and use performance, which on low-hardward pc isn't always that nice.  :wink:
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

MorleyDev

  • Full Member
  • ***
  • Posts: 219
  • "It is not enough for code to work."
    • View Profile
    • http://www.morleydev.co.uk/
Game states
« Reply #4 on: August 25, 2011, 12:27:26 pm »
Personally I tend and view things as tasks in a stack.

Each state is a collection of tasks, and as you push a state on top of the stack the tasks of the stack below it can decide either to suspend or continue. When a state is popped, all it's tasks are killed. You can obviously code in more fancy things too.

Tasks can be groubed by two additional properties: Process and Priority

- Process only matters if the program is multithreaded: Two tasks of process n are guaranteed to be running on the same thread whilst tasks of different processes may or may not, there are no guarantees.

- Likewise, tasks with the same process are guaranteed to be updated in order of priority (high -> low) whilst tasks on different processes aren't.

Some day I'll devise a more complex task system based around chaining tasks to execute concurrently (so you can say "Tasks X, Y and Z depend on Task A" and tasks X,Y and Z execute concurrently after A without interrupting the flow of any 'unlinked' tasks). Basically creating and scheduling "task trees"...Task tree! That sounds like a good way to implement it now that I think of it xD
UnitTest11 - A unit testing library in C++ written to take advantage of C++11.

All code is guilty until proven innocent, unworthy until tested, and pointless without singular and well-defined purpose.