Thursday, April 18, 2013

More Programming in RPGs

In response to yesterday's post, +Robert Hanz brought up that a discussion of messaging and the actor model in RPGs might be a good thought exercise, so I figured I'd take a shot at it. This is high level and steamrolls over a lot of nuances and details within the actor model. I'm not going to tackle things like message queues or service layers or anything else.

What's interesting about this in relation to yesterday's post is that Alan Kay, who developed the Small Talk programming language and is considered one of the founding fathers of object-oriented programming, lamented that he should have called it "message oriented programming" because it is the message and not the objects that are relevant. He felt everybody was concentrating too much on the objects, class libraries, etc.

So for this post, I'm going to look at only the messages that are sent between the actors, and who those actors are.

No, NOT him

So what is this "actor model" anyway? In simplest terms instead of everything being an object, everything is an actor. That is, it is able to act upon or in response to other actors (that's my wording and may not jive 100% with the actual model). Actors send messages to one another, and in response they can do one or all of the following at the same time:

  • Send messages to other actors
  • Create new actors
  • Decide the behavior when the next message is received.

A classic example would be driving a car. The driver and the car are both actors. When the driver presses the gas pedal they send the message Go faster. The car responds to that message and through the speedometer sends the message I am now going 65 mph. The driver receives the message and decides they're not going fast enough, and sends the Go faster message again. If the car has a governor, or is now out of gas, it may respond by not going any faster and may begin to slow down (deciding the behavior when the next message is received).

These messages can be synchronous or asynchronous. The gas pedal transmits a synchronous message as the gas pedal is depressed. The driver doesn't need to press the pedal, wait for the car's speed to respond, then press the pedal again. The pedal provides a steady flow of information to the engine. Asynchronous is when you start your car. You have to turn the key and wait for the engine to start before you can start driving. The messages can also be concurrent or non-concurrent. If the car runs out of gas just as you are pressing on the pedal, both messages are sent at the same time and are concurrent.

So in the context of typical rpg combat between two characters, the messages may look like this:

Actor 1 sends a message to Actor 2: I'm a wreck your face!
Actor 2 receives the message and responds with a message of their own: Oh no you didn't!

Depending on the game the messages can be parallel (attack and defense roll at the same time) or non-concurrent (or asynchronous), such as rolling an attack versus a static value like an armor class.

Now let's say Actor 1 succeeds. He now creates a new actor - damage - which transmits a message to Actor 2: Subtract x hit points. Actor 2 receives that message and decrements his hit points by that amount.

Modifiers to actions are the actor changing behavior when the next message is received. If Actor 1 did an All Out Attack, the actor's behavior in response to the next attack may be "Lose a turn.". If the game has a wound system with penalties, his response to the next message coming from Actor 1 might be Subtract x from defense roll because of wounds.

Another example of actors (or characters) creating new actors would be casting a spell that has an effect independent of the caster. Summoning a monster is the most obvious, but pretty much any spell is a new actor. It will be able to send and receive messages and respond to them in predetermined ways (such as reacting to a counterspell or a dispel).

So far the ability to create new actors has been inferred. In other words, a particular character is only able to create a limited number of specific actors (which fits perfectly into the actor model). In games like Fate the actor can decide what new actors to create, plus when and how, through the use of Fate Points and declaring aspects.

But the biggest takeaway in how the actor model applies to Fate is the fact that in Fate everything is an actor. Things like a security bot are obvious. But what about the tree with the aspect Just High Enough To Get Over The Wall? Or a trap with the aspect Spring-Loaded Trap and the skill Spiky-Hurty Bits +2? Those are actors too. When you use Security Systems to create the advantage Targets My Enemies on a turret control panel, you're sending and receiving messages with the panel as an actor and changing its behavior for when it receives the message "Detects presence of an enemy".

Even the setting is an actor. In yesterday's post, I talked about dwindling Resources creating skills the setting can use against the players. Resources send a message to the setting I am now at 0 which responds by creating the aspect Struggle For Survival. In addition, the setting sets its behavior so if it receives the message from Resources I am now at -1, it will create three actors in the form of skills (Hunger, Thirst, and Exposure). These actors can now start sending messages to the characters (i.e., starvation, dehydration or sunburn) until Resources is above 0 again.

Much like object-oriented programming, I don't think that the actor model is something that would be a singular design goal for an rpg. But the parallels are strong enough that just a slight change in viewing what is an actor and what isn't can have profound effects on how pretty much any game is designed or played.