In my last AkkaOfEmpires blog post, I started to use dependency injection (DI) for my various actors, but it was made “by hand”. So today I will show how to do it with Akka.DI, which is a plugin bringing DI to Akka.NET.

My goal is to be able to ask the actor system for VillagerActor instances without having to specify their dependencies, I’ll let Akka.DI handle this job.

Here is the VillagerActor constructor having the dependencies:

public VillagerActor(IActorRef resourcesSupervisor, SubroutinesFactory subroutinesFactory)
{
    _resourcesSupervisor = resourcesSupervisor;
    _subroutinesFactory = subroutinesFactory;
    Profession = Profession.Idle;
}

And here is the use case:

// Program.cs
var system = AkkaOfEmpiresSystem.Start();
 
var supervisorProps = Props.Create<ConsoleResourcesSupervisorActor>();
var supervisor = system.ActorOf(supervisorProps);
 
var consoleSubroutinesFactory = new ConsoleSubroutinesFactory();
var villagerProps = Props.Create<ConsoleVillagerActor>(supervisor, consoleSubroutinesFactory);
var gatherer = system.ActorOf(villagerProps, "Gatherer");
gatherer.Tell(new GatherFruits());

Using Akka.DI

Now I will change this last part in order to use dependency injection. First there is a nuget to install, in my case I will use StructureMap for the Inversion of Control (IoC) container.

Install-Package Akka.DI.StructureMap

Now, if you want to use another one you can see the list of available Akka.DI extensions here.

First I will rework the SubroutinesFactory by extracting an interface.

public interface ISubroutinesFactory
{
    IActorRef CreateResourceHarvesterActor(IActorContext actorContext, IActorRef villagerActor);
}
 
public class SubroutinesFactory : ISubroutinesFactory
{
    public IActorRef CreateResourceHarvesterActor(IActorContext actorContext, IActorRef villagerActor)
    {
        var props = Props.Create<ResourceHarvesterActor>(actorContext.System.Scheduler, villagerActor);
        var resourceHarvesterRoutine = actorContext.ActorOf(props);
        return resourceHarvesterRoutine;
    }
}
 
public class ConsoleSubroutinesFactory : ISubroutinesFactory
{
    public IActorRef CreateResourceHarvesterActor(IActorContext actorContext, IActorRef villagerActor)
    {
        var props = Props.Create<ConsoleResourceHarvesterActor>(actorContext.System.Scheduler, villagerActor);
        var consoleActor = actorContext.ActorOf(props);
        return consoleActor;
    }
}

Like before, I have two factories: a “classic” one and another one for the Console GUI. I will use the latter in my DI configuration.

Akka.DI uses a dependency resolver to link the IoC container with the actor system, there is one avaialble in the nuget package. I can now update the code:

// Program.cs
static void Main(string[] args)
{
    var system = AkkaOfEmpiresSystem.Start();
    var container = GetDependencyContainer();
    var resolver = new StructureMapDependencyResolver(container, system);
 
    var villagerProps = system.DI().Props<ConsoleVillagerActor>();
    var gatherer = system.ActorOf(villagerProps);
    gatherer.Tell(new GatherFruits());
 
    system.AwaitTermination();
}
 
static IContainer GetDependencyContainer()
{
    var container = new Container(c =>
    {
        c.For<ISubroutinesFactory>().Use<ConsoleSubroutinesFactory>();
    });
    return container;
}

I have specified that every instance of ISubroutinesFactory will be automatically resolved as ConsoleSubroutinesFactory instances and that is what will happen when requesting a new VillagerActor from the system.

I have taken care of one of the two dependencies for the actor. The other one is tricky because it is a IActorRef instance which can refer to every type of actor in the system.

The easy way

Well, at the moment the only IActorRef I need to inject through DI is for the ResourcesSupervisorActor, so I can have the following workaround:

static void Main(string[] args)
{
    var system = AkkaOfEmpiresSystem.Start();
    var container = GetDependencyContainer(system);
    var resolver = new StructureMapDependencyResolver(container, system);
 
    var villagerProps = system.DI().Props<ConsoleVillagerActor>();
    var gatherer = system.ActorOf(villagerProps);
    gatherer.Tell(new GatherFruits());
 
    system.AwaitTermination();
}
 
static IContainer GetDependencyContainer(ActorSystem system)
{
    var container = new Container(c =>
    {
        c.For<ISubroutinesFactory>().Use<ConsoleSubroutinesFactory>();
        c.ForSingletonOf<IActorRef>().Use(system.ActorOf<ConsoleResourcesSupervisorActor>());
    });
    return container;

I defined the dependency as a singleton because I want the resources supervisor to be the same for all the villagers. But now every classes that will need a IActorRef dependency will have a supervisor actor when constructed through DI.

With some IoC containers it is possible to play with named instance and conditions over the constructor parameters to provide the correct instance. But… meh… it is painful to set up and I think it can be dangerous. Let’s try something else.

Another way

What I can also do to fix my problem is removing the dependency to the IActorRef. Instead I will inject a service that will provide the reference to the supervisor actor, like I did for the subroutine actor.

public interface ISupervisorsFactory
{
    IActorRef GetResourcesSupervisor();
}
 
public class SupervisorsFactory : ISupervisorsFactory
{
    public SupervisorsFactory(ActorSystem system)
    {
        _resourcesSupervisor = system.ActorOf<ResourcesSupervisorActor>();
    }
 
    private readonly IActorRef _resourcesSupervisor;
 
    public IActorRef GetResourcesSupervisor()
    {
        return _resourcesSupervisor;
    }
}
 
public class ConsoleSupervisorsFactory : ISupervisorsFactory
{
    public ConsoleSupervisorsFactory(ActorSystem system)
    {
        _resourcesSupervisor = system.ActorOf<ConsoleResourcesSupervisorActor>();
    }
 
    private readonly IActorRef _resourcesSupervisor;
 
    public IActorRef GetResourcesSupervisor()
    {
        return _resourcesSupervisor;
    }
}

Now this factory can be used by the VillagerActor like this:

public VillagerActor(ISupervisorsFactory supervisorsFactory, ISubroutinesFactory subroutinesFactory)
{
    _resourcesSupervisor = supervisorsFactory.GetResourcesSupervisor();
    _subroutinesFactory = subroutinesFactory;
    Profession = Profession.Idle;
}

And I can update my IoC container configuration to link everything.

static IContainer GetDependencyContainer(ActorSystem actorSystem)
{
    var container = new Container(c =>
    {
        c.For<ISubroutinesFactory>().Use<ConsoleSubroutinesFactory>();
        c.ForSingletonOf<ISupervisorsFactory>()
            .Use<ConsoleSupervisorsFactory>()
            .Ctor<ActorSystem>()
            .Is(actorSystem);
    });
    return container;
}

Here is the end of my introduction to Akka.DI for Akka.NET. It allows the instantiation of actor references without having to declare all their dependencies every time a new actor is needed. Yet using DI with Akka.NET can become tricky when these dependencies are others IActorRef. At the moment I prefer avoiding them as much as possible.

Feel free to share your own experience with Akka.DI when it comes to IActorRef.

See you next time!

In my last AkkaOfEmpires blog entry I started a Graphic User Interface (GUI), only on console mode, to display how the actors in my system behave. In this project I use the Akka.NET framework (implementation of the actor model)  to re-create some of the rules present in Age of Empires II.

I was able to add a “console” implementation for two actors on the three I currently have in the system. This last actor is harder to “override” because its creation is done by another actor. Here is the code I am talking about (inside the VillagerActor):

var props = Props.Create<ResourceHarvesterActor>(Context.System.Scheduler, Self);
var resourceHarvesterRoutine = Context.ActorOf(props);

An I would like to use the following implementation of the ResourceHarvesterActor.

public class ConsoleResourceHarvesterActor : ResourceHarvesterActor
{
    public ConsoleResourceHarvesterActor(ITellScheduler messageScheduler, IActorRef villagerAcor)
        : base(messageScheduler, villagerAcor)
    {
    }
 
    public override void Handle(ResourceHarvested message)
    {
        base.Handle(message);
        Console.WriteLine("1 unit of {0} harvested. (carrying {1}).", ResourceToHarvest, CurrentlyCarrying);
    }
}

But, as I said in my last article, I cannot directly use this class in the VillagerActor, because it would create a circular reference and I don’t want to have “GUI” classes in my “core” project.

I think this issue shows that there is some coupling in the VillagerActor, indeed the class directly use the Props API and the Context. I believe it would be a good thing to extract this part of the code and encapsulate it in a dependency.

An actor factory

To fix this issue I will create a factory which will deal with the creation of the subroutine for the other actors and I will be able to use this class as a dependency for the VillagerActor. This way I will remove some coupling in the code.

Here is the factory:

public class SubroutinesFactory
{
    public virtual IActorRef CreateResourceHarvesterActor(IActorContext actorContext, IActorRef villagerActor)
    {
        var props = Props.Create<ResourceHarvesterActor>(actorContext.System.Scheduler, villagerActor);
        var resourceHarvesterRoutine = actorContext.ActorOf(props);
        return resourceHarvesterRoutine;
    }
}

The method in this factory needs some parameters to do its job, first an actor context in order to access the Scheduler and to create the IActorRef instance, secondly the IActorRef for the VillagerActor needing the subroutine.

I can now update my code to use this new class.

public class VillagerActor : ReceiveActor
{
    private readonly IActorRef _resourcesSupervisor;
    private readonly SubroutinesFactory _subroutinesFactory;
 
    public VillagerActor(IActorRef resourcesSupervisor, SubroutinesFactory subroutinesFactory)
    {
        _resourcesSupervisor = resourcesSupervisor;
        _subroutinesFactory = subroutinesFactory;
        //...
    }
 
    //...
 
    protected virtual void ResourceHarvester(IHarvestResourceCommand command)
    {
        //...
 
        var resourceHarvesterRoutine = _subroutinesFactory.CreateResourceHarvesterActor(Context, Self);
        resourceHarvesterRoutine.Tell(command);
 
        //...
    }
 
    //...
}

Override in the GUI

Now, the good thing is that I can create another implementation for this factory in my Console GUI project to use the ConsoleResourceHarvesterActor instead of the regular ResourceHarvesterActor.

public class ConsoleSubroutinesFactory : SubroutinesFactory
{
    public override IActorRef CreateResourceHarvesterActor(IActorContext actorContext, IActorRef villagerActor)
    {
        var props = Props.Create<ConsoleResourceHarvesterActor>(actorContext.System.Scheduler, villagerActor);
        var consoleActor = actorContext.ActorOf(props);
        return consoleActor;
    }
}

And now I can update my program in the GUI project to inject the implementation I want.

static void Main(string[] args)
{
    var system = AkkaOfEmpiresSystem.Start();
 
    var supervisorProps = Props.Create<ConsoleResourcesSupervisorActor>();
    var supervisor = system.ActorOf(supervisorProps);
 
    var consoleSubroutinesFactory = new ConsoleSubroutinesFactory();
    var villagerProps = Props.Create<ConsoleVillagerActor>(supervisor, consoleSubroutinesFactory);
    var gathered = system.ActorOf(villagerProps);
    gathered.Tell(new GatherFruits());
 
    system.AwaitTermination();
}

(To avoid too much flooding on the console I put only one villager instead of three).

And when launching the application, we can see the following output, letting us know what is happening.

We now have what we wanted, information is displayed for each actor and we have a pretty good idea of what is going on. The overall behavior looks good.

In this post I showed a way to extract the logic of creating an actor in a dependency in order to override the behavior, you can find the entire solution here.

For the moment my project is quite small and I only have two levels in my class hierarchy, therefore this “factory” fix will be hard to continue in the future because I have to inject the dependencies at the “boundaries” (the Main() method in my case). In the next AkkaOfEmpires post I will introduce Dependency Injection (DI) when working with Akka.NET to remove this future problem.

See you next time!

Today, I will continue my journey with my project named AkkaOfEmpires. In this project I implement some of the rules of the game Age Of Empires II using the actor model with Akka.NET. You can find the last entries about the project here and here.

In this blog post I will not add new functionalities related to the game, first I feel the need to change a few things I made. I want to change the communication between the VillagerActor and the ResourceHarvesterActor routine. See the code for these two classes below.

Here is the VillagerActor:

public class VillagerActor : ReceiveActor
{
    private readonly IActorRef _resourcesSupervisor;
 
    public VillagerActor(IActorRef resourcesSupervisor)
    {
        _resourcesSupervisor = resourcesSupervisor;
        Profession = Profession.Idle;
 
        var props = Props.Create<ResourceHarvesterActor>(Context.System.Scheduler, _resourcesSupervisor);
        _resourceHarvesterRoutine = Context.ActorOf(props);
    }
 
    public Profession Profession { get; private set; }
    public Resource ResourceToRecolt { get; private set; }
 
    private readonly IActorRef _resourceHarvesterRoutine;
 
    protected override void PreStart()
    {
        base.PreStart();
        Become(Idle);
    }
 
    private void Idle()
    {
        ListenForCommands();
    }
 
    private void ResourceHarvester(IHarvestResourceCommand command)
    {
        Profession = command.AssociatedProfession;
        ResourceToRecolt = command.ResourceToRecolt;
 
        _resourceHarvesterRoutine.Tell(command);
 
        ListenForCommands();
    }
 
    private void ListenForCommands()
    {
        Receive<IHarvestResourceCommand>(m => Become(() => ResourceHarvester(m)));
    }
}

And theResourceHarvesterActor:

public class ResourceHarvesterActor : TypedActor,
    IHandle<IHarvestResourceCommand>,
    IHandle<ResourceHarvesterActor.ResourceHarvested>
{
    private readonly ITellScheduler _messageScheduler;
    private readonly IActorRef _resourcesSupervisor;
 
    public const uint MAX_CAPACITY = 10;
    public uint CurrentlyCarrying { get; private set; }
 
    public Resource ResourceToHarvest { get; private set; }
 
    public ResourceHarvesterActor(ITellScheduler messageScheduler, IActorRef resourcesSupervisor)
    {
        _messageScheduler = messageScheduler;
        _resourcesSupervisor = resourcesSupervisor;
        CurrentlyCarrying = 0;
    }
 
    public void Handle(IHarvestResourceCommand message)
    {
        if (message.ResourceToRecolt != ResourceToHarvest)
        {
            ResourceToHarvest = message.ResourceToRecolt;
            CurrentlyCarrying = 0;
        }
        _messageScheduler.ScheduleTellOnce(TimeSpan.FromSeconds(1), Self, new ResourceHarvested(), Self);
    }
 
    public void Handle(ResourceHarvested message)
    {
        CurrentlyCarrying++;
        if (CurrentlyCarrying == MAX_CAPACITY)
            _resourcesSupervisor.Tell(new ResourceGathered(ResourceToHarvest, CurrentlyCarrying));
        else
            _messageScheduler.ScheduleTellOnce(TimeSpan.FromSeconds(1), Self, new ResourceHarvested(), Self);
    }
 
    public class ResourceHarvested { }
}

Refactoring

What I don’t like with this code is the fact that the “routine” sends the message to the resources supervisor directly. In my opinion the routine should notify the VillagerActor when the capacity is reached and then stops its process.

For me this child actor should not be aware of any actor except itself and its parent. The higher level actor will take care of the communication with the supervisor.

Akka.NET does not provide any shortcut to send messages to the parent of an actor, therefore we will have to inject the reference. We already have a parameter in the constructor of type IActorRef, for the supervisor, from now it will be a reference to the VillagerActor. The type does not change but the actor at the other side of this reference will, then it is extremely important to use proper names when manipulating IActorRef references.

private readonly IActorRef _villagerActor;
 
public ResourceHarvesterActor(ITellScheduler messageScheduler, IActorRef villagerAcor)
{
    _messageScheduler = messageScheduler;
    _villagerActor = villagerAcor;
    CurrentlyCarrying = 0;
}

I now need to refactor the case when the maximum capacity is reached. The villagerActor will be notify and will behave accordingly and the routine will be stopped.

public virtual void Handle(ResourceHarvested message)
{
    CurrentlyCarrying++;
    if (CurrentlyCarrying == MAX_CAPACITY)
    {
        _villagerActor.Tell(new MaxCapacityReached(CurrentlyCarrying));
        Context.Stop(Self);
    }
    else
        _messageScheduler.ScheduleTellOnce(TimeSpan.FromSeconds(1), Self, new ResourceHarvested(), Self);
}

To do this, I created a new message type names MaxCapacityReached with the amount of resource gathered. And to stop the actor I use the Stop() method of the Context property with Self as argument. By doing so the actor system will stop the current instance of the actor.

Now I need to update the behavior of the VillagerActor to properly use the ResourceGathererActor.

protected virtual void ResourceHarvester(IHarvestResourceCommand command)
{
    _currentCommand = command;
    Profession = command.AssociatedProfession;
    ResourceToRecolt = command.ResourceToRecolt;
 
    var props = Props.Create<ResourceHarvesterActor>(Context.System.Scheduler, Self);
    var resourceHarvesterRoutine = Context.ActorOf(props);
    resourceHarvesterRoutine.Tell(command);
 
    ListenForCommands();
}

I moved the creation of the child actor (the usage of Props and Context) inside the method (it was in the constructor before), because now the routine actor will stop once its job is done. If this is not done, the program will not crash, instead the message will not be delivered and will become a “dead letter” (more information on JVM Akka website here). Note that I also save the received command in a field, which will be used shortly.

Now this VillagerActor also need a new handler for MaxCapacityReached message in order to “return to a depot” to increase the amount of resources available.

protected virtual void ResourceCarrier(uint quantity)
{
    _resourcesSupervisor.Tell(new ResourceGathered(ResourceToRecolt, quantity));
    Self.Tell();
    ListenForCommands();
}
 
private void ListenForCommands()
{
    Receive<IHarvestResourceCommand>(m => Become(() => ResourceHarvester(m)));
    Receive<MaxCapacityReached>(m => Become(() => ResourceCarrier(m.Quantity)));
}

Once the message has been sent to the ResourceSupervisorActor the VillagerActor will send itself the command it previously stored, this way it will continue its job by creating a new child actor (a routine) to gather resources.

Now the question is: Does that really work as expected? I could try to make some tests to cover these cases but I fear that they will be extremely difficult to write. Instead I think it is time for me to create the first GUI for the project. Do not get too excited, I will simply be a Console GUI…

The Console GUI

To display the behaviors of the actors, I could simply add some Console.WriteLine() in the methods but I don’t want to pollute the code of my actors with this. Instead I will use inheritance to add this behavior.

To be able to do this, I have to change a few private methods and make them protected virtual (see in the code samples above). And I can now define some ConsoleActors in a new project (AkkaOfEmpires.ConsoleUI).

ConsoleResourcesSupervisorActor:

public class ConsoleResourcesSupervisorActor : ResourcesSupervisorActor
{
    public override void Handle(ResourceGathered message)
    {
        Console.WriteLine("ResourceGathered: {0} {1}", message.Quantity, message.ResourceType);
        base.Handle(message);
        Console.WriteLine("Resources available: {0}: {1} | {2}: {3} | {4}: {5} | {6}: {7}",
            Resource.Food, ResourcesAmounts[Resource.Food],
            Resource.Wood, ResourcesAmounts[Resource.Wood],
            Resource.Gold, ResourcesAmounts[Resource.Gold],
            Resource.Stone, ResourcesAmounts[Resource.Stone]);
    }
}

ConsoleVillagerActor:

public class ConsoleVillagerActor : VillagerActor
{
    public ConsoleVillagerActor(IActorRef resourcesSupervisor)
        : base(resourcesSupervisor)
    {
    }
 
    protected override void PreStart()
    {
        Console.WriteLine("A new villager appears!");
        base.PreStart();
    }
 
    protected override void ResourceHarvester(IHarvestResourceCommand command)
    {
        Console.WriteLine("Villager becomes {0}", command.AssociatedProfession);
        base.ResourceHarvester(command);
    }
 
    protected override void ResourceCarrier(uint quantity)
    {
        Console.WriteLine("Villager carries {0} {1}", quantity, ResourceToRecolt);
        base.ResourceCarrier(quantity);
    }
}

This way I am able to separate the “UI logic” from the message handling of the actors.

I have also created a static method creating the actor system (in the AkkaOfEmpires project this time):

public static class AkkaOfEmpiresSystem
{
    public static ActorSystem Start()
    {
        var system = ActorSystem.Create("AkkaOfEmpires");
 
        return system;
    }
}

And here is the Main program of the console application:

static void Main(string[] args)
{
    var system = AkkaOfEmpiresSystem.Start();
 
    var supervisorProps = Props.Create<ConsoleResourcesSupervisorActor>();
    var supervisor = system.ActorOf(supervisorProps);
 
    var villagerProps = Props.Create<ConsoleVillagerActor>(supervisor);
    var gathered = system.ActorOf(villagerProps);
    gathered.Tell(new GatherFruits());
 
    var shepherd = system.ActorOf(villagerProps);
    shepherd.Tell(new ShepherdFlock());
 
    var lumberjack = system.ActorOf(villagerProps);
    lumberjack.Tell(new CutTrees());
 
    system.AwaitTermination();
}

This program will create the resources supervisor actor and 3 villagers, the first will become a gatherer, the second a shepherd and the last a lumberjack. Now if we launched this program we have the following ouput (after about 50 seconds).

Looks good, the food and wood amounts increase over time, these villagers are now efficient workers!

But… What about a ConsoleResourceHarvesterActor? Well, this one is a bit different, its creation is directly inside the VillagerActor and not in the program. I cannot used this specific actor in the code of the VillagerActor (Circular reference between AkkaOfEmpires and AkkaOfEmpires.ConsoleUI) and I do not want to, a UI class has nothing to do in my core project.

The resolution of this “issue” will be in my next AkkaOfEmpires blog post. Meanwhile you can take a look at the entire solution on GitHub.

See you next time!

Today I will continue to present my work on AkkaOfEmpires, in this project I implement some of the rules from the game Age Of Empires II using the actor model with Akka.NET. You can have a look at the first step here.

In this last entry I introduced the concept of behavior switching using Akka.NET while providing an implementation for a villager (unit in the game) gathering various types of resources. In this article I will continue to work on the VillagerActor and I will mostly do refactoring.

For the moment the villager has a dedicated method for all the professions he can have when gathering resource, see the class below.

public class VillagerActor : ReceiveActor
{
    private readonly IActorRef _resourcesSupervisor;
 
    public VillagerActor(IActorRef resourcesSupervisor)
    {
        _resourcesSupervisor = resourcesSupervisor;
        Profession = Profession.Idle;
    }
 
    public Profession Profession { get; private set; }
    public Resource ResourceToRecolt { get; private set; }
 
    protected override void PreStart()
    {
        base.PreStart();
        Become(Idle);
    }
 
    private void Idle()
    {
        CommandsHandler();
    }
 
    private void Gatherer()
    {
        Profession = Profession.Gatherer;
        ResourceToRecolt = Resource.Food;
        // repeat until new order or lack of bushes
        _resourcesSupervisor.Tell(new ResourceRecolted { ResourceType = ResourceToRecolt, Quantity = 10 });
 
        CommandsHandler();
    }
 
    private void Shepherd()
    {
        Profession = Profession.Shepherd;
        ResourceToRecolt = Resource.Food;
        // repeat until new order or lack of sheeps
        _resourcesSupervisor.Tell(new ResourceRecolted { ResourceType = ResourceToRecolt, Quantity = 10 });
 
        CommandsHandler();
    }
 
    private void Hunter()
    {
        Profession = Profession.Hunter;
        ResourceToRecolt = Resource.Food;
 
        _resourcesSupervisor.Tell(new ResourceRecolted{ResourceType = ResourceToRecolt, Quantity = 10});
 
        CommandsHandler();
    }
 
    private void Farmer()
    {
        Profession = Profession.Farmer;
        ResourceToRecolt = Resource.Food;
 
        _resourcesSupervisor.Tell(new ResourceRecolted { ResourceType = ResourceToRecolt, Quantity = 10 });
 
        CommandsHandler();
    }
 
    private void Fisherman()
    {
        Profession = Profession.Fisherman;
        ResourceToRecolt = Resource.Food;
 
        _resourcesSupervisor.Tell(new ResourceRecolted { ResourceType = ResourceToRecolt, Quantity = 10 });
 
        CommandsHandler();
    }
 
    private void Lumberjack()
    {
        Profession = Profession.Lumberjack;
        ResourceToRecolt = Resource.Wood;
 
        _resourcesSupervisor.Tell(new ResourceRecolted {ResourceType = ResourceToRecolt, Quantity = 10});
        CommandsHandler();
    }
 
    private void StoneMiner()
    {
        Profession = Profession.StoneMiner;
        ResourceToRecolt = Resource.Stone;
 
        _resourcesSupervisor.Tell(new ResourceRecolted { ResourceType = ResourceToRecolt, Quantity = 10 });
        CommandsHandler();
    }
 
    private void GoldMiner()
    {
        Profession = Profession.GoldMiner;
        ResourceToRecolt = Resource.Gold;
 
        _resourcesSupervisor.Tell(new ResourceRecolted { ResourceType = ResourceToRecolt, Quantity = 10 });
        CommandsHandler();
    }
 
    private void CommandsHandler()
    {
        Receive<GatherFruits>(m => Become(Gatherer));
        Receive<ShepherdFlock>(m => Become(Shepherd));
        Receive<HuntPrey>(m => Become(Hunter));
        Receive<FarmCrops>(m => Become(Farmer));
        Receive<CatchFish>(m => Become(Fisherman));
        Receive<CutTrees>(m => Become(Lumberjack));
        Receive<MineStone>(m => Become(StoneMiner));
        Receive<MineGold>(m => Become(GoldMiner));
    }
}

As you can see the code is quite redundant and there is already a lot of methods for the class. Yet a villager can do a lot more than simply gathering resource and I fear that my class will become too big. When working with Object Oriented Programming (OOP) I try to follow the SOLID principles and I feel like I’m starting to break the Single Responsibility Principle.

My goal is to create a child actor for the VillagerActor to deal with all the resource gathering to avoid having too much logic inside this class. But first I will do some refactoring.

Refactoring phase

You may have noticed that all the commands related to the resource gathering are similar, they are associated to a type of resource and to a profession, it looks like a good opportunity to introduce an interface for all of these commands.

public interface IHarvestResourceCommand
{
    Resource ResourceToRecolt { get; }
    Profession AssociatedProfession { get; }
}
 
public abstract class HarvestFood : IHarvestResourceCommand
{
    public Resource ResourceToRecolt
    {
        get { return Resource.Food; }
    }
 
    public abstract Profession AssociatedProfession { get; }
}
 
public abstract class HarvestWood : IHarvestResourceCommand
{
    public Resource ResourceToRecolt
    {
        get { return Resource.Wood; }
    }
 
    public abstract Profession AssociatedProfession { get; }
}
 
public abstract class HarvestGold : IHarvestResourceCommand
{
    public Resource ResourceToRecolt
    {
        get { return Resource.Gold; }
    }
 
    public abstract Profession AssociatedProfession { get; }
}
 
public abstract class HarvestStone : IHarvestResourceCommand
{
    public Resource ResourceToRecolt
    {
        get { return Resource.Stone; }
    }
 
    public abstract Profession AssociatedProfession { get; }
}

And now each command can inherit from the correct abstract class and just have to provide the profession associated to it (see some examples below).

public class FarmCrops : HarvestFood
{
    public override Profession AssociatedProfession
    {
        get { return Profession.Farmer; }
    }
}
 
public class CatchFish : HarvestFood
{
    public override Profession AssociatedProfession
    {
        get { return Profession.Fisherman; }
    }
}
 
public class CutTrees : HarvestWood
{
    public override Profession AssociatedProfession
    {
        get { return Profession.Lumberjack; }
    }
}
 
public class MineStone : HarvestStone
{
    public override Profession AssociatedProfession
    {
        get { return Profession.Miner; }
    }
}
 
public class MineGold : HarvestGold
{
    public override Profession AssociatedProfession
    {
        get { return Profession.Miner; }
    }
}

I can now update the implementation of the VillagerActor to use the properties available in the classes I just refactored to simplify it and to remove all the code duplication.

private void ResourceHarvester(IHarvestResourceCommand command)
{
    Profession = command.AssociatedProfession;
    ResourceToRecolt = command.ResourceToRecolt;
 
    _resourcesSupervisor.Tell(new ResourceRecolted { ResourceType = ResourceToRecolt, Quantity = 10 });
 
    ListenForCommands();
}
 
private void ListenForCommands()    // previously CommandsHandler()
{
    Receive<IHarvestResourceCommand>(m => Become(() => ResourceHarvester(m)));
}

In my opinion this is way cleaner than before even if the notion of one method by profession has been removed, we still have a property for this.

Now I think that I have a good base to add the child actor which will have a bit more logic than this current implementation.

The child actor

In Age Of Empires II, gathering resource takes time, a villager harvests resource one by one and brings them back to the a resource depot when his capacity is full. I will implement this logic in the new child actor called ResourceHarvesterActor. This actor is not a unit on its own, it will represent a subroutine of the villager.

public class ResourceHarvesterActor : TypedActor,
    IHandle<IHarvestResourceCommand>,
    IHandle<ResourceHarvesterActor.ResourceHarvested>
{
    private readonly ITellScheduler _messageScheduler;
    private readonly IActorRef _resourcesSupervisor;
 
    public const uint MAX_CAPACITY = 10;
    public uint CurrentlyCarrying { get; private set; }
 
    public Resource ResourceToHarvest { get; private set; }
 
    public ResourceHarvesterActor(ITellScheduler messageScheduler, IActorRef resourcesSupervisor)
    {
        _messageScheduler = messageScheduler;
        _resourcesSupervisor = resourcesSupervisor;
        CurrentlyCarrying = 0;
    }
 
    public void Handle(IHarvestResourceCommand message)
    {
        if (message.ResourceToRecolt != ResourceToHarvest)
        {
            ResourceToHarvest = message.ResourceToRecolt;
            CurrentlyCarrying = 0;
        }
        _messageScheduler.ScheduleTellOnce(TimeSpan.FromSeconds(1), Self, new ResourceHarvested(), Self);
    }
 
    public void Handle(ResourceHarvested message)
    {
        CurrentlyCarrying++;
        if (CurrentlyCarrying == MAX_CAPACITY)
            _resourcesSupervisor.Tell(new ResourceGathered { Quantity = CurrentlyCarrying, ResourceType = ResourceToHarvest });
        else
            _messageScheduler.ScheduleTellOnce(TimeSpan.FromSeconds(1), Self, new ResourceHarvested(), Self);
    }
 
    public class ResourceHarvested { }
}

To simulate the game logic, this actor will send a message to itself every second to increment the amount of resource the villager is carrying. To do so I use the ITellScheduler interface which is available in Akka.NET. This allows to set a delay before sending a message to an actor, in this case the actor is itself so I use the Self property. I chose to use this interface instead of an implementation to be able to inject the dependency to ease the testability of the class.

I also added a condition to detect when the villager is at full capacity, when it occurs then the ResourceSupervisorActor is used to increment the global counter for the resource being harvested (in the game the villager goes to the depot for this).

There is another game rule I implemented in this actor, the fact that a villager cannot gather several types a resource at the same time. For example if a lumberjack is ordered to go fishing, then the wood he is carrying is lost. I made a unit test to cover this case:

[Fact(DisplayName = "ResourceHarvesterActor Should Empty CurrentlyCarrying If Different Resource To Harvest")]
public void Empty_CurrentlyCarrying_If_Different_Resource_To_Harvest()
{
    _harvester.Tell(VillagerOrders.CutTrees);
    _harvester.Tell(new ResourceHarvesterActor.ResourceHarvested());
    _harvester.UnderlyingActor.CurrentlyCarrying.ShouldBe<uint>(1);
    _harvester.Tell(VillagerOrders.CatchFish);
    _harvester.UnderlyingActor.CurrentlyCarrying.ShouldBe<uint>(0);
}

Now I will use this new actor inside the VillagerActor.

public class VillagerActor : ReceiveActor
{
    private readonly IActorRef _resourcesSupervisor;
 
    public VillagerActor(IActorRef resourcesSupervisor)
    {
        _resourcesSupervisor = resourcesSupervisor;
        Profession = Profession.Idle;
 
        var props = Props.Create<ResourceHarvesterActor>(Context.System.Scheduler, _resourcesSupervisor);
        _resourceHarvesterRoutine = Context.ActorOf(props);
    }
 
    public Profession Profession { get; private set; }
    public Resource ResourceToRecolt { get; private set; }
 
    private readonly IActorRef _resourceHarvesterRoutine;
 
    protected override void PreStart()
    {
        base.PreStart();
        Become(Idle);
    }
 
    private void Idle()
    {
        ListenForCommands();
    }
 
    private void ResourceHarvester(IHarvestResourceCommand command)
    {
        Profession = command.AssociatedProfession;
        ResourceToRecolt = command.ResourceToRecolt;
 
        _resourceHarvesterRoutine.Tell(command);
 
        ListenForCommands();
    }
 
    private void ListenForCommands()
    {
        Receive<IHarvestResourceCommand>(m => Become(() => ResourceHarvester(m)));
    }
}

There is nothing particular in here except the fact that I used the Scheduler from the System (available through the Context) for the child actor. With the refactoring and the adding of a child actor, the VillagerActor has more the role of a coordinator than an actor since I remove all the logic from it. But this is a temporary situation, since I still have a lot of rules to implement, with time it will become a high level actor delegating work to child actors.

The code for the entire solution is available on my GitHub repository, it will allow you to see the entire project. Since I write the blog posts in parallel of the development of the solution itself it is likely that the code will change a lot with time due to constant refactoring. So it is possible that the code shown in the articles is not up-to-date when you read it, therefore do not hesitate the browse the changes in the repository’s history and to have a look at the different branches.

See you next time!

I am quite interested by the actor model pattern and especially by using Akka.NET. So I wondered how I could learn it by practicing, the Petabridge’s boot camp is a very good start but I want to learn more by myself.

When I was a kid, I used to play a lot at Age Of Empires II: The Age of Kings, I played this game for hours and I still know a lot about the rules. This is a strategy game in real-time, where the player manage units to gather resources, expand on a map, build armies to defeat some opponents.

When thinking about it I think it could provide a good and fun example to try Akka.NET in depth. There are a lot of different rules in the game and some of them are quite specific, and a unit in the game could be implemented by an actor, imagine all the interactions that can happened between all of these actors.

When writing these lines I am only at the start of this journey and I don’t know if it is a good idea, but still I want to try. I don’t think I will handle the movement of the units and the graphic interface, I will focus on the interactions between the different units, buildings and technologies.

The setup

For this demo I will show you how to switch the behavior of a villager depending on the message (command) he receives. In the game a villager can do a lot of things: gathering resources, constructing buildings, repairing them, even fighting. For the moment I will focus on the resources gathering part.

In order to see the different amounts of resource available to the player, I created an actor which will store them:

public class ResourcesSupervisorActor : TypedActor, IHandle<ResourceRecolted>
{
    public Dictionary<Resource, uint> ResourcesAmounts { get; private set; }
 
    public ResourcesSupervisorActor()
    {
        ResourcesAmounts = new Dictionary<Resource, uint>
        {
            {Resource.Food, 0},
            {Resource.Wood, 0},
            {Resource.Stone, 0},
            {Resource.Gold, 0}
        };
    }
 
    public void Handle(ResourceRecolted message)
    {
        ResourcesAmounts[message.ResourceType] += message.Quantity;
    }
}

You can notice that unlike in previous posts about Akka.NET, I used a new kind of actor: the TypedActor and I implemented an interface to specify the type of message this actor can handle. Now it is time to have a villager that will gather resources to increase these amounts.

The tests

I am using Specflow to write the acceptance tests I want to implement for the project and here are the firsts for the villager:

Feature: Villager Professions

Scenario: A villager recolts food when ordered to gather fruits
	Given I have a villager
	When he becomes a gatherer
	Then he recolts food

Scenario: A villager recolts food when ordered to becoma a shepherd
	Given I have a villager
	When he becomes a shepherd
	Then he recolts food

And below you will find the implementation of these steps.

[Binding]
public sealed class VillagerSteps : TestKit
{
    [AfterScenario]
    public void AfterScenario()
    {
        Shutdown();
    }
 
    [BeforeScenario]
    public void BeforeScenario()
    {
        _resourcesSupervisor = ActorOfAsTestActorRef<ResourcesSupervisorActor>();
    }
 
    private TestActorRef<VillagerActor> _villagerActor;
    private TestActorRef<ResourcesSupervisorActor> _resourcesSupervisor;
 
    [Given(@"I have a villager")]
    public void GivenIHaveAVillager()
    {
        var props = Props.Create<VillagerActor>();
        _villagerActor = ActorOfAsTestActorRef<VillagerActor>(props);
    }
 
    [When(@"he becomes a gatherer")]
    public void WhenHeBecomesAGatherer()
    {
        _villagerActor.Tell(new GatherFruits());
    }
 
    [When(@"he becomes a shepherd")]
    public void WhenHeBecomesAShepherd()
    {
        _villagerActor.Tell(new ShepherdFlock());
    }
 
    [Then(@"he recolts food")]
    public void ThenHeWillRecoltFood()
    {
        _villagerActor.UnderlyingActor.ResourceToRecolt.ShouldBe(Resource.Food);
    }
}

I am using Akka.TestKit and the shouldly library for the tests. With these scenarios we can understand that a villager can have several roles, even when gathering a single type of resource. I only put two professions in this example to shorten the code.

The villager implementation

Now I will show you the implementation of the villager actor to show how a behavior switching can be made when using Akka.NET.

public class VillagerActor : ReceiveActor
{
    private readonly IActorRef _resourcesSupervisor;
 
    public VillagerActor(IActorRef resourcesSupervisor)
    {
        _resourcesSupervisor = resourcesSupervisor;
        Profession = Profession.Idle;
    }
 
    public Profession Profession { get; private set; }
    public Resource ResourceToRecolt { get; private set; }
 
    protected override void PreStart()
    {
        base.PreStart();
        Become(Idle);
    }
 
    private void Idle()
    {
        CommandsHandler();
    }
 
    private void Gatherer()
    {
        Profession = Profession.Gatherer;
        ResourceToRecolt = Resource.Food;
        // repeat until new order or lack of bushes
        _resourcesSupervisor.Tell(new ResourceRecolted { ResourceType = ResourceToRecolt, Quantity = 10 });
 
        CommandsHandler();
    }
 
    private void Shepherd()
    {
        Profession = Profession.Shepherd;
        ResourceToRecolt = Resource.Food;
        // repeat until new order or lack of sheeps
        _resourcesSupervisor.Tell(new ResourceRecolted { ResourceType = ResourceToRecolt, Quantity = 10 });
 
        CommandsHandler();
    }
 
    private void CommandsHandler()
    {
        Receive<GatherFruits>(m => Become(Gatherer));
        Receive<ShepherdFlock>(m => Become(Shepherd));
    }
}

Like in my introduction to Akka.NET I used the ReceiveActor which allows me to treat several types of message and to do different actions depending on the context.

At the first the villager is idle and just wait to receive an order to get to work (just like in the game). At the moment he can only be ordered to gather food from bushes or from sheep. When one of these two order arrives the “profession” of this villager change and he begins his work, gathering food in these cases (message sent to the supervisor actor to increment the food amount).

Yet a gatherer can at anytime receive the order to become a shepherd and this is done by using the Become method available for this type of actor (I extract this behavior in a separate method to avoid duplication).

I have written the following test to check that a villager can change its behavior:

[Fact(DisplayName = "VillagerActor Should Be Able To Change Profession")]
public void Be_Able_To_Change_Profession()
{
    var villager = ActorOfAsTestActorRef<VillagerActor>(Props.Create<VillagerActor>(TestActor));
    var shepherdCommand = new ShepherdFlock();
    villager.Tell(shepherdCommand);
 
    var gatherCommand = new GatherFruits();
 
    villager.Tell(gatherCommand);
 
    villager.UnderlyingActor.Profession.ShouldBe(Profession.Gatherer);
}

Using this Become method is very helpful when designing Finite-State-Machine with Akka.NET.

A final word

This example is just an introduction regarding the behavior switching with the actor model, the example is quite simple at the moment. But I intent to make updates on the project to implement the rest of the possible gathering methods for a villager. There are a lot more rules to implement even in the area I just showed you.

I put the code on my GitHub account to allow you to browse the whole code and to see the improvements I will add over time. If you would like to see a particular set of rules implemented, let me know, I will continue to post articles about this project and the use of Akka.NET for it. And do not hesitate to tell me if you think something should be made differently, I am open to feedback.

See you next time!

A few weeks ago I discovered a framework implementing the actor-model: Akka.NET. Since I was quite unaware regarding this programming model, I decided to give it a try. I really like what I saw and the concepts behind the actor-model and this is why I’m creating this blog post.

The actor-model adopts the idea that everything is an actor, an actor is an entity that receive messages, creates other actors and adapts its behavior depending on the message it receives. And the entire system relies on asynchronous communication making it inherently concurrent.

Akka.NET is an open-source project (available on GitHub) bringing the actor-model to the .NET world (C# & F#), it is based on the Akka framework (Scala & Java).

To install Akka.NET for one of your project, you just have to install a nuget package:

Install-Package Akka

Creating your first actor

I will now show you how to use the project to create your first actor-model. You’ll find below the definition of an actor in C#.

public class YellowActor : UntypedActor
{
    private const string ActorName = "YellowActor";
    private const ConsoleColor MessageColor = ConsoleColor.Yellow;
 
    protected override void OnReceive(object message)
    {
        if (message is string)
        {
            var msg = message as string;
            PrintMessage(msg);
        }
    }
 
    private void PrintMessage(string message)
    {
        Console.ForegroundColor = MessageColor;
        Console.WriteLine(
            "{0} on thread #{1}: {2}",
            ActorName,
            Thread.CurrentThread.ManagedThreadId,
            message);
    }
}

In this case I created a class that inherits from UntypedActor, this allow me to override the OnReceive method. This way the system knows that this class represents an actor able to treat messages. Creating a basic actor is simple, I don’t need to write too much code.

As you can see the OnReceive method is protected, if I want to use this actor I will have to create an actor system, I cannot just instantiate this class to use it. Akka.NET provides a set of functionalities to deal with the actor model, the ActorSystem is one of them. This is how you create a system and an actor:

var actorSystem = ActorSystem.Create("myActorSystem");
 
var yellowActor = actorSystem.ActorOf<YellowActor>();
 
actorSystem.AwaitTermination();

Since my actor is quite simple, I don’t need more code to have an up-and-running actor system with an actor. The WaitTermination method blocks the current thread to avoid it to exit the program, it waits for the actor system to shut down.

Now I can send a message to the actor to see what will happen. To do so I will add the following lines:

Console.ForegroundColor = ConsoleColor.Red;
Console.WriteLine("Starting actor system on thread: {0}", Thread.CurrentThread.ManagedThreadId);
 
yellowActor.Tell("Message to yellow");

Let’s run the application to see what is happening.

The YellowActor has received the message and has printed it, on a different thread, which makes sense since the one that has created the actor system is blocked by this same system.

There is one important concept to know when manipulating actors with Akka.NET, in my example the yellowActor variable is not an instance of YellowActor, it is an IActorRef. Sending messages to actors is always done with reference, the framework will know how to deliver the message to the associated actor.

Adding a second actor

Now that we have a working actor I will add a second one which will be used by the YellowActor. This way I will show you how to “create” an actor from another one. Let’s define a GreenActor:

public class GreenActor : ReceiveActor
{
    private const string ActorName = "GreenActor";
    private const ConsoleColor MessageColor = ConsoleColor.Green;
 
    protected override void PreStart()
    {
        base.PreStart();
 
        Become(HandleString);
    }
 
    private void HandleString()
    {
        Receive<string>(s =>
        {
            PrintMessage(s);
        });
    }
 
    private void PrintMessage(string message)
    {
        Console.ForegroundColor = MessageColor;
        Console.WriteLine(
            "{0} on thread #{1}: {2}",
            ActorName,
            Thread.CurrentThread.ManagedThreadId,
            message);
    }
}

This time I made the class inherits from ReceiveActor allowing me to use the Receive<T> property telling the actor how to handle different types of message, in my case it’s still a string.

Now I will update the YellowActor to use this new actor.

private IActorRef _greenActor;
 
protected override void PreStart()
{
    base.PreStart();
 
    _greenActor = Context.ActorOf<GreenActor>();
}
 
 
protected override void OnReceive(object message)
{
    if (message is string)
    {
        var msg = message as string;
 
        PrintMessage(msg);
        _greenActor.Tell(msg);
    }
}

The actor has an IActorRef field “pointing” toward the green actor. This actor will not only print the message it receives but it will also send it to the green actor. Let’s see what we have now.

The new actor has received the message and treat it on a different thread. I just show you how to easily create actors and how to pass messages between them. You might think that the second actor looks more complicated for the work it does, and you are right! Yet it will come handy in just a minute when we will create a third actor.

One more actor

It is time to create the BlueActor, again this actor will display the message it receives. And will also respond with a message telling how many messages it has displayed. Here is the blue actor:

public class MessageReceived
{
    public int Counter { get; private set; }
 
    public MessageReceived(int counter)
    {
        Counter = counter;
    }
}
 
public class BlueActor : ReceiveActor
{
    private const string ActorName = "BlueActor";
    private const ConsoleColor MessageColor = ConsoleColor.Blue;
 
    private int _counter = 0;
 
    protected override void PreStart()
    {
        base.PreStart();
        Become(HandleString);
    }
 
    private void HandleString()
    {
        Receive<string>(s =>
        {
            PrintMessage(s);
            _counter++;
            Sender.Tell(new MessageReceived(_counter));
        });
    }
 
    private void PrintMessage(string message)
    {
        Console.ForegroundColor = MessageColor;
        Console.WriteLine(
            "{0} on thread #{1}: {2}",
            ActorName,
            Thread.CurrentThread.ManagedThreadId,
            message);
    }
}

To send back a message inside an actor, you can use the Sender property which is an IActorRef “pointing” to the actor which sent the message. This is helpful if you have an actor hierarchy where a high-level actor delegates some work to lower-level actors.

It is time to update the GreenActor to make it use the BlueActor and to make it handle the MessageReceived type of message, the following code is added to the class:

private const ConsoleColor ResponseColor = ConsoleColor.DarkGreen;
 
private IActorRef _blueActor;
 
protected override void PreStart()
{
    base.PreStart();
 
    var lastActorProps = Props.Create<BlueActor>();
    _blueActor = Context.ActorOf(lastActorProps);
 
    Become(HandleString);
}
 
private void HandleString()
{
    Receive<string>(s =>
    {
        PrintMessage(s);
        _blueActor.Tell(s);
    });
 
    Receive<MessageReceived>(m => PrintResponse(m));
}
 
private void PrintResponse(MessageReceived message)
{
    Console.ForegroundColor = ResponseColor;
    Console.Write("{0} on thread #{1}: ",
        ActorName,
        Thread.CurrentThread.ManagedThreadId);
    Console.WriteLine("Receive message with counter: {0}",
        message.Counter);
}

I was able to use Receive again to specify how to handle MessageReceived instances, an actor can handle several types of message. An actor can even send messages to itself using the Self property. Let’s try out our actor system.

All three actors have displayed the message and the green actor has received an answer from the blue actor. Let’s see if the counter is working as expected, we will tell the program to send 5 messages to the yellow actor.

The green actor received a message from the blue actor with a counter of 5, looks good! The actors communicate with each other using different threads.

Time to conclude

This blog post is just an introduction of the actor model using Akka.NET, the project offers a lot of powerful functionalities. I always try to find new ways for developing software and the actor-model offers me a new paradigm I was not familiar with.

For now I think that this programming model can be very helpful in some situations and I will try to post more on the topic, I really like the project so far!

If you want to learn more about Akka.NET I highly recommend you to try the Petabridge’s bootcamp which will help you to understand the concepts behind the actor model and how they are implemented in Akka. You can find the bootcamp for free here. I also made a presentation a few days ago and you can find the slides here.

See you next time!