How would you approach this

[jsantos]

Hi all,

This is a bit of a general question...

Imagine that you have one game/application of sorts, like this:

• one main menu with access to 9 different areas;
• each of those 9 areas has from 1 up to 4 different "games", with up to 4 difficulty levels (each with its own main image, instructions and so on);
• Any of those games can be started by choosing 1 of 19 possible "keys";
• ...

I'm passing the keys (that control images and so on) in a .json file and using localStorage to keep the player choices and direct it to the proper place.

My big question right now is: should I look at the 9 areas with different levels as being each a state inside a main project or should each be its own little project accessed by the main one? For example, main State (with Boot, Preload, ...) just for showing loader and main menu (plus help and so on) and have something like area01_game01_level01 state; area01_game01_level02 state, area01_game02_level01 state,..., area09_game01_level01; OR main, boot, preload... states and after the player choices are entered, again a main, boot, preload, etc...

What's easier to maintain and more logical? Pros and cons... And why?

Thanks in advance for all your ideas!

 

Ps - For the record I already have it running in a mix of phaser and plain JS (some games) but each has its own folder and there are BIG folders for html, js, etc...I just want to improve it and make it cleaner!

[Jackolantern]

I honestly think I would probably make each of the games separate projects. Since they seem to be discreet, the only real benefit of keeping them all in one larger "game" would be easy sharing of code assets, but if they are quite different there is not a ton of benefit there. You can of course still combine all of the graphic assets into graphic atlases or CSS sprites and load them all up-front. The loading time of the various Javascript files will likely be nearly trivial. 

Pros? I think it would keep each game lean and focused. It would allow your connecting pages and systems to be what they probably should be: standard web pages with the whole site setup as a standard web application. If players are mostly interacting with these connecting pages like a website where they see information and graphics, and click on icons or buttons to move around, then you will probably be ahead of the curve by simply making that a web page rather than bringing it into the Phaser game loop and managing all of that yourself. 

Cons? If you ever wanted to package this up as a native mobile app you will have to go with a solution that includes a DOM to power the standard web pages of your site. These of course do exist, but often these technologies tend to be all-or-nothing with either DOM or game engines. They either have a full DOM supported but are completely app-focused with little optimization for games, or they have no DOM at all and are completely game focused. By needing both, your performance for one or the other may suffer. Note that this is getting better, as I believe CocoonJS has implemented a DOM in their game-focused wrapper. 

[jsantos]

Hi Jackolantern!

Thanks for your answer!

As I was reading I was nodding to myself and saying "yes, that would be really nice and..." but I hit a (seemingly) wall... The objective is to wrap all in to an hybrid app. At the moment I'm using Intel's XDK with Cordova/Crosswalk... And I do share assets (images, sounds, sets of words,...) with all games. And I do want to create a separate file with all the GUI and common repeated stuff that I can just call whenever and from wherever I am. 

So... 

Do you still think it feasible with web pages and small independent games or one BIG thing with 19 plus states that are the small games?

Sorry for bothering.

Cheers!