What is an actor in game development?

Question

I am reading a book about game development (Game Coding Complete, Fourth Edition) and there is an "Actors" topic which just explains how to use them briefly instead of explaining what it is.

Here's how the book introduces these actors:

Games are full of objects that bring your world to life. A World War II game might be full of tanks and planes, while a futuristic science fiction game might have robots and starships. Like actors on a stage, these objects are at the heart of the gameplay. It seems fitting that we call them “game actors” because that’s exactly what they are.

A game actor is an object that represents a single entity in your game world. It could be an ammo pickup, a tank, a couch, an NPC, or anything you can think of. In some cases, the world itself might even be an actor. It’s important to define the parameters of game actors and to ensure that they are as flexible and reusable as possible.

There are as many ways for defining a game actor as there are games. Like everything else in computer programming, there is rarely a perfect solution.

I could only understand a very few things: it is an abstraction of everything in the game which can perform actions; it has it's own state; it's behaviour is usually implemented as a state machine. This is it. I am coming with systems programming background to the game development, and so I would like to know in general, what the actor is in game development meaning, how to use it, how it is used in general, what problem it solves, how and why. I would like the explanation to be such that a kid could understand.

I have tried to find this information on google but it heads me to another "actors" instead: concurrent programming most of the time or game actors but without a good explanation of it.

Answer 1

As you mentioned, an actor can be literally anything; trees, NPCs, buildings, etc. A similar term is "entity". It doesn't need to have a behaviour in the traditional sense, it can be static.

It's just a way to say "an object in the game".

Answer 2

By my understanding the term is a side effect of hiring writers to make the stories for games. Since they usually come from theater or screen, they are accustomed to the terms Actor and Prop. Actors being things that move and play a real role in the game, and Props being things like trees, buildings, etc.

From my early days of coding in college, before we were allowed to use an engine like Unity, we had to code our own engine. Actor was an abstract base class that had a transform, empty lifecycle functions, and a function called Act() which was our version of Unity's Update().

Our main game loop basically followed:

for(Actor actor in actors)
{ 
   actor.Act(); 
}

Most engines use the Entity concept, so from your reading, just translate Actor as Entity in your head and you'll be fine.

Answer 3

Others already gave good answers, but i wanted to add and clarify couple of things. There are various approaches to architecture and it may seem like Actor is the same as Entity or GameObject, but there are pretty big differences between them in practice.

• Actor indeed lives in a Scene and acts, "living in a scene" means that it has some positional data attached to it, be it matrix components or a Transform for managing matrices, an object cant have a meaningful position representation in a scene without it.
• Different architectures solve the composition over inheritance problem differently. Unreal4 uses a mix of component model and inheritance with its Actor, as it has a "root" class extending Actor and representing a "thing" in the scene, (look at AStaticMeshActor for example), and a bunch of supporting components. GameObject in unity does not allow extension and is purely a collection of components, which makes it agnostic to its use, which is great for scene graph related problems. Entity in ECS in its purest form, is absolutely agnostic to its use and doesn't have to have any transformation data or behavior, and so its the most "low level" approach. These approaches have deep implications on how you treat your objects in game code.

An example would be skeletal meshes:

• Unreal4 has a skeleton actor, which represents the bones with independent FBoneNode type.
• Unity represents bones by using GameObjects themselves, which allows you to intuitively operate on them (attaching components right in editor for example).
• ECS approaches may use any of the above or not have any bones at all, since performance is the key over there, its most likely the whole animation will be baked into a texture and played on geometry shader.

So to summarize my ramblings: Traditionally Actors combine data and behavior (and most likely inheritance), and optionally have some form of components attached they are very convenient/intuitive to reason about and to work with as they represent a concrete "thing", GameObject may do exactly the same, however nowadays popularized by Unity approach they will most likely only act as a component container and have no behavior, but components do. And ECS Entity would act as a key id for a group of independent components that can represent anything through data components with no behavior attached (its implemented by systems which act on them).

As with any architecture what approach for your "Actor" you chose is best decided by what fits your game better.