FlyingMongoose here in my first development blog. I am the current Game Designer, and lead Programmer on our project Brel and I'd like to provide a little insight on our workflow process.
Ultimately every projects starts with a game design, and while I'm not going to go over the details of game design in this blog (that's for the game designer blog), there are some key components to think about when it comes to implementing the code based around the game design before you even start writing a single line of code, so I'm going to provide a little preview into our minds on that thought right here and right now utilizing our building outline and because we are utilizing Unreal Engine 4 (UE4) we also are going to be utilizing the terminology used therein, so bear with us on that.
We have 8 unique buildings and 4 unique upgrades in our initial release plan and intend on more to come later. This is actually quite a bit of work, but we can ease a bit of work off of ourselves too. Each building, according to the UE4 is considered an Actor and these types of classes are defined as "Something that can be spawned into your level or game" (or something like that, I can't remember exactly what the documentation says). In UE4 every actor that spawns is considered an instanced actor, or instantiated, this means all buildings can share one base Actor Class.
Before we even start on writing our actor class we need to decide what is universal to all buildings that we can place in this Base Actor Class, it seems simple enough but it requires a bit of brainstorming. Well, here's an easy one, Building Health. Okay great, the building health can be a privately stored variable in the base actor class that can be accessed utilizing Getters and Setters, these are functions that allow you to get, or set a variable that is Private to a class, more on that later. How about mesh, this is also known as model, this is the static mesh/model that will decide what to show to the players, well that makes sense. We also need to know the team the building is on, the player that built it, as well as the player's class (we have a particular player/class building system that is a bit unique that I will not go into details here because this is something that sets us way apart from others). Why not how much it costs to build? It's rotation and location in the world, is there an upgrade attached or not, how about it's scale? This one may seem a bit silly but we have an animation in mind that will need this variable. Why not give it an "is alive" boolean variable too? Or, even something more universal, a "STATUS", maybe with status variables that indicate building, built, being damaged, damaged, or destroyed.
As you can see there's quite a lot to plan out before we even start writing a single line of code.
So, just to finish this off, I'd like to explain what getters and setters are a little more in depth as I mentioned them before.
A "getter" in programming is a function that grabs and returns a value.
A "setter" in programming is a function that sets a value on something else.
Why do we need them? Well, there's a few reasons, one of which is "security in your code", if you expose things like, building health to the "public" in your code this means anything that utilizes that instance (or even the memory location of that instance) would be able to modify your variable. In essence if you stored your building health variable publicly it's basically like painting a target on it's back for hackers/cheaters.
The combination, again using health allows you to make a calculation like this:
BuildingActorClass->SetBuildingHealth(BuildingActorClass->GetBuildingHealth() - DamagingPlayer->GetWeaponDamage());
To make the above more "English Clear" the above grabs the current health of the building, subtracts the damaging player's weapon damage, then sets the building health based on that impact. Code-security wise, this is the best option.