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
//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
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.