If you look around yourself and watch how living beings behave, what they do, you certainly realize how much we all have in common. As an example, many walk, breath, interact with the world around them. If you want to describe these beings in a game world you often will see similarities which can be your help to ease your job. This is where you can use inheritance and have a common parent for eg. your player, and the non-player characters (NPCs). This week I was thinking about improving the current code to have a better, faster workflow for creating the beings in our game world.
As a first step, our team discussed the basic attributes, skills each being will have the result is used to create my new class: LivingEntity. This class will be responsible for such things as holding the health, defense, and various other values about the given character, also to manipulate these values. In a way, LivingEntity is the basis of how the game will control an entity.
Using LivingEntity as a common parent for both the Player and NPC characters means that they all benefit from everything inside LivingEntity, all have the same basic parameters and functionalities. All the attributes and logic however can be altered if the given character needs a variant, this way the whole idea is even more flexible and helps reusability.
On the above picture it’s clearly visible that most of the components are the same in all three:
- position & rotation
- Animator
- RigidBody
- Collider for the character
- LivingEntity (the common class)
- Movement (handles the animation and speed changes, also controls the next movement target)
The remaining differences are related to the kind of entity: an enemy has an Enemy Controller, also a slight change in the children (an additional collider for proximity checking), while the Player has a Player Controller which handles the controls based on mouse input. Both controllers have connections to the BasicEntity to have a common place for basic interactions.
Utilizing the new class was the real test: I’ve created a Player and an Enemy variant, the setup of these were much (I mean MUCH) easier and faster. Since both Bobs are really from the same parent now, it’s time to revisit one topic from the previous week: Attacking.
When we introduced EnemyBob we created the attack animation for our test dummy, but we left out one important part. EnemyBob can hit us, but we can’t slap him, not even a little bit. My other goal for this week became: have both characters hit each other, and finally have health and damage in the picture. We need to discuss first how we want to approach damage. In many games, especially in the action RPG category, the damage is defined as damage per second, aka. DPS. This means you can hit with the given weapon x times in the given timeframe, and that will be the basis for calculating the actual damage you can deal per second. Let’s say your weapon has a Hit ration of 2 hits per second and has a damage value of 3 points. Since you’re hitting twice, each hit deals 3 points of damage, your DPS will be 6 points.
Since Attacking is a common skill I was creating a separate MonoBehavior script for handling the attack-logic, then both the Enemy and Player will have this attached to themselves, with “proper” configuration.
After having the attack coded, we have a basic movement with manual speed setting (run or walk), the first (and very minimal) interaction, attacking.