Tag Archives: Schedule

RogueSharp V3 Tutorial – Monster Behaviors

Next Tutorial Post – Doors
Previous Tutorial Post – Scheduling System

Goal

There is going to be a lot of code in this tutorial. We have to start using the scheduling system we built last time. We’ll also be laying the foundation for creating monster behaviors. Our first behavior will be a simple move and attack, but we can expand on this in the future to create lots of interesting monsters.

simplebehaviors

Simple Behaviors

Defining a Behavior Interface

First we need to define the interface that all of our future Behaviors will use. Create a new file named IBehavior.cs in the Interfaces folder. Add the following code:

public interface IBehavior
{
  bool Act( Monster monster, CommandSystem commandSystem );
}

We’re going to keep it simple and just have a simple Act(…) method that will take the Monster performing the action and the CommandSystem as parameters.

Creating a Move and Attack Behavior

Our first concrete behavior that will implement our IBehavior interface will be StandardMoveAndAttack.

Briefly lets go over what the StandardMoveAndAttack behavior will do.

  • A monster should perform a standard melee attack on the player if the player is adjacent to the monster.
  • If the player is not within attack range, the monster should move closer to the player via the shortest available path.
  • Only monsters that are aware of the player should chase him.
  • Once the monster is alerted and begins the chase, if the player evades him and remains out of visual range for a period of time the monster should stop pursuit.
  • If the monster can see the player but does not have a valid path (possibly because of being blocked by other monsters) it should wait a turn.

Because we want to have many additional behaviors in the future we should make a new folder named Behaviors and then create the file StandardMoveAndAttack.cs in that folder. Add the following code:

public class StandardMoveAndAttack : IBehavior
{
  public bool Act( Monster monster, CommandSystem commandSystem )
  {
    DungeonMap dungeonMap = Game.DungeonMap;
    Player player = Game.Player;
    FieldOfView monsterFov = new FieldOfView( dungeonMap );

    // If the monster has not been alerted, compute a field-of-view 
    // Use the monster's Awareness value for the distance in the FoV check
    // If the player is in the monster's FoV then alert it
    // Add a message to the MessageLog regarding this alerted status
    if ( !monster.TurnsAlerted.HasValue )
    {
      monsterFov.ComputeFov( monster.X, monster.Y, monster.Awareness, true );
      if ( monsterFov.IsInFov( player.X, player.Y ) )
      {
        Game.MessageLog.Add( $"{monster.Name} is eager to fight {player.Name}" );
        monster.TurnsAlerted = 1;
      }
    }
    
    if ( monster.TurnsAlerted.HasValue )
    {
      // Before we find a path, make sure to make the monster and player Cells walkable
      dungeonMap.SetIsWalkable( monster.X, monster.Y, true );
      dungeonMap.SetIsWalkable( player.X, player.Y, true );

      PathFinder pathFinder = new PathFinder( dungeonMap );
      Path path = null;

      try
      {
        path = pathFinder.ShortestPath( 
        dungeonMap.GetCell( monster.X, monster.Y ), 
        dungeonMap.GetCell( player.X, player.Y ) );
      }
      catch ( PathNotFoundException )
      {
        // The monster can see the player, but cannot find a path to him
        // This could be due to other monsters blocking the way
        // Add a message to the message log that the monster is waiting
        Game.MessageLog.Add( $"{monster.Name} waits for a turn" );
      }

      // Don't forget to set the walkable status back to false
      dungeonMap.SetIsWalkable( monster.X, monster.Y, false );
      dungeonMap.SetIsWalkable( player.X, player.Y, false );

      // In the case that there was a path, tell the CommandSystem to move the monster
      if ( path != null )
      {
        try
        {
          // TODO: This should be path.StepForward() but there is a bug in RogueSharp V3
          // The bug is that a Path returned from a PathFinder does not include the source Cell
          commandSystem.MoveMonster( monster, path.Steps.First() );
        }
        catch ( NoMoreStepsException )
        {
          Game.MessageLog.Add( $"{monster.Name} growls in frustration" );
        }
      }

      monster.TurnsAlerted++;

      // Lose alerted status every 15 turns. 
      // As long as the player is still in FoV the monster will stay alert
      // Otherwise the monster will quit chasing the player.
      if ( monster.TurnsAlerted > 15 )
      {
        monster.TurnsAlerted = null;
      }
    }
    return true;
  }
}

Be aware that if you try to Build right now there will be errors. We never added the TurnsAlerted property to our Monster class. Additionally we are missing the MoveMonster method on our CommandSystem.

Note: You may also notice the TODO comment. I discovered a bug in V3 RogueSharp and have a fix for it but for now this is a workaround.

Monster Class Updates

We should make sure we get back to a state where the project will build as quickly as possible. With that in mind open Monster.cs and add a new TurnsAlerted property as well as a PerformAction method that we’ll use later.

public int? TurnsAlerted { get; set; }

public virtual void PerformAction( CommandSystem commandSystem )
{
  var behavior = new StandardMoveAndAttack();
  behavior.Act( this, commandSystem );
}

Did you notice the question mark on the int? property? That’s shorthand for a Nullable<int> type. Since integers are value types they cannot normally be null, however we want a null integer to represent that the monster has not been alerted.

Notice that the PerformAction method is virtual also. Since this is on our Monster base class, we’ll give any monster the StandardMoveAndAttack behavior by default. We can override this in any of our Monster sub-classes to get more interesting behaviors.

Actor Class Updates

At this point we’re still not building, but we are getting closer. Open Actor.cs and make sure that the Actor class implements IScheduleable so that we can add them to our scheduling system.

public class Actor : IActor, IDrawable, IScheduleable
{
  // ... Previous Actor code omitted

  // IScheduleable
  public int Time
  {
    get
    {
      return Speed;
    }
  }
}

CommandSystem Class Updates

We should get our CommandSystem updated now so we can finally build again. Open CommandSystem.cs and add the IsPlayerTurn property as well as the ActivateMonsters() and MoveMonster(…) methods.

Update 1/31/2017 – Added the EndPlayerTurn() method which was accidentally omitted from the code below. Thank you to Zacharry Field for bringing this to my attention.

public bool IsPlayerTurn { get; set; }

public void EndPlayerTurn()
{
  IsPlayerTurn = false;
}

public void ActivateMonsters()
{
  IScheduleable scheduleable = Game.SchedulingSystem.Get();
  if ( scheduleable is Player )
  {
    IsPlayerTurn = true;
    Game.SchedulingSystem.Add( Game.Player );
  }
  else
  {
    Monster monster = scheduleable as Monster;

    if ( monster != null )
    {
      monster.PerformAction( this );
      Game.SchedulingSystem.Add( monster );
    }

    ActivateMonsters();
  }
}

public void MoveMonster( Monster monster, Cell cell )
{
  if ( !Game.DungeonMap.SetActorPosition( monster, cell.X, cell.Y ) )
  {
    if ( Game.Player.X == cell.X && Game.Player.Y == cell.Y )
    {
      Attack( monster, Game.Player );
    }
  }
}

The ActivateMonsters() method is intended to be called after the Player takes a turn. This will proceed to get the next scheduled Actor from the SchedulingSystem. If this happens to be the Player again, we’ll wait for the Player to make a move. Otherwise we’ll have the Monster perform an action and then call ActivateMonsters() again recursively. This will keep having Monsters perform their actions until it is once again the Player’s turn.

Add Player and Monsters to Scheduling System

Open DungeonMap.cs and update the AddPlayer(…), AddMonster(…), and RemoveMonster(…) methods to use the SchedulingSystem. Just add the calls at the end of each method.

public void AddPlayer( Player player )
{
  // ...previous code omitted
  Game.SchedulingSystem.Add( player );
}

public void AddMonster( Monster monster )
{
  // ...previous code omitted
  Game.SchedulingSystem.Add( monster );
}

public void RemoveMonster( Monster monster )
{
  // ...previous code omitted
  Game.SchedulingSystem.Remove( monster );
}

Updating the Game Class

We’re almost done. The rest of the updates will be in Game.cs so open up the file and add a new public property.

public static SchedulingSystem SchedulingSystem { get; private set; }

Make sure to instantiate a new SchedulingSystem in the Main() method.

SchedulingSystem = new SchedulingSystem();

The last set of updates will be made in the OnRootConsoleUpdate(…) method. We need to ensure that it is the player’s turn before handling key presses. We also need to activate monsters after the player has taken their turn.

private static void OnRootConsoleUpdate( object sender, UpdateEventArgs e )
{
  bool didPlayerAct = false;
  RLKeyPress keyPress = _rootConsole.Keyboard.GetKeyPress();

  if ( CommandSystem.IsPlayerTurn )
  {
    if ( keyPress != null )
    {
      if ( keyPress.Key == RLKey.Up )
      {
        didPlayerAct = CommandSystem.MovePlayer( Direction.Up );
      }
      else if ( keyPress.Key == RLKey.Down )
      {
        didPlayerAct = CommandSystem.MovePlayer( Direction.Down );
      }
      else if ( keyPress.Key == RLKey.Left )
      {
        didPlayerAct = CommandSystem.MovePlayer( Direction.Left );
      }
      else if ( keyPress.Key == RLKey.Right )
      {
        didPlayerAct = CommandSystem.MovePlayer( Direction.Right );
      }
      else if ( keyPress.Key == RLKey.Escape )
      {
        _rootConsole.Close();
      }
    }

    if ( didPlayerAct )
    {
      _renderRequired = true;
      CommandSystem.EndPlayerTurn();
    }
  }
  else
  {
    CommandSystem.ActivateMonsters();
    _renderRequired = true;
  }
}

Everything should build now and if you run the game you’ll see that monsters will now chase the player around and attack. The scheduling system that we implemented last time is all hooked up now too.

Final Thoughts

This was a long post with a lot of code but it should pave the way for adding more monsters and more interesting behaviors in the future.

As always the code for the tutorial series so far can be found on Bitbucket:
https://bitbucket.org/FaronBracy/roguesharpv3tutorial/commits/tag/14MonsterBehaviors

Bored waiting for the next tutorial post? The completed project is already available on Bitbucket.

RogueSharp V3 Tutorial – Scheduling System

Next Tutorial Post – Monster Behaviors
Previous Tutorial Post – Simple Combat

Goal

During this tutorial we will create a Scheduling System. Some roguelikes also refer to these as time systems. You can find out how lots of developers create their time systems by reading the Roguelike Dev Subreddit FAQ Friday #41.

Scheduling System Details

Most roguelikes including this tutorial are turn-based, meaning each Actor acts on their turn. The simplest way to achieve this is to just have a giant queue structure and have everyone act in order one-by-one. When the actor is removed from the queue and takes their turn then they get re-added to the back of the queue. The player goes, and then each monster takes a turn, then the player takes their turn again and so on.

Unfortunately if we did something that simple it wouldn’t be very interesting. All Actors would have the same speed. Effectively this would mean that you could never run away from monsters or catch a fleeing monster.

To get around this issue we will give each Actor a Speed statistic which will represent how often they can take actions. You may even remember in a previous tutorial where we defined stats we already allocated a Speed stat. We just never got around to using it, but we are about to fix that!

The concept behind our scheduling system is that it will keep track of the time or number of turns that have passed as well as the current time. The Speed of the actor will determine when they get inserted into the timeline. Note that in this case having a lower speed is better.

SchedulingSystem

Example Schedule

In the Example Schedule above notice that during the first 12 turns the player with a speed of 4 will have acted 3 times. The goblin with a speed of 3 will have acted 4 times. And the Ooze with a speed of 6 will have only acted twice. This means that a player would be able to easily outrun an ooze, but not the goblin. The goblin moves twice as fast as the ooze.

Data Structure

To represent this data structure in code we will use a SortedDictionary<int, List<IScheduleable>>. This may look a little odd at first, but all it really means is that Key in the dictionary is an integer that represents the time. The Value of each dictionary entry is a List<IScheduleable>. But what exactly is an IScheduleable? It’s a custom interface that we’ll make and it will just have a single property Time. What we are saying is that we can put anything on the schedule as long as it has a Time which represents how many turns pass until its time comes up again on the schedule. Add the IScheduleable.cs file to the Interfaces folder and add the following code.

public interface IScheduleable
{
  int Time { get; }
}

So now that we see what an IScheduleable is, the next question is why do we have a List<> of them for each key in the dictionary? The answer goes back to our to our Example Schedule. If you look at it closer you’ll notice that more than one Actor can act on the same time interval. At Time 6 both the Ooze and Goblin act. At time 12 all three act.

Let’s go ahead and create SchedulingSystem.cs in the Systems folder.

public class SchedulingSystem
{
  private int _time;
  private readonly SortedDictionary<int, List<IScheduleable>> _scheduleables;

  public SchedulingSystem()
  {
    _time = 0;
    _scheduleables = new SortedDictionary<int, List<IScheduleable>>();
  }

  // Add a new object to the schedule 
  // Place it at the current time plus the object's Time property.
  public void Add( IScheduleable scheduleable )
  {
    int key = _time + scheduleable.Time;
    if ( !_scheduleables.ContainsKey( key ) )
    {
      _scheduleables.Add( key, new List<IScheduleable>() );
    }
    _scheduleables[key].Add( scheduleable );
  }

  // Remove a specific object from the schedule.
  // Useful for when an monster is killed to remove it before it's action comes up again.
  public void Remove( IScheduleable scheduleable )
  {
    KeyValuePair<int, List<IScheduleable>> scheduleableListFound 
      = new KeyValuePair<int, List<IScheduleable>>( -1, null );

    foreach ( var scheduleablesList in _scheduleables )
    {
      if ( scheduleablesList.Value.Contains( scheduleable ) )
      {
        scheduleableListFound = scheduleablesList;
        break;
      }
    }
    if ( scheduleableListFound.Value != null )
    {
      scheduleableListFound.Value.Remove( scheduleable );
      if ( scheduleableListFound.Value.Count <= 0 )
      {
        _scheduleables.Remove( scheduleableListFound.Key );
      }
    }
  }

  // Get the next object whose turn it is from the schedule. Advance time if necessary
  public IScheduleable Get()
  {
    var firstScheduleableGroup = _scheduleables.First();
    var firstScheduleable = firstScheduleableGroup.Value.First();
    Remove( firstScheduleable );
    _time = firstScheduleableGroup.Key;
    return firstScheduleable;
  }

  // Get the current time (turn) for the schedule
  public int GetTime()
  {
    return _time;
  }

  // Reset the time and clear out the schedule
  public void Clear()
  {
    _time = 0;
    _scheduleables.Clear();
  }
}

Quite a bit of code and if we run the game again nothing will have changed since the last tutorial. We won’t get a chance to actually see our scheduling system in action until next time.

As always the code for the tutorial series so far can be found on Bitbucket:
https://bitbucket.org/FaronBracy/roguesharpv3tutorial/commits/tag/13SchedulingSystem

Bored waiting for the next tutorial post? The completed project is already available on Bitbucket.