by Jon (Updated on 2015-10-21)
This article introduces you to the key concepts behind actors. Because Actor concepts are intertwined, it's useful to get a little exposure to each before delving into full detail.
Actors are the living, interactive parts of a game. Actors are the players, enemies, projectiles, vehicles, inteface elements and anything in a game that "lives."
Every actor can be broken up into a few common elements.
Appearance dictates how an Actor looks. In the 2D games we build, we call these animations.
Animations are a collection of frames that are played out in sequence and usually loop, to form a fluid, living visual representation of the actor.
Actors need not be bound to a single animation. They can switch between different states, each which are associated with their own Animation and collision bounds.
Consider the hero or "player" character in a platformer such as Mario. This character will have states for standing, walking, running and jumping.
Coming from Scratch? Animation States are equivalent to costumes.
Behaviors tell an actor what to do and how to react. They provide specific logic which allows the actor to perform unique tasks like run, jump, walk, fire weapon and more.
Behaviors are unique in that they are reusable and configurable.
They can be attached to other actors, thereby letting you reuse the same behavior for multiple actors. Reuse is good because it saves you effort and prevents bugs stemming from duplicate code (that you are likely to edit in the future).
You can configure their Attributes (properties). For example, if you attached a Walking behavior to an actor, you could customize its walking speed.
You may notice an "Events" page when opening up the Actor Editor. This page lets you attach Events directly to an actor, without requiring a full behavior.
This is useful for adding logic that's specific to the actor and is also great for rapidly prototyping ideas.
Further Reading: We don't cover the Behaviors or Events pages in Chapter 3, since you got exposed to plenty of that already in Chapter 2. For a refresher, read Chapter 2's introduction.
In many games, Actors collide with other Actors. In our engine, our Actors obey the laws of physics and act much like real-world objects.
In order to make this all happen, the Actors need to assume a physical form, whether it's a box, a circle, a polygon or some combination of those.
These physical forms are known as Collision Bounds, and they are tied directly to Animation States. Intuitively, this makes sense. If your character stands, he takes on one shape. If he's "ducking" on the ground, his shape will be shorter.
Sensors allow collisions to occur without generating a physical reaction. This is useful when you don't want a certain Actor to "push" other actors away but do want that collision to happen.
For example, slashing a sword or being hit by a fireball shouldn't necessarily knock you back, but it should definitely hurt.
Groups let you filter collisions, so that only certain classes of Actors collide with each other.
To take a real-life example, consider the concept of "friendly fire" - sometimes, you don't want your enemy's bullets to kill other enemies. Groups let you prevent this from happening.
As mentioned earlier, Actors obey the laws of physics. The Physics page lets you tweak an actor's physical attributes that don't pertain to its collision bounds.
Here are just some of the properties you can tweak.
Two terms you may see thrown around are Actor Types and Actor Instances. More confusingly, we may abbreviate both to simply "Actor", with no indication, outside of context, which of the two we're talking about.
The difference is this...
Consider a game like Super Mario Bros. Consider this familiar enemy, which you may recognize...
We expect this enemy to act in the same way, namely to walk in one direction until it hits a wall, then to reverse direction. If we hit this enemy, we get hurt.
But every instance of this enemy exists at a different location on the scene. When you step on one, it dies. These are each separate instances of Goomba.
This, in a gist is the distinction between an Actor Type and Actor Instance.
Programmers' Note: Types are akin to Classes, while Instances are akin to Objects.