.NET Reactive Framework

In our game, stories are first-class beings -  invisible meddlers. They move around, observe and manipulate the world according to their plot. They wait for triggering conditions or patterns of events to occur, and then spring to life to advance the story.

In our case, we have an evil story waiting for the betrayal of a paladin. When this happens, the story will unravel a series of events, involving a horror, a child's toy and a man with a poisoned name.

How does the story listen out for the betrayal? Our game follows an event-driven design so we'll need to do some event-processing.

I recently saw Erik Meijer's presentation on .NET's up and coming Reactive Framework (Rx), which looks pretty cool and the right tool for the job. There are already a couple of other reactive programming frameworks out there, like Continous LINQ and Reactive LINQ, but I thought it would be interesting to see what's involved in writing one, so here we go.

Rx is the mathematical inverse of IEnumerable, dubbed IObservable. So instead of being able to iterate over a stream of objects you get to listen to a stream of events.

No big deal really, but the cool thing is that it supports Linq, so you can query over event streams.

IObservable<ICombatCommand> paladinFleeCmds =
  from cmd in CombatMediator.CombatCommands
  where cmd.CommandType == CommandType.Flee &&
        cmd.Subject.CharacterType == CharacterType.Paladin
  select cmd;

paladinFleeCmds.Subscribe(cmd =>
  {
    IStoryPoint betrayal = new Betrayal(cmd.Subject);
    story.RegisterStoryPoint(betrayal);
  });

I'll post how to implement this kind of Linq-to-Events shortly.

Inversion of Control (IoC)

In our game, a monster wakes up because some players have entered its domain. It's in a dark corner, so it waits for the players to pass by and then lunches them.

Assuming the flow of control starts with the monster object, how does it communicate its intentions to the combat system?

1) The direct approach would be for the monster to create and reference the combat system.

public class Monster : ICreature
{
  private DefaultCombatSystem combatSystem =
                new DefaultCombatSystem();  // Bad
  
  protected void GetUpToNoGood()
  {
    //...
    ICommand command = new LunchPlayers(players);
    IResponse response =
              combatSystem.HandleCommand(this, command);
    //...
  }
  //...
}

But this comes with a raft of problems. The least of which is when the combat system changes, the monster will need updating.

2) A better approach is to refer to an interface for combat systems rather than a particular implementation. This will save on the refactoring. The monster can also ask a factory for the combat system that implements this interface. This adds a dependency on a factory however, which is not ideal.

So instead we inject the combat system into the monster. This is known as dependency injection and removes the monster's dependency on a concrete combat system or factory.

public class Monster : ICreature
{
  private ICombatSystem combatSystem;  // Better 
  
  // Constructor injection 
  public Monster(ICombatSystem combatSystem)
  {
    this.combatSystem = combatSystem;
  }
  //...
}

This would be perfect for things a monster does depend on, like its stomach, but the combat system doesn't belong here.

3) An even better approach is to expose an event that the monster fires. This frees the monster from combat system concerns altogether, so it can concentrate on what monsters do best.

public delegate void CommandHandler(ICommand command);

public class Monster : ICreature
{
  public event CommandHandler Command;  // Best
  
  protected void GetUpToNoGood()
  {
    //...
    ICommand command = new LunchPlayers(players);
    Command(this, command);
    //...
  }
  //...
}

Wiring up the event,

public class DefaultCombatSystem : ICombatSystem
{
  private IList<ICreature> creatures;

  public void AddCreature(ICreature creature)
  {
    creatures.Add(creature);
    creature.Command += OnCommand;
  }
  
  public void OnCommand(ICommand command)
  {
    // Handle the command 
  }
  //...
}

This is the observer design pattern using events.

Control has shifted to the combat system now. It references the monster and will make the required calls to resolve the combat. This is known as inversion of control (IoC) or the Hollywood principle - "Don't call us, we'll call you".

In hindsight it's easy to see we had things backwards from the start, but the direct approach is all too common. It's a hangover from procedural programming where the programme's flow of control acts directly rather than setting up an object model and then handing over control to one of these objects.

In this way, the combat system and the monster are much easier to maintain, test and debug.