Hi, I've been wondering I know that games are all about states right? So if there're states in a game and substates in each state, which is better, make 'em in a class or only in an enumeration?
Hi, I've been wondering I know that games are all about states right? So if there're states in a game and substates in each state, which is better, make 'em in a class or only in an enumeration?
What is really better is that you drop this states idea. Where did you get that!?
Please explain yourself better.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
I think he may be talking about a 'finite state machine.' It's a construct used for organizing AI. Basically, the bot AI transitions from one state to another based on existing conditions in the world and how it 'feels' (internal biases and preferences).
I have my AI setup to handle instructions, which is similar to a finite state machine, in that it has to transition from one instruction to another. You can make instructions be very high level or very low level. An example of a high level instruction could be 'go to next waypoint.' An example of a low level instruction could be 'disable internal state number five.'
So yeah, do an internet search for finite state machine.
I'm not immature, I'm refined in the opposite direction.
Well, I don't know the correct term of it. I just call them states. For instance: In my game I used this states in it:
1. Attract screen / Opening
2. Main Menu
3. Main Game
And in the Main Game itself there's substates such as:
1. Data Input Screen
2. Check Data Screen
3. Data Manipulation
4. Show Result Screen
BTW, my game is like a horoscope thingy.
In my games I placed them in an enumeration. So in the parts of the games (e.g. Event Handlers), I switched this enumeration like this:
That's what I did. But I've seen someone created a class to accomodate this. So what I wanted to ask was is it better to make it a simple enumeration or a class?Code:switch (mGameStates) { case ATTRACT: cekMouseClick(ATTRACT); doThings(ATTRACT); break; case MAIN_MENU: cekMouseClick(MAIN_MENU); doThings(MAIN_MENU); break; case MAIN_GAME: cekMouseClick(MAIN_GAME); doThings(MAIN_GAME); break; }
Thanks.
You could have a class that manages some function pointers that do certain things depending on the state of the game instead of checking for all of them.
http://www.cprogramming.com/tutorial/gamedesign.html
Covers this topic more or less (though brief, it hopefully gets the point across).
Search for the "Stack Method". It will be used to manage the gamestates.
This thread may be of interest: http://www.gamedev.net/community/for...age=1�
Also, your switch-case method (as it's called) is a perfect method for small projects.
Last edited by Sentral; 11-13-2006 at 02:33 PM.
Videogame Memories!
A site dedicated to keeping videogame memories alive!
http://www.videogamememories.com/
Share your experiences with us now!
"We will game forever!"
Thank you for all the replies.
>>Also, your switch-case method (as it's called) is a perfect method for small projects.
Yeah, I thought so too at first, but eventually my project became a monster and I've lost track of the state management. It evolved into a lot of lines in each case of the switch.
That's why classes are invented in first place. To simplify the code, and design.
So use a class.
lu lu lu I've got some apples lu lu lu You've got some too lu lu lu Let's make some applesauce Take off our clothes and lu lu lu