To simplify things, let’s say the player can choose to either build a Stable, a **Monastery **or a Castle.
I am stuck between these two different options. Which one is the recommended way to go?
OPTION 1:
I create a single blueprint, which I could simply call BP_Building. This blueprint would hold a StaticMeshComponent called MeshComp, and an integer called BuildingType (0=Stable, 1=Monastery, 2=Castle).
OPTION 2:
I create 3 separate blueprints: BP_Stable, BP_Monastery, and BP_Castle. Depending on which building the player wants to build, the corresponding Blueprint would be instantiated. [HR][/HR]
Since I’m a beginner I understand both ways are possible, but I think there might be a preferred way to go. Something that aligns better with UE4 design principles, if that makes sense. What do experienced UE4 game developers think?
I would go with 1 base building, and make the other ones child classes. As someone who played Age of Empires for a very long time and also used UE4 for very long, I imagine the concept going something like this:
BP_BuildingBase; has all logic to what other buildings can do, like spawn a class (BP_UnitBase as reference, this will be important later on), do upgrades, increase population, etc.
PlayerController would be used to control the game, since you’re not using a single character but can select any from the map (see default top down template as reference)
HUD widget with empty borders that get filled based on what building is selected, to give different options for each
For camera use a blank character class with only a springarm and camera, this will make it easier to move it around the map because of the movement component, just have the capsule ignore everything besides the floor and map borders
BP_UnitBase; character base class for units that can do anything, then have child classes be specified by using an enum (soldier, villager, etc.) and have them look different and use different stats based on what class they are
AI can be somewhat tricky, would probably have to be made specifically for RTS purposes with one overarching controller, as opposed to having each unit being their own thing
A somewhat similar example can be found in the learning tab “StrategyGame”, it’s a tower defense example but it does have different buildings (town center, canon tower, flame thingy, crossbow tower) and unit spawning.
You can use **Inheritance **to create a parent-child relationship whereby you have a parent building blueprint and then child blueprints that are derived from it for your Stables, Monastery, etc. This way, you can put logic common to all buildings like say, taking damage, activating UI for interaction, etc in the parent blueprint and all children will inherit those features automatically. The child blueprints can then focus on having specialized logic (as well as custom meshes) like spawning cavalry at stables, researching technologies at blacksmith etc.
You can also then go a step further & use Components (For further read: Component · Decoupling Patterns · Game Programming Patterns), which can be attached to your building classes to add additional functionalities. One example would be a component that contains the logic for spawning units, setting rally points, etc. The same component can be added to your Barracks, Stables, Castle, etc since the only difference will be in specifying the class of the unit to be spawned.
Thank you for your answer SB1985. Nice to meet an AoE fella My favorite game of all time. A new remastered HD version is coming out in a few days!
I read through the whole answer, and another question came to mind. As you know already, buildings and units can have like 10 or more different stats (health, attacking range, shield health, moving speed, viewing distance, etc etc).
If I decide to use one base blueprint (like your BP_BuildingBase or BP_UnitBase), where do I store these stats values? Moving to the C++ side of the game: should I create different classes/structs for each building type, with their constructors, member variables and functions, etc?
Apologies if my questions are too basic, I’m just starting out but feeling strong and excited about UE4.
Hey StormRage256, thank you for your detailed answer. I didn’t know about that webpage, will start digging deeper into those patterns. I will also take a look at inheritance.