Why States - Must I? Should I?

[mwatt]

This question is directed at experienced JavaScript developers who have also written at least one Phaser-based game and have looked at the idea of using Phaser's State mechanism.

 

I have a couple of games that I keep toying with porting to Phaser.  As it is I have ported portions of one of them.  I like the idea of Phaser and everything I see going on around it.  However, I am a bit put off by "states".  They don't fit into my known JavaScript repertoire and they don't seem to be well explained by documentation or examples (this may have changed, I have not dug in to this topic lately).   To make a long story short ... they don't feel comfortable.  I think I can see how I can build games, even big games, without using multiple states.  However, since The Creator (aka Rich) chose to include them and indeed has espoused their use, I am afraid to go off half-cocked and not include their use in my architecture.

 

Now that you've had the preamble, here is the meat of the thing.  Is there a compelling reason for their use?  The only real reason I can see is a scenario in which your game consists of multiple environments and you want different resources loaded for different environments, and the ability to keep these loaded in memory.  Is that it?  Am I missing something?  Can I use an architecture based upon JavaScript objects and closure-backed modules and leave the states out and not be making a mistake?

 

Thank you for your time.

[Nambiar]

If you're building a game with only 2 screens (a play menu and the game itself), using states is not so important. But when the number of states (or screens) start increasing. such as an endscreen, a highscores screen, a credits screen -> managing these on a sprite by sprite basis gets cumbersome VERY quickly. Not to mention the readability that is lost and bug testing that is hampered.

 

Of course, you can use an architecture based upon JavaScript objects and closure-backed modules and leave the states out but states make it easier for new devs (like me) to make games quickly without having to learn anything more than basic JS. Also, for people coming to Phaser after having a read a book/article about Game Development usually are poised to use states since its a staple in the literature. 

 

Phaser does not advertise it enough but its impressive that it provides us with such an efficient state manager. 

[alex_h]

Not having built a project in phaser yet myself (but hoping to do so soon) I was also wondering about how states are intended to be used in phaser. My own approach for game building is to have a screen manager that controls the creation and destruction of screens (load screen, menu screen, game screen, etc). AmI right in thinking that what I term a screen is roughly equivalent to what phaser calls a state? My screens are DisplayObjectContainers though, perhaps a state is more abstract than that? I am aware of what a finite state machine is, but I'm not 100% clear on how phaser is using the 'state' terminology here.

[Nambiar]

AFAIK, Phaser uses states to denote these 'screens'. So when I switch from a mainmenu screen to a credits screen, phaser handles the disposal of the objects created in that screen. So, I can just say 

game.state.start('Credits') 

ANYWHERE in the Mainmenu code and not worry about all the tweens, sprites, groups, collision/input handlers, etc that I created (except music, i think). 

[alex_h]

Cool thanks, so it sounds like 'state' does genuinely correspond to 'screen' then. Cheers!

[Heppell08]

I use states religiously for a number of reasons. Not just for a main menu, credits etc etc, the boot is a pretty important piece for my games because inside the boot (before the game is loaded at the users end) you can scale, rotate and modify how the game can/should look for a multiple amount of devices. Not only that but having the ability to have a preload bar image animating the game actually loading and having the splash screen etc, they all make for a more polished and professional looking game$ this can be achieved without states but it makes for a lot of over complication without the aid of grunt anyway.

Either way, I'd highly recommend a state like set up, unless, like mentioned above, you don't need a menu, splash screen, preloadbar or scaled game dimensions and visuals.

[plicatibu]

In actionscript I used to have a game manager class and all screen classes received an instance of game manager (the listener) so I could control which screen would be show, which sprite were clicked and so on.

 

Now I'm finishing my first game made using Phaser and I like a lot the states. It simplifies the work I had with actionscript.

[StrykerKKD]

I started my own little game framework and the first thing that i made was a state machine.

It breaks up the code and the game to smaller parts. It's better to have ten smaller source code than a big one.

Not to mention you don't have to load every resources at the beginning of the game and the main file of your game looks more clean with states. 

[mwatt]

Thanks everybody for your replies - in particular Nambiar and Heppel08.

 

 @Heppel08 - I wonder if you might have the time to post a skeleton that illuminates the architecture you would employ for a typical Phaser project?  If you would be so inclined, I think it would be helpful for me and a few others.   I know we all have our own lives and if this is too onerous and time consuming for you then never mind.  In any event, thank you for your detailed answer.

[sleekdigital]

https://github.com/photonstorm/phaser-examples

 

Under "projects" you will see some examples that might help you there.  They have states such as boot, preloader, menu, game...

 

Also, I like this yoeman scaffold generator for a nice starting point...

 

https://github.com/julien/generator-phaser