15
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ @Philipp I have added the book. Though, there is some very brief explanation of actor but I am not satisfied with it: it does not bring any historical or practical reasons for invention of actors and what problem it solves, there is just explaining what it can be. \$\endgroup\$ – Victor Polevoy Nov 20 '17 at 12:06
  • 1
    \$\begingroup\$ In Unreal Engine, an Actor is actually a class. docs.unrealengine.com/latest/INT/Programming/UnrealArchitecture/… \$\endgroup\$ – Almo Nov 20 '17 at 20:42
  • 2
    \$\begingroup\$ I believe most engines call these "entities" or "game objects"; I've never heard "actor" in this context. \$\endgroup\$ – user253751 Nov 20 '17 at 22:37
  • 7
    \$\begingroup\$ Your quoted block text is as good an answer to the question of "what is an actor" as you're going to get. \$\endgroup\$ – Russell Borogove Nov 21 '17 at 3:14
  • \$\begingroup\$ To make things more confusing, there are also actors in the Actor Model, which is apparently different. \$\endgroup\$ – Brian McCutchon Nov 21 '17 at 4:59
39
\$\begingroup\$

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".

\$\endgroup\$
  • 2
    \$\begingroup\$ So this is just a term similar to entity, okay. I have thought it has also meaning of something more, thought it is bigger abstraction than just a synonym. Could you also tell what should be an actor and what not? What should I operate with to choose this? \$\endgroup\$ – Victor Polevoy Nov 20 '17 at 12:09
  • \$\begingroup\$ Actor is actually a class in Unreal Engine. Well, it was anyway back in version 2. So it might not be just a term depending on which engine you're using. \$\endgroup\$ – Almo Nov 20 '17 at 20:40
  • 2
    \$\begingroup\$ This sounds like everything in a game is an actor, which would make that word useless. I would say everything that can change the gamestate is an actor. Then a tree is not an actor if it is only a background image, but if you can chop it down and gain ressources, it is. Menus on the other hand do something, but I would not classify them as actors, they are not part of the game world (mostly, e.g. in the "upgrade completed" flash game the menus are actually part of the game world). \$\endgroup\$ – syntonym Nov 21 '17 at 13:47
  • \$\begingroup\$ @syntonym The second paragraph of the quoted text in the question states that anything can be an actor, even couches. Also, not everything is an actor, particles for instance aren't. \$\endgroup\$ – Bálint Nov 21 '17 at 14:35
  • \$\begingroup\$ @Bálint interesting, I have thought particles are actors too. They have to tick on update, they have to think (physics), they have a state. Is not it? \$\endgroup\$ – Victor Polevoy Nov 21 '17 at 15:13
14
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ +1 I like that it illustrates the fact that you need a name for a base class. \$\endgroup\$ – Vaillancourt Nov 20 '17 at 19:21
  • 3
    \$\begingroup\$ 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. {{citation needed}} a term "actor" is generic enough to be used in software design long before people even thought about hiring writers for games (also, it was used in UML etc, things that were used for business development). The dictionary (M-W) says this: Definition of actor: 1 : one that acts : doer; I fail to see any theatrical connection here. \$\endgroup\$ – user40973 Nov 21 '17 at 17:27
  • \$\begingroup\$ To be fair, I did say by my understanding. You may be right, but people are at least used to the idea of actor and prop in that context, which lends a useful explanation to the Asker. \$\endgroup\$ – Stephan Nov 21 '17 at 18:16
  • \$\begingroup\$ I too would say that the term Actor doesn't come from hiring writers but it may come from game developers' early desire to chase Hollywood. :) \$\endgroup\$ – dash-tom-bang Nov 22 '17 at 3:13
1
\$\begingroup\$

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.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.