Phaser states and JavaScript

[BrunoHautenfaust]

I've seen some tutorials about game states and after incorporating their ideas, I began wondering about a few things.
We have the following:

    Game = {}; // An object    Game.Boot = function(game) {}; // A function    Game.Boot.prototype = { // An object    preload(){        this.load.image(...);        game.load.image(...);    },   create()    };

1/ Why does  Boot  have to be a function?

 

2/ I can write directly  Game.Boot = { preload(), create() };  which becomes and object and everything still work fine. Is the prototype just a good practice in this case? Signifying that maybe, at some point in the future, we would want to inherit from  Game.Boot.prototype?

 

3/ The parameter  game  is passed but everything works fine without it. Then why pass it?

 

4/  game.load  loads/attaches stuff to game and this.load attaches stuff to  this  which is Game.Boot.prototype, right? Both are fine even at the same time. Does it really matter what I will use?

[shohan4556]

I am replying  the 2nd question, yes everything is working fine without the param game but its not a good practice yesterday I got a problem about this and its waste my all that day here is the post link http://www.html5gamedevs.com/topic/18705-unable-to-instantiate-phaser-object-in-intel-xdk/#entry106124

 

and why should you use 'prototype' ? , because in a nutshell its not instantiate your game object manytimes  it only do it once, for better understand visit the link http://stackoverflow.com/questions/8433459/js-why-use-prototype

[Skeptron]

I'll try so answer as well as possible but I'm not a JS expert. Anyone better than me, please don't hesitate to correct me!

1) To me the need for a function is to create a constructor. This way you have a clean way of making a new Game.Boot(...) and pass parameters for initialization

2) http://stackoverflow.com/questions/8433459/js-why-use-prototype

3) Parameter game is mandatory for almost anything, it's just that you don't necessarily see it because Phaser hides it into the Game State object. When you do this.load.image(), in reality you do this.game.load.image(). So yes, you need the game to do loading.

4) Again, doing this.game.load and this.load is exactly the same thing (Interphase covers Game states quite deeply, and explains this shortcut).

[BrunoHautenfaust]

I'll try so answer as well as possible but I'm not a JS expert. Anyone better than me, please don't hesitate to correct me!

1) To me the need for a function is to create a constructor. This way you have a clean way of making a new Game.Boot(...) and pass parameters for initialization

2) http://stackoverflow.com/questions/8433459/js-why-use-prototype

3) Parameter game is mandatory for almost anything, it's just that you don't necessarily see it because Phaser hides it into the Game State object. When you do this.load.image(), in reality you do this.game.load.image(). So yes, you need the game to do loading.

4) Again, doing this.game.load and this.load is exactly the same thing (Interphase covers Game states quite deeply, and explains this shortcut).

 

OK, if I'm not planning on making another Game.Boot, it doesn't matter if I'll use a prototype then. Because when the program loads, it calls and creates the state only once, right?

3/ Isn't the Phaser state object the parent of everything inside it? Because if it is, then shouldn't 'this' refer to Game.Boot.load(...)? 

I don't know. It sounds to me like I should go over the JS OOP again.

[drhayes]

Take a look at the StateManager's add method. It explicitly handles each case: is this an instance of (or child instance of) Phaser.State? Is it already an object? Did someone hand me a constructor function that I should instantiate and pass the "game" instance to?

 

Here's the link function. It assigns all the goop that makes a state a state. That's how come it doesn't *quite* matter if you derive from state, pass in a random constructor method, or just pass an object... the StateManager will populate all those properties for you.

 

This grants you a tremendous amount of flexibility in how you make your states. You're correct that your states could just be object literals created when your JS files get parsed (var boot = {create: function() {}, ... } and you'd be good.

 

Now imagine that you have a separate state for each level in your game and you don't know what those levels are until you've loaded a config file in your preload via "load.json". Once you have that config file you could instantiate several states that all get passed the level info and add them, one-by-one, to the state manager. That's one reason you might need a real, actual-factual constructor -- to pass in custom per-state information. *Then* you could add those objects to the StateManager.

 

Answering your questions in light of all that...

 

1. It doesn't have to be, but it *could* be if you think you need it.

 

2. *Maybe* inheritance, but I think instantiating it yourself with custom params is a more useful case to think about.

 

3. Why not? But seriously, the State constructor doesn't require it. But maybe *your* specialized constructor logic does. So the StateManager gives it to you, just in case.

 

4. No difference but the typing. "this.load" is shorter than "this.game.load" but the same as "game.load". Whichever you want.

 

Your last question, "then shouldn't 'this' refer to Game.Boot.load(...)?" Not quite. "this" always refers to an object, not the function. This can be confusing in JS because any ol' function can be a constructor. In this case, the object you have a reference to after instantiating "Game.Boot" by calling "new Game.Boot()" somewhere is "this" inside "Game.Boot.load".

[BrunoHautenfaust]

Thanks, drhayes, that made sense. To tell you the truth, I don't have the habit of going into the source code of an API that much. But I should. Because most of the time I stick with the documentation and it's not always clear enough.

[drhayes]

You're welcome. I'm a fan of the Phaser source. Pretty clear, nicely commented.

 

As someone cornier than me once said... "Use the source, Luke!"