Jump to content

Help! drowning in game confusion


Recommended Posts

I'm just starting out with both phaser and javascript, so please forgive the seriously basic stuff I'm just not getting :-S


I suspect my problem stems from tutorials and examples loving to name the Phaser.Game instance as "game":

var game = new Phaser.Game(800,600,Phaser.AUTO);

Initially I was fine and thought I was flying with my coding... until I started modularising my code and attempted to make proper use of "this" in my different states.


I then started seeing a mish-mash of: 

game.<somePropertyorMethod> this.game.<theSamePropertyorMethodAgain>  this.<theSamePropertyorMethodYetAgain> 

sometimes even within the same method!!


Am I just an innocent (and yeah ok ok - finicky and pedantic) victim of example code being built from cut n paste code or am I missing a key piece of info (as in when its best to use which)?


Through trial and error I discovered the 3 call types above result in the same thing due to:

1. the variable "game" being used and declared at top level 

2. each state being automatically given a property called... drumroll... "game" (as well as some others such as "load", "world", "scale" etc.)


I know changing the property name to something else would be bonkers this far down the line, so my plea is simply to those who write examples and tutorials - please please please stop using a variable called "game" since it has (in combination with my stupidity) totally held me back in understanding wtf is going on... unless of course I'm still getting it wrong? :-S


To check whether I am... if I call 


where myGame is the variable holding the Phaser.Game instance, and then reference "this" in the js file that holds the particular state object - what would "this" be? the Phaser.Game instance or the state object?   


Thanks, and again sorry if this is fundamental stuff I should know.





Link to comment
Share on other sites

In that case 'this' should refer to the state object... I think you already understand it, you're just assuming you don't !

Consider this pure JS example:

function Something(game) {var x=1; // localthis.y = 2; // a property of Somethingthis.game = game // another property of Something}game = 'a game'var s = new Something(game)console.log(s.x) // undefinedconsole.log(s.y) // 2console.log(s.game) // 'a game'

however it's worth noting a few things:


new State()
This is a base State class which can be extended if you are creating your own game. It provides quick access to common functions such as the camera, cache, input, match, sound and more.


"quick access"....


now let's look at the StateManager code


link: function (key) {        this.states[key].game = this.game;        this.states[key].add = this.game.add;        this.states[key].make = this.game.make;        this.states[key].camera = this.game.camera;        this.states[key].cache = this.game.cache;        this.states[key].input = this.game.input;        this.states[key].load = this.game.load;


that means in a state you can write


this.load rather than this.game.load


as per the example here:



TopDownGame.Boot.prototype = {  preload: function() {    //assets we'll use in the loading screen    this.load.image('preloadbar', 'assets/images/preloader-bar.png'); // you could also use this.game.load.image  },  create: function() {    //loading screen will have a white background    this.game.stage.backgroundColor = '#fff';

it's the same thing, but logically it makes more sense to read... you're loading the image into the state, so why not write it like that?


there's also the fact that there's a smaller protoype chain to walk i think so performance is better...  http://jsperf.com/prototype-chain-speed/2


ie this.input should be faster than this.game.input i think, even though they eventually point to the same thing


hope this helps



Link to comment
Share on other sites

and then reference "this" in the js file that holds the particular state object - what would "this" be? the Phaser.Game instance or the state object?   

Well, you sort of answered it yourself :) As jmp909 stated correctly above, this would refer to the state object. 


I agree that Phaser dynamically linking the core references in the Phaser.Game object to the Phaser.State object can throw some people off. But as jmp909 above again remarks, it does have benefits. For me, I prefer to explicitly reference the loader from the game object (e.g., this.game.load) as opposed to through the state object (e.g., this.load) because it helps me to be explicit where all the core modules are coming from. 

Link to comment
Share on other sites

Ah thanks guys, really appreciate it!

I do this a lot, confusing myself unnecessarily because I don't trust my own understanding - a result of developing coding cynicism over the years from bug fixing other peoples work I guess  :blink:


I suppose I was mostly worried that there could be subtle differences between the properties and didn't want to just assume they were the same in all cases, and it has only been sheer fluke that I've gotten away with it so far (I suppose this could still be true if any of the properties are overridden locally for example).


With that then, I'll get back to coding!

Thanks again

Link to comment
Share on other sites


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...