Game Development Reference
In-Depth Information
The main issue with this style of design is that the code you write will be focused on
the type of game being made. If you want to re-use the code later on, it will be harder
to do this without extensive changes to the existing code. Code re-use with OOP
may be difficult even within the context of the current game, where certain types may
share the functionality, but cannot be easily structured to share that code. Of course
in many cases this is not a problem and using this style of design allows for faster
development.
As an example, let's look at the logic flow involved in shooting an enemy in this
game. The player begins by triggering the input for shooting, which is detected by the
input manager. Code handling the input would then call
player->Shoot()
and that
object would create a new bullet, which moves forward for each update—perhaps
with a
Move()
method. When the bullet reaches the enemy it detects the collision,
destroys itself, and calls
enemy->Damage(damage)
, passing the amount of dam-
age the bullet should do to the enemy so that it can appropriately reduce its health.
The enemy then checks the amount of health remaining and if it is zero (or less than
zero) it destroys itself.
When a bullet or enemy destroys itself, it is removed from the respective manager
and renderer so that it is not displayed or used anymore.
Components and entities
Another design style uses
composition
to disconnect the objects from each other,
making it easier to construct them as required, and add/remove functionality as
needed. This also improves re-using in future games because the components can
be taken and easily copied over, knowing that they have very low coupling to oth-
er objects. This, however, requires a bit of design to build the systems and provide
helpers or systems to allow communication between them.
The core of this system uses the concept of an
entity
(sometimes called an
actor
)
to represent all of the objects in the game. The entity is often a bare bones simple
class that contains the necessary functionality to store components and allow for dis-
covery or generic communication paths between the components.
The components themselves define what an entity is, and are often also managed
by separate manager classes that handle updating or iterating through them in se-
quence. This has a number of benefits, ranging from high modularity to performance.
