Coding model - every object is an "Entity"

[MegaLeon]

Hi everyone, I came up with a coding model for this small platformer I am making and wanted to check up with you what were your thoughts about it.

In this model, every object that the player can interact with is a children of the `Entity` class:

class Entity extends FlxSprite
{

 public function new(x:Int, y:Int) {
 super(x, y);
 }


 override public function update() {
 super.update();
 }


 public function interact(player:Player) {

 }

}

```

Entities are stored in a `_entities = new FlxTypedGroup<Entity>();` in the PlayState.

When the player collides with an entity, its `interact()` method is called:

```

FlxG.overlap(_player, _entities, interact);


function interact(player:Player, entity:Entity):Void
{
 entity.interact(player);
}

```

The `interact()` method of course would be different for each entity, so we'd have a `class Coin extends Entity` where interact would kill the coin and raise the score, a `class Enemy extends Entity` which would kill the player and so on. This makes the whole thing pretty modular.

When I want to add a new entry, I recycle one from the group and cast the correct class on it:

```

var coin:Entity = Reg.PS.getEntities().recycle(Coin);
coin.reset(i.x, i.y - 16);
_entities.add(coin);

```

The thing makes sense to me, however in every example I saw people seems to make up specific typedGroup for different objects (coins, enemies, so on)

To the more seasoned programmers, what are your opinions about this? What could the downside be? Am I about to run into a performance disaser?

[Junjo]

Having diferent groups for diferent object types makes searching one for recycling faster, I think (there are less objects in the group), but I don't think it makes a big difference... probably.

Aside of that, if you are defining "Entity" just to have that method "interact", without adding nothing new to FlxSprite, I think it would be more appropiate to create it as an Interface, not a Class, and make your game types to implement it.

[SruloArt]

* I think this is a simple Switch statement in the Player class that has grown way out of proportions :)

[MegaLeon]

I recently came back to this and still trying to wrap my head around the cleanest way to handle things. If I stick to the entity model I'd get interact() as a superclass function, plus doing things like storing which state the object belongs in so I can add stuff to it from that object without handling too many global variables. Every group will be a FlxTypedGroup<Entity> though.

```

Class Entity extends FlxSprite
 public function init(x:Float, y:Float, state:PlayState):Entity
 public function interact(player:Player){}


Class Item extends Entity
Class Enemy extends Entity


_items = new FlxTypedGroup<Entity>();
_enemies = new FlxTypedGroup<Entity>();


function collidePlayer(entity:Entity, player:Player):Void
{
 entity.interact(player);
}

```

The other option is to keep the interact() method in my objects but get rid of the entity superclass, have individual objects pools (does that make a difference in performance?), and run the collision function with a Dynamic object so that Haxe figures out the correct class to call interact() from - Although I've been reading on the Haxe communities that is advisable to avoid Dynamic. Also store a pointer to the PlayState in Reg and use that when I need to add new objects.

```

Class Item extends FlxSprite
Class Enemy extends FlxSprite


_items = new FlxTypedGroup<Item>();
_enemies = new FlxTypedGroup<Enemy>();


function collidePlayer(object:Dynamic, player:Player):Void
{
 object.interact(player);
}

```

What do you guys think?