Architecture Question

[strawlion]

Hey All! I recently started using Phaser and am loving how easy it is to use. 

One thing that's been bothering me is that I'm finding that I have to use hacks to organize the code in a scalable way. For instance, I have an enemy class that, when destroyed, should drop an item that the player can pick up.

So in the enemy class, I spawn the item on the enemy destroyed event. This is ok, working as expected. However, it appears there's no easy way to perform collision detection with the player at this point.

Is the only workaround to add all of these items to some global group and manually perform the collision detection? I seem to recall Unity would fire an event on any physics object collision, so these events could be handled within the sprite classes themselves.

Any advice would be appreciated!
 

[Cirno]

How about try this
 

item.enableBody = true;item.physicsBodyType = Phaser.Physics.ARCADE;

[Skeptron]

 I seem to recall Unity would fire an event on any physics object collision, so these events could be handled within the sprite classes themselves.

Wouldn't that lead to huge performance loss?

 

The solution you mention makes a lot of sense. You could even code our own Sprite class, extending Phaser.Sprite, and in its constructor automatically add it to a collision group. And you could even make it more specific : having several Sprite child classes, to put the objects in different collision groups (BulletSprite into bullets group, Map Sprite into map group etc.)

[drhayes]

I do what Skeptron says. In a game I'm working on I stick the global-ish groups on the game instance so other things can get at them: enemiesGroup, playerGroup, particlesGroup, etc. So when an enemy dies it can add something to the pickupGroup because it's available on the game instance.

 

If that's too distasteful, you could also add the item to the enemy's this.parent before you kill it.

[strawlion]

Wouldn't that lead to huge performance loss?

 

The solution you mention makes a lot of sense. You could even code our own Sprite class, extending Phaser.Sprite, and in its constructor automatically add it to a collision group. And you could even make it more specific : having several Sprite child classes, to put the objects in different collision groups (BulletSprite into bullets group, Map Sprite into map group etc.)

Yes, it would certainly be less performant. I only used Unity briefly, but IIRC you could opt out of that behavior. I'm sure they use a more sophisticated algorithm than straight bounding sphere collision (only checking collisions in subregions etc... not too familiar with how game engines usually implement this  ). 

It would be nice to have the ability to enable this kind of behavior only for specific object types. IE I specify to always check collisions between player and items, and a handler specified in both Item and Player classes gets called on collision. Since I'm doing this manually every update tick anyways.

Anyways, thanks for the suggestion. I think placing these in groups within the constructor is the way to go!

For reference:

http://docs.unity3d.com/ScriptReference/Collider.OnCollisionEnter.html