Game States: switch statement verses Stack
Author
oh, also, through a bunch of reading I've been doing lately, i've noticed alot of books use functions to represent states, but wouldn't it be cleaner to use classes?
To start with, just so you know, x vs y post tend to be looked down upon. Have a quick review of the Forum FAQ when you next get chance.
Really it comes down to what you want to do. If you looking to create something extensable and reusable for large projects then yeah Classes would be better. But when you really think about it, how big are your projects going to get?
If you want to get something (a game or demo) done then there is nothing wrong witht the switch statement. Maybe tidy it up a bit with functions, might also make it easier to maintain. But there is no right or wrong way to do it really, just what ever fits your time frame.
I was looking at doing what your doing, but after spending a couple of days figuring it out, i thought 'in the same time frame i could have done lots of other useful stuff'.
Really it comes down to what you want to do. If you looking to create something extensable and reusable for large projects then yeah Classes would be better. But when you really think about it, how big are your projects going to get?
If you want to get something (a game or demo) done then there is nothing wrong witht the switch statement. Maybe tidy it up a bit with functions, might also make it easier to maintain. But there is no right or wrong way to do it really, just what ever fits your time frame.
I was looking at doing what your doing, but after spending a couple of days figuring it out, i thought 'in the same time frame i could have done lots of other useful stuff'.
The opposition is not "switch statement" versus "stack", but rather "finite state machine" versus "stack". The answer to this is to use the simplest of the two if it's enough for your purposes (this is generally a finite state machine), and use the more complicated one if you actually need it. It's perfectly possible to convert a finite state machine to a stack at a later point in development if you need to, simply by adding the relevant code to the relevant states, so I would suggest you start with a finite state machine anyway.
Concerning the use of functions versus the use of classes, don't forget that functions are objects in the object-oriented sense, as much as classes are. They are just objects which come with a predefined behavior and are instances of a predefined class (that depends on their type). If the predefined behavior doesn't suit you, then you can use classes to further customize it, but there's no point in customizing the behavior of your functions if the default behavior is sufficient. Of course, the question of whether the default behavior is sufficient, remains open.
Concerning the use of functions versus the use of classes, don't forget that functions are objects in the object-oriented sense, as much as classes are. They are just objects which come with a predefined behavior and are instances of a predefined class (that depends on their type). If the predefined behavior doesn't suit you, then you can use classes to further customize it, but there's no point in customizing the behavior of your functions if the default behavior is sufficient. Of course, the question of whether the default behavior is sufficient, remains open.
Some random, related thoughts:
- A switch is simple and easy to do, requires minimal boilerplate and is hard to get wrong. If you just need something simple (like whether an enemy is idle or attacking) then this will work just fine.
- A state machine involes a bit more overhead, because you've got to define interfaces and you've got the supporting code to run it, but with the run and return successor method it is a very elegent solution. As an added bonus it's easier to extend as you just need to add a new state class, and the actual running code doesn't need to be modified (unlike a switch, where you've got to modify the switch statements).
- If your states have a lot of different member variables then a state machine is probably better as you avoid problems with uninitialised and stale values. Eg. if you've got AI state for idle and attacking, and the attacking state has all sorts of pathfinding information then you've got to be careful to reset this when moving from idle to atttacking each time. Using a state machine means you can put it as class member variables and have it automatically reset for you and cuts down on bugs.
- I've tried stacks of states for various things and always found them to be more of a hinderance than a help, and makes it difficult to follow the flow of code. YMMV.
- A switch is simple and easy to do, requires minimal boilerplate and is hard to get wrong. If you just need something simple (like whether an enemy is idle or attacking) then this will work just fine.
- A state machine involes a bit more overhead, because you've got to define interfaces and you've got the supporting code to run it, but with the run and return successor method it is a very elegent solution. As an added bonus it's easier to extend as you just need to add a new state class, and the actual running code doesn't need to be modified (unlike a switch, where you've got to modify the switch statements).
- If your states have a lot of different member variables then a state machine is probably better as you avoid problems with uninitialised and stale values. Eg. if you've got AI state for idle and attacking, and the attacking state has all sorts of pathfinding information then you've got to be careful to reset this when moving from idle to atttacking each time. Using a state machine means you can put it as class member variables and have it automatically reset for you and cuts down on bugs.
- I've tried stacks of states for various things and always found them to be more of a hinderance than a help, and makes it difficult to follow the flow of code. YMMV.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
