Game states with global variables

[kingfisher]

Hey,

I'm currently developing a rpg game with phaser(I'm new to html 5 game developement). I did not use game states, because I didn't know of them

To change the level, I recall the create funkction, which works fine, but I have the feeling, that handling an intro, cutscenes, etc. would be much easier with game states.

I'm working with global vars inside the main class, which store data for the game. How can i transfer thoose vars to other states?

For example: I have the game class setup like that:

var myGame = function(ARGUMENT)
{
    var self = this;
    
    self.game = new Phaser.Game(jQuery(window).width(), jQuery(window).height(), Phaser.CANVAS, "game",{ preload: preload, create: create, update: update, render: render },true,false);
    self.map = [];
   ...
   function create() {
       self.game.state.add("state2");
       self.state.start("state2");
   }
}

now when I switch to the state2.js file I have something like this:

var state2 = function() {

    function preload() {
       //NOW HERE I WANT TO FILL THE "map"-Array from before
    }

}

 

Is this going into the right direction?

Can You help me with this task?

 

[mattstyles]

It's often easier (although not necessarily the best) to expose the Phaser game object as a global and attach global variables to it. You could do this with your own global namespace if your prefer.

You can be smarter and pass state to your functions (to avoid things like an uber object i.e. this principle) but it all depends how involved you plan on getting. For smaller applications it is often easier to have global state that you then mutate, using JS it almost always more performant to mutate singletons (global, or 'nearly' global objects) even if it can potentially open up some particularly nasty programming headaches later.

var game = {
  phaser: new Phaser.Game(...)
}

function create () {
  game.map = []

  startState()
}

function startState () {
  // game.map is available, via global, here
}

Exposing a `game` namespace here is purely to try and avoid name clashes (JS won't give you any hints if you try to over-write object methods so name clashes are always a real threat), if you check out the Phaser examples you'll see that using the Phaser.Game is exposed globally. It's up to you how you want to manage it.

Try to check out a few tutorials and see how they are structured. This one, for example, uses globals everywhere. I wouldn't necessarily advocate that but it is certainly the easiest way to get started with learning how Phaser works.

[kingfisher]

Thanks for your reply!
Performance is very important, since I want it to run on as many devices as possible, so I shouldn't use game states?

Thanks!

[mattstyles]

Yes, use the game states. I think Phaser passes a reference to each state (using `this`) which can be used to share variables across states, of course, you could use global variables, or store your variables in a global namespace, or, create a different abstraction that holds your global state (sometimes called a store or service in other frameworks).

I just quickly checked the examples and a few userland tutorials, looks like many people end up having `game` as a global so they can grab the Phaser initialised game instance. This is treated like a singleton, but I dont think there is anything in code to enforce this, but, seeing as you have control of your own codebase you could ensure it is a singleton or just know that it will be because you only create it in one place.

You don't have to use the Phaser game states, but, it makes sense that you do, little point in reinventing the wheel unless you have a good reason. Phaser uses an architecture that wants (dont think it requires it) 4 phases of your game, preload, create, update and render. This is a well-defined game and application architecture. I think the states simply add an abstraction that takes these component parts of an app lifecycle and compartmentalises them to defined states, and then adds a mechanism for adding them to your game and switching between those states (which I assume is a synchronous procedure, I'm also unclear where people perform a teardown of a state, presumably they handle this explicitly in whichever part of their code switches state).

States in computer science are often defined as setup->main->teardown, in Phaser parlance the preload & create go in the setup and the update & render loop happens as the main component of a state.

Most of the Phaser examples on the site forego the added complexity of states and effectively have one single state for the application (dont confuse this with actual state of the application, the actual state of the application changes whenever any variables change in the app) which highlights whatever the example is for. In practise most games are more complex than an example and have at least a few different game states i.e. loading (could be a blank screen), pre-game (maybe a menu, or just a start button), main game and complete/dead screen (this would normally lead back to the pre-game state, or simply allow you to restart the main game state).