Unity in itself is a fully object-orientated (OO) system with strict interfaces to ensure that the engine knows what to expect and when, so why shouldn't your game follow the same pattern? Unity is also component-based, which is something else to take into account while designing how your game will be put together.

At the core of any object-orientated design, the focus is on reusability. If a set of attributes is repeatedly used across multiple objects, then they should be separated into one common class and shared in much the same way we do with code refactoring; in addition to this, you should also reduce the amount of code that is lying about doing the same job. This means that we can more easily make changes to this base set without having to re-edit all the classes that might need those attributes. The following diagram shows two approaches of using a base class to define common attributes over multiple code implementations:

Another facet of OO is to employ interfaces to govern exactly how a class should look if you have multiple objects of the same type. For example, you have an Enemy class structure that defines how enemies in general should work; then, using that same structure, you specify all the enemy implementations, such as zombies, spiders, and white-fanged rabbits. Interfaces can also define behaviors or methods on a class, so you can ensure that all the classes that implement that interface will always have the same common abilities, such as all the enemies will have patrol, Fight, and run away methods. This means that if you have an enemy object, it will always have those methods attached to them when you refer to them in the code.

The following diagram shows how you can plan for multiple inheritances, allowing you to add a common behavior pattern to each group of entities:

Knowing this helps us properly design our game effectively and ensures that we architect correctly from the beginning.

We'll discuss these patterns in more detail when we implement them in the following sections.

To keep in line with the preceding architecture set, we'll design the layout of the class to support a flexible structure that will be easily extended in the future.

The common game object

As almost every entity in our game will have statistics and some basic behaviors, we start with a generic object (Entity) to define the attributes that all the entities in our game will have. As there is only one entity type, we don't need to set up an interface for this object as all the other game objects will just use this one definition, as shown in the following diagram:

This shows that we have several common attributes for things such as health and strength. This Entity object is implemented in the code as follows:

using UnityEngine;
public class Entity : ScriptableObject
{
  public string Name;
  public int Age;
  string Faction;
  public string Occupation;
  public int Level = 1;
  public int Health = 2;
  public int Strength = 1;
  public int Magic = 0;
  public int Defense = 0;
  public int Speed = 1;
  public int Damage = 1;
  public int Armor = 0;
  public int NoOfAttacks = 1;
  public string Weapon;
  public Vector2 Position;
}

Note

The entity class is inherited from a specialized class called ScriptableObject. This is essential to know how we will use it in the game. We will cover ScriptableObject in more detail in Chapter 5, NPCs and Interactions.

The player object

Basing the player's character on the Entity object makes the definition of the player a lot simpler. So, you only need to focus on what is specific to the player's character itself, that is, the differences between the player and all the other game entities.

So, the player character we see here is the only one who has Inventory, Money, and Skills since they are specific to our hero's work in our game. This is implemented in the following code with the player inheriting all the properties from the Entity class:

using UnityEngine;
public class Player : Entity
{
  public string[] Inventory;
  public string[] Skills;
  public int Money;
}

Note

Preferably, all the attributes of any class should be of the read-only type outside of the class itself (unless there is a very good reason for it). This is to ensure that you don't mistakenly change a class's value without knowing why. It might sound easier to just keep updating everything, but at some point, while you are debugging, you will want to know why things are changing. If any code updates these values, then you will literally spend hours trying to find why. If you need to change values, then you need to implement behaviors (see the following sections).