Which one is better? An object method or a function.

[yltang]

Newbie to Phaser ;-)

 

I notice that, in most of the Phaser examples, functions tend to be written as methods of the state object. For example,

var main = {   ...  update: function() {    this.platforms.forEach(this.wrapPlatform, this);  },    wrapPlatform: function(platform) {    ...  },};

Why don't we make it a function as follows?

var main = {   ...  update: function() {    this.platforms.forEach(wrapPlatform, this);  },};function wrapPlatform(platform) {  ...};

In such an arrangement, the length of the code of object 'main' will be significantly shorter. And the code looks cleaner, also, not so many "this.". Is there any reason or benefit writing the function as an object method? Or which one is better? Thanks.

[Skeptron]

I'm not sure there is any performance difference, I'd say it's up to you really. I like to decouple things, so I wouldn't add functions to a State which are not state-related, to put them into other, appropriate objects instead. But it really depends on the use-case and your coding preferences.

 

In your example, maybe it would be better for the code understanding to have a "MapGenerator", "MapElementsFactory", or even "PlatformManager" object which could "wrapPlatform"s, as it is not really the State's role to do so. It happens in the state, but it's not the state's responsibility. But the first snippet of code is not particularly ugly either. Most of the time in JS, what works is what's good.

[yltang]

Nice thought.

Would you elaborate more about what you think are the responsibilities of the state? I don't seem to be able to identify them easily. Taking my code snippet as an example, suppose that "wrapPlatform" is a function to bring back the platform that is moving out of the game world. Is it one of the responsibilities of the state, or it just happens in the state?

[AzraelTycka]

Hello,

 

there is usually more reasons for this.

 

1. One is encapsulation, when you keep methods/functions in context of object which uses them. It jus keeps things clear what is used for what, just google details, it's a common them in programming.

 

2. Other thing is that programmers tend to keep global environment as clean as possible. You can google on this topic, you will get tons of reasons for global vs local variables (I'm not saying global variables are evil, if you meet posts which say they are evil then just leave it and read something else).

 

3. Ops I was talking about a different function declaration here.

 

4. There is programming style called functional and object oriented, you don't need to go only one way, but some people like it more one way or the other ;-).

Edited October 21, 2015 by AzraelTycka

[Skeptron]

Nice thought.

Would you elaborate more about what you think are the responsibilities of the state? I don't seem to be able to identify them easily. Taking my code snippet as an example, suppose that "wrapPlatform" is a function to bring back the platform that is moving out of the game world. Is it one of the responsibilities of the state, or it just happens in the state?

 

To me it's not the State's role but rather some kind of "Map"/"MapManager" role. Because if your state starts to manage platforms that get out of screen, then it should as well handle any player out of screen, fireballs out of screen, birds out of screen, particles out of screen etc. And your state turns into a huge, massive mess.

 

Let each object manage the way it should behave out of screen. For example, you might want to make the platform go back into the screen but you might want to destroy() a fireball once not visible.

 

Your state's role is to spawn the objects in the scene,  not to say how they should behave

[drhayes]

There's no performance difference between "var thing = function() {}" and "function thing() {}". The second one sets the functions "name" property so you get nicer stacktraces, but that's about it.

 

Variables in JS get hoisted to the top of the functional scope (unlike most block language like C or Java), so that variable in the inner loop isn't getting initialized every time, it's just getting re-used from its surrounding scope. There *is* some truth to making use of "local" vars in a function vs. making JS traverse a bunch of objects (i.e. using "names.that.look.like.this" everywhere vs saying "var thing = names.that.look.like.this;" and using "thing" everywhere), but, even then, most JS engines will optimize that away for you.

 

But, yes, those kind of micro-optimizations are usually not the problem in JS games. Besides controlling what you draw and trying not to draw too much, it's all about how many objects you create each frame since that puts pressure on the garbage controller and it will stop the world to clean up memory. Don't make lots of anonymous functions, don't create lots of objects or arrays to pass as arguments to functions or as return values. That kind of thing.

 

As for code organization, I would say "put it where you know to look for it". If it makes sense to you that a method would be on a state then put it there; otherwise, don't. I break things into smaller pieces so that each piece is responsible for one thing as much as possible so that I know where to look when I want to change how that one thing works. E.g. I have a "shooting" manager that is responsible for how everything in the game shoots. Similarly for explosions, and the tile map, etc.

 

But I don't think there's a "best" way other than "do it the way you need to in order to finish your game". That's the #1 priority, right?

 

Wow. This post was kinda grumpy.