Game Development Reference
In-Depth Information
The object-orientated design
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 ac-
count 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 struc-
ture 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 rab-
bits. 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:
