Room Loader is component for select room and load background and room logic.
Items Loader is component for create items for a specific room.
Music Manager is component for preload/play/pause music for a specific room.
Char Loader is component for create chars for a specific room. Chars can be player (playable) or NPC.
Particles is a component for ParticleEmitters for items/characters.
What would be a good way to organize all this?
The Phaser examples I see are very small and have everything in the same file. I understand that all blue boxes extends Scene, and it has to be the same Scene so that the camera can interact correctly with them.
My suggestion would be to have your 5 scenes that you have in life cycle extend Phaser.scene. Then in your more complex game scene create instances of all your other classes such as your room/items/music loader and pass them a a reference to the game scene through their constructors. They do not need to extend Phaser.scene as they all need to just alter the game scene.
I agree with @funnythat - I would have all of those blue boxes as classes that your Game Scene interacts with, in order to build-up the game display, handle room movement, etc. They don’t sound like scenes to me, but game systems.
Your Grey boxes are what I call game phases – to avoid confusion with Phaser terminology. Your blue boxes are “things” (or as the “smarty-pants” say objects) in your game. Everything could be a “module” (a separate JS file) which would be consolidated into one monolithic file when you’re ready to release to the apps stores.
What’s cool about Phaser III is you can have multiple “scenes” inside a single game phase. I like to think of them as “Flash MovieClips” is that helps?
Some of your blue boxes are “visible” things, others are “data things” or JSON outputs from your backend database. I like to separate “what is seen” from “meta-data” about it. Perhaps this might help …
{width:80%}
Manager files are a custom class that export a new object.
RoomManager preload scenary and items data, current player and scenary music.
PlayerManager preload player, animation and input controls.
ItemManager preload items and build Item instance
Item a custom class for every item
Features files are a custom function exported and injected on class Items that have this behaviour (for example, a bubble item have a fly behaviour, a tree item not have a fly behaviour)
I appreciate any comments or suggestions for improvement.
I’m especially interested in improving the organization of code and files.
If you thought “code2flow.com” was great … you simply love “StarUML.io”. I use version 2 because It will write OOAD/OOP classes into JavaScript; I merely draw my class relationship and WHAM, I get the JS code. Nothing is more simple than this “forward engineering”!. (There’s also an extension for Typscript too) All my students use this because it also generates documentation for their SQL and advanced SQL Security courses. It just “Boogles” my mind why software engineers can’t write documentation when the tools are available to build documentation website is MarkDown.
