'Managing game states' is great if you need to change scenes (or scene managers) for different parts of your game
(i.e going from outdoors to indoors like in an adventure game)
But if your game is more like a simple application like the chess game or YAT(yet another Tetris Clone) were there is only one active window for the duration of the game, you will not need to bother with the whole State managment
I used up all my sick days, so I'm calling in dead.
Raven wrote:But if your game is more like a simple application like the chess game or YAT(yet another Tetris Clone) were there is only one active window for the duration of the game, you will not need to bother with the whole State managment
Just for correctness, both YAT and Chess make extensive use of state management. They just don't switch scene managers through it. I never really looked at 'Managing game states', but I suspect it's the same concept.
For developing simple games like these, I think it's fine to go with this approach and using Ogre directly.
There is no 'best' way. It all depends on what you're aiming to achieve.
If you want to make a small game quickly, without much focus on future modification, it's probably best to avoid being abstract and just use everything directly.
However, if you plan on either a big project, or one that is easily extendable and a pleasure to work with, then you'd want some abstractness.
A state system isn't *needed*, but it's very nice to have one. Personally I'm turning into a bit of a design freak as time goes by, so sadly even for a small project I find I can't help but go abstracting it all anyway.
Anyway, I suppose it all comes down to resources - how much time and effort are you willing to put in for results?
Walley wrote:There is no 'best' way. It all depends on what you're aiming to achieve.
Agreed!
Walley wrote:If you want to make a small game quickly, without much focus on future modification, it's probably best to avoid being abstract and just use everything directly.
However, if you plan on either a big project, or one that is easily extendable and a pleasure to work with, then you'd want some abstractness.
I'd say it depends how much time you need to get going with the "abstract" approach. If an engine provides you tools and frameworks which get you towards your goal (the game) faster then that might be worth a try rather building everything from scratch and, even more importantly, test and bugfix it yourself.
I find it easiest to have one frame listener that passes the events to the active state. That's the way it's done in the tutorial as well I think.
"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."
Douglas Adams
Well I’m trying to get a game loop together but I don’t understand how to do in ogre. I understand ogre from main() to initialize() but that’s about it.
Ogre is extremely object oriented. This means that the engine is already very abstract. I started out using Ogre in my engine in a very abstract way, and then scrapped it and started to use the API directly. Works fine, is very readable. In general I think Ogre is well enough designed from an OO standpoint that there is no need to build in extra abstraction. That is, of course, unless you plan on supporting more than one engine or something