# Initializing entities vs having a constructor parameter

I'm working on a turn-based tile-based puzzle game, and to create new entities, I use this code:

Field.CreateEntity(10, 5, Factory.Player());


This creates a new Player at [10; 5]. I'm using a factory-like class to create entities via composition.

This is what the CreateEntity method looks like:

public void CreateEntity(int mX, int mY, Entity mEntity)
{
mEntity.Field = this;
mEntity.Initialize();
InvokeOnEntityCreated(mEntity);
}


Since many of the components (and also logic) of the entities require to know what the tile they're in is, or what the field they belong to is, I need to have mEntity.Initialize(); to know when the entity knows its own field and tile.

The Initialize(); method contains a call to an event handler, so that I can do stuff like this in the factory class:

 result.OnInitialize += () => result.AddTags(TDLibConstants.GroundWalkableTag, TDLibConstants.TrapdoorTag);
result.OnInitialize += () => result.AddComponents(new RenderComponent(), new ElementComponent(), new DirectionComponent());


This works so far, but it is not elegant and it's very open to bugs. I'm also using the same idea with components: they have a parameterless constructor, and when you call the AddComponent(mComponent); method in an entity, it is the entity's job to set the component's entity to itself.

The alternative would be having a Field, int, int parameters in the factory class, to do stuff like:

new Entity(Field, 10, 5);


But I also don't like the fact that I have to create new entities like this. I would prefer creating entities via the Field object itself.

How can I make entity/component creation more elegant and less prone to bugs?

• Why would you rather create entities via the field object? Is it just personal preference or is there a practical reason for this? I'm afraid I have to tell you this makes little sense for an outsider on your application like me. May 14 '12 at 11:41
• @Koarl I'm using reflection to get entity parameters in my level editor (from the methods in the factory class). If I had to create an entity with x,y,field in the constructor I would have to add these 3 parameters to every single method in the factory class and somehow make them get ignored by the editor. Also, I may be totally wrong, but I find it weird to see a line starting with "new Entity(1, 2, field);" - I think the field is the most important object, and it should manage entity creation/destruction. May 14 '12 at 12:05
• If you have unusual requirements due to your level editor, you should mention that in your question because that is pretty important to know when answering. Also, if the design of your level editor is constraining some aspect of your core game, I would say the problem is the design of your level editor. I think you've got your priorities backward; the game is more important than the level editor. May 14 '12 at 13:20
• A level editor is hugely important, and having a good one can impose some special requirements on your engine. The entire purpose of a game engine is to run content; without content, theres no reason to even have a game engine. Never ever sacrifice the quality or effiency of your content generation tools just to simplify a game engine slightly! May 15 '12 at 16:55
• I agree that a level editor is important, but disagree that you should ever change the game to fit the editor and not the other way around. shrug philosophical difference I guess May 16 '12 at 11:18

If entities must have positions (which is implied, as your CreateEntity() call takes the position as a parameter), why not put the position into the Entity itself, and then pass the x,y coordinates to the Player Factory directly?