Various Phaser 2 questions

[sonelliot]

Hi guys. First-time poster here. I used Phaser for our recent LD33 game:

 

http://ludumdare.com/compo/ludum-dare-33/?action=preview&uid=55213

 

Overall Phaser was pleasant to work with. I did run into a few gotchas though and I thought I'd consult the collective Phaser brain-space on the best way to tackle them in the future!

 

----

 

Question 1: How do you properly clean-up stuff when changing levels?

 

The design I used was to create a class (ES6) for every distinct game entity. These entities created whatever Phaser objects they needed in their constructors and updated them in their update tick. They also registered some signals to respond to user input. I would create these entities in the level state's create method. Unfortunately, I had to manually loop through all of my entities and call destroy() on their groups or kill() on their sprites when loading a new level. Is there a way to just destroy everything in the stage and re-populate it from scratch? I also had to de-register all of the signals I setup because otherwise we would see weird behaviour where invisible entities were firing shots after loading the new level.

 

The way Unity handles this is to clean-up everything in a scene when you load a new scene. If you want to preserve some state or objects between scenes you need to do this explicitly. This seems like a sensible approach to me, since you don't then need to clean-up everything you've created manually, which feels very c-ish to me haha.

 

Question 2: What is the 'proper' way to work with Phaser objects?

 

As I mentioned in Q1, my design was based composition: I created classes for my entities and then let them instantiate and manage their Phaser objects. I wonder, is this a good design for working with Phaser? Or is it better to extend (inherit) from the base Phaser classes, like Sprite etc?

 

----

 

Let me know what you think!

[drhayes]

1. If those objects are added to the world, switching states will destroy all children of the world. So there's one thing you could do.

 

In my game, I have one top-level group called "map" that has all the enemies, obstacles, items, etc. in it arranged in groups to maintain layering. I then blow away the contents of that group on level load.

 

If an entity has a handle to a resource it cleans it up itself, though -- there's no magic there. Event handlers count as resources.

 

2. I'm inheriting from the Phaser objects (primarily Sprite, of course) then decorating them with additional data. I was originally going to do it the way you did it, with a Player object that internally had a "sprite" property that was the actual Phaser.Sprite... but, ultimately, it felt like too much ceremony over just decorating a Sprite instance with my required properties.

[netcell]

If you create your own entity class to manage Phaser Display Object, you will have to explicitly destroy the object on state changes and there could still be some problem depends how you design your entity class. The reason you are having ghost is the callback hell problem of Javascript.

 

If you prefer your way, you can extend the Group to create an Entity class. Still, Phaser isn't designed to be used in entity way I suppose. I think a good Unity entity structure for Phaser would be using the common Phaser Display Object (Sprite, Image, Group) as the entity and decorate it with classes extended from a custom Decorator class that handle the connection similar to MonoBehaviour.

[sonelliot]

1. If those objects are added to the world, switching states will destroy all children of the world. So there's one thing you could do.

 

In my game, I have one top-level group called "map" that has all the enemies, obstacles, items, etc. in it arranged in groups to maintain layering. I then blow away the contents of that group on level load.

 

If an entity has a handle to a resource it cleans it up itself, though -- there's no magic there. Event handlers count as resources.

 

2. I'm inheriting from the Phaser objects (primarily Sprite, of course) then decorating them with additional data. I was originally going to do it the way you did it, with a Player object that internally had a "sprite" property that was the actual Phaser.Sprite... but, ultimately, it felt like too much ceremony over just decorating a Sprite instance with my required properties.

 

If you create your own entity class to manage Phaser Display Object, you will have to explicitly destroy the object on state changes and there could still be some problem depends how you design your entity class. The reason you are having ghost is the callback hell problem of Javascript.

 

If you prefer your way, you can extend the Group to create an Entity class. Still, Phaser isn't designed to be used in entity way I suppose. I think a good Unity entity structure for Phaser would be using the common Phaser Display Object (Sprite, Image, Group) as the entity and decorate it with classes extended from a custom Decorator class that handle the connection similar to MonoBehaviour.

 

Thanks for the feedback guys. It seems like decorating an existing Phaser class is the nicest, and simplest, way to go design-wise. As for the clean-up, it seems like I can probably get away with putting all of the objects I want to destroy in a single group, and then manually destroying them on level load. I guess I'll also need to keep track of the signals that they attach and detach them. This probably isn't too much of a pain if I adopt this strategy from the beginning. Thanks again for your help!