Alternatives to Prototype pattern for Buildings

Question

Hope some of you have ideas for this. first I will describe the Task ahead and then go on with the my thoughts about solving it and what kind of problems I see.

1) I have a number of buildings. Their data is stored in a json file and contains stuff like name, price, maxHP, etc... all those static infos - This file can be changed or extended by additional types of buildings and my system should take them all, as long as there are no invalid data (negative health for example)

2) I need some kind of list of all buildings, that I can use to iterate over (for example to display all buildings in a build-menu)

3) I need to be able to place them somewhere and therefore create concrete instances of them in my gameworld

basically buildings can do different stuff in my game. they can create units, generate income, attack and other stuff.

my thoughts about solving it:

1) On loading my building.json, first the allowedActions of this building are looked at and the various components are added (e.g weapon component for shooting stuff) and then the actual data (like hp, damage, etc) is set and validated.

2) Currently to get a list of all my buildings and being able to place them somewhere, I do the following. on loading buildings, I actually create an instance of each of them in order to get a List of prototypes - this prototype list is then used everywhere, where I need to be able to iterate over them, e.g. buildmenu.

3) When I then want to build it, I kind of just clone this building and update the data specific to the new clone (e.g. its actual position) and add it to my game world

So basically I'm using some kind of prototype pattern, if I understood it correct. However I don't really feel comfortable to have a list of instances of my buildings that in reality don't exist in my gameworld and for which I always have to care, that they don't ever influence the actual game (like accidently they are iterated through in a list, when I want to do something to all currently constructed buildings in my game but this will also influence the prototypes, which i clone my buildings from but are not actually constructed)

Do you have other Ideas to solve this, or is using prototypes here the right thing to do?

Thanks for any advice Kind Regards

Answer 1

If you're uncomfortable with having building instances that aren't physically present on your map (though as pointed out above, this works fine and there's nothing "wrong" with doing it this way), you're only a few small changes away from using the Type Object Pattern instead.

Here the data you're storing in your JSON/iterating in your menus no longer represent "Buildings," but "Building Types." This contains only the information common to all buildings of that type:

• max HP
• cost
• visual asset
• actions it can perform

but no instance-specific data.

Then you have a separate type for your Building instances themselves, which reference their buildingType and add data that's specific to structures built somewhere in your world:

• building type
• position
• controlling faction
• current HP
• action components

Now you don't have to worry about accidentally writing code that's supposed to iterate one of these but feeding it the wrong list. The data has a completely different makeup, so strict type checking will catch this error immediately, and even with dynamic typing the problem should become obvious very quickly.

You'd move the step of attaching components to the instance to the moment when the building is placed in the world (since unbuilt building archetypes in your menus have no need of these components.

You could even extend this to additional types for other systems that need different views of building type data, like a BuildingButton type with disabled/cooldown state tracking to use in your menus, or a BuildingOption type that annotates the building type with info an AI player uses to select what to build when & where. Each of these still refer back to the same set of BuildingType instances for the core of the building's description, so that no one type has to handle all of these different use cases.