Witch OOP Phaser choose? Witch makes the run faster?

[Salvatore]

Hi there little felas,

 

I stumbled upon two ways to code with Phaser in OOP. Each one are diferent in how to code, and in how to structure your game.

 

The first is the familiar http://codevinsky.ghost.io/phaser-2-0-tutorial-flappy-bird-part-1/

Let's call it "flappy tutorial".

 

And the second is the http://createdineden.com/blog/2014/may/01/multi-platform-games-with-phaserjs/

And this we call it "not-flappy tutorial".

 

Well, the flappy tutorial uses a simple and easy to understand way to structure the game. He uses the objects/classes ass a simple module of code to be added to the main code, without any complication and any work to think about.

 

In the not-flappy tutorial, I took a few seconds to understand how it works. He makes the object a extention of the Phaser.Sprite to determinate that object ass a sprite, and to add to the game, you have to add ass a existing object through Phaser.Game.add.existing and add the object ass a Phaser object.

Cool huh?

 

So, witch one of these ways make our game run smoothly? Take less time to execute?

 

May the force be with us, so we can live long and prosper...

[lewster32]

I'd probably go out on a limb here and say that coding style in the broadest sense won't make an appreciable impact on performance, as at the end of the day most of the heavy lifting is done in Phaser's update loops. What will matter is what you do in the update loops, and whether you use optimisation methods such as object pooling, culling and so on. It's not really as simple as adopting a certain type of faux-OO JS pattern.

[Salvatore]

I understand. But, my question is, if we added all objects to the Phaser.GameObjectFactory and add in the game ass a Phaser object will make the game less laggy.

[lewster32]

Phaser.GameObjectFactory as it stands only serves as a convenient way of creating new instances of objects; it doesn't offer any performance advantages (that I'm aware of) over manually creating sprites via new Phaser.Sprite. Extending the Phaser.Sprite object doesn't change the performance vs a normal sprite either until you start adding in your own routines, and then it's totally dependent on the optimisation of the routines, rather than as a result of the fact that it's extended.