Have a look into the Builder Pattern. It wraps up all that complex construction for you.

Builders are best driven by some kind of external textual or binary map data file, from which are read in various shorthand specs for each entity.

So in other words with this...

class SoldierBuilder //singleton
{
     function build()
     {
       //encapsulates a bunch of object creations, some of which create their own subobjects, etc. in order to build this whole soldier
     }
}

you would do something like

for each (record in soldierToBeBuiltRecords) //comes from a data file
   builder.build(record)

Bear in mind that for instance you might have two different builders, a SoldierBuilder and a WeaponBuilder. Then the SoldierBuilder might utilise the WeaponBuilder within it's own construction code, in order to build weapons for the soldiers as spec'ed in the soldier data, aside from using other parameters therein to construct the soldier itself.

You can use the same builder both at level setup and during runtime. And you can use it for predefined (data-specified) entities, or dynamic entities whose specs your game logic may decide at runtime.

Have a look into the Builder Pattern. It wraps up all that complex construction for you.

Builders are best driven by some kind of external textual or binary map data file, from which are read in various shorthand specs for each entity.

So in other words with this...

class SoldierBuilder //singleton
{
     function build()
     {
       //encapsulates a bunch of object creations, some of which create their own subobjects, etc. in order to build this whole soldier
     }
}

you would do something like

for each (record in soldierToBeBuiltRecords) //comes from a data file
   builder.build(record)

Bear in mind that for instance you might have two different builders, a SoldierBuilder and a WeaponBuilder. Then the SoldierBuilder might utilise the WeaponBuilder within it's own construction code, in order to build weapons for the soldiers as spec'ed in the soldier data, aside from using other parameters therein to construct the soldier itself.

You can use the same builder both at level setup and during runtime. And you can use it for predefined (data-specified) entities, or dynamic entities whose specs your game logic may decide at runtime.

As for setting the distance between sprites, I guess that should be a distinct bit of logic coded in the way you want it. It doesn't really have anything to do with construction, but rather positioning in relation to existing entities. Your builder's focus should only be within the context of the entity itself.

Have a look into the Builder Pattern.

Builders are best driven by some kind of external textual or binary map data file, from which are read in various shorthand specs for each entity.

So in other words...

class SoldierBuilder
{
     function build()
     {
       //encapsulates a bunch of object creations, some of which create their own subobjects, etc. in order to build this whole soldier
     }
}

And then to use it you would do something like

for each (record in soldierToBeBuiltRecords) //comes from a data file
   builder.build()

Bear in mind that for instance you might have two different builders, a SoldierBuilder and a WeaponBuilder. Then the SoldierBuilder might utilise the WeaponBuilder within it's own construction code, in order to build weapons for the soldiers as spec'ed in the data file, aside from using other parameters therein to construct the soldier itself.

Have a look into the Builder Pattern. It wraps up all that complex construction for you.

Builders are best driven by some kind of external textual or binary map data file, from which are read in various shorthand specs for each entity.

So in other words with this...

class SoldierBuilder //singleton
{
     function build()
     {
       //encapsulates a bunch of object creations, some of which create their own subobjects, etc. in order to build this whole soldier
     }
}

you would do something like

for each (record in soldierToBeBuiltRecords) //comes from a data file
   builder.build(record)

Bear in mind that for instance you might have two different builders, a SoldierBuilder and a WeaponBuilder. Then the SoldierBuilder might utilise the WeaponBuilder within it's own construction code, in order to build weapons for the soldiers as spec'ed in the soldier data, aside from using other parameters therein to construct the soldier itself.

You can use the same builder both at level setup and during runtime. And you can use it for predefined (data-specified) entities, or dynamic entities whose specs your game logic may decide at runtime.