jargon help, please - State vs Scene vs Stage vs World

[stvrbbns]

I'm completely new to Phaser and am coming to it from a general Web Development background. I need to be sure I understand a few of the terms/nouns used when defining/answering "What am I looking at/rendering?". Currently, it seems to me that:

• State (as in the StateManager) - the difference between booting, loading, login, main menu, tactical game map, full-screen mini map
• Scene - the difference between the tactical map when the player is in sector A1 vs. B1 vs. C1
• Level - really only related to game design and a subset of Scene changes
• World (Phaser.World) - little more than a container for everything in the game; mostly used to use the default Stage, bound the Camera, and potentially affect physics
• Camera - the portion of the Stage which is currently being rendered in Phaser's web browser element (e.g. using WebGL/canvas)
• Stage - the subset of the World which stores and controls renderable stuff

1. Am I correct that a tactical game map and a game minimap would be different State objects?

2. Going through the initial tutorial and looking at the paucity of World examples implies to me that the world is a relatively background object, only incidental to the game insofar as it is used as a method to bound the stage, camera, and physics. Is that really it, or is the World probably the key point to, for example, manage dynamically adding and removing data about nearby stuff in a particularly large game map?

3. Could a Scene be validly defined in the context of Phaser as "the set of things to be rendered"? If so, then what meaningful difference is there between a Scene and a World? Otherwise, is a Scene really more "about" the graphic/art/audio side of game design the way a Level might be mostly about the game mechanics, difficulty curve, and narrative flow? Looking at some videos of game creation with tools like Unity, "Scene" seems to have a fairly specific and technical connotation within the context of game design, but Google has not provided me any indication of exactly what that definition and connotation is.

I do see that the Phaser 2 docs don't reference "scene".

4. Are there terms I am missing that I should make sure I understand because they might not mean quite what I think they mean (e.g. I expect the verb "render" to approximately mean "putting stuff on screen", and the noun "view" to mean something along the lines of "view" in MVC).

[rich]

1) Think of States as being like chapters in a book. You'd work your way through one entirely, and when finished, move on to the next (i.e. Loader, MainMenu,, Level Select, Game, Game Over). I wouldn't use a State for a mini-map, that is an in-game element.

2) World is exactly as you say, just a container sat on the Stage. You can place elements above it (on the Stage, above the World group), for example UI. But otherwise that's it, World is just a Group in which everything lives.

3) There's no concept of a 'Scene' in Phaser itself (this is a game dev term, yes, but there is nothing in Phaser that uses it)

4) Camera renders the portion of the World currently visible, it doesn't render the Stage (all Stage contents are always rendered)

The other term you will want to get familiar with is 'Signal'. Phaser uses Signals internally for most everything. Their web dev equivalent are 'Events'. Instead of listening for events, you bind a function to a Signal instead. For example 'sprite.events.onInputDown' is a Signal.

[stvrbbns]

1) Is it strongly preferred to *not* go "back" to previous Phaser game States? For example, if dying on a level is supposed to send the player back to level selection, should the level selection and the levels themselves be coded into the same State, or is it fine to flip between game States?

Thank you very much!

[rich]

You can jump between States as often as you like, in any order you like. Just remember that they exist in isolation. One State knows nothing about another (unless you code it specifically to do so), and they cannot exist on the Stage at the same time either (well, that's not strictly true.. but for all intents and purposes, treat it this way)