The Top Down settings for entities provides an easy way to implement top-down movement for a character. It can be extended to support any input device, multiple sets of movement variables, and animation.

Introduction

The CurrentMovement property controls the values used by the top down entity in response to input values. This value can be changed according to various conditions in your game such as:

• Collision with different terrain (such as walking through mud)

• Responding to power-ups (such as collecting a power-up which increases speed)

• Responding to special moves or input which changes the character's movement variables (such as holding down a run button)

Defining Movement Values

Movement values can be defined in Glue or code. If your game has a limited set of movement values, these can be defined in Glue. To define a movement value in Glue:

1. Select the entity

2. Click the Entity Input Movement tab

3. Verify that your entity is using the Top Down option for Input Movement Type

4. Click the Add Control Values button
5. Modify the newly-added movement values as necessary

The Top Down tab displays all movement values for the selected entity.

Assigning Movement Values

You can assign the current movement values in code through the CurrentMovement propety. For example, the following code assigns the movement to FastMovement or Default depending on the state of an Xbox360GamePad:

var gamepad = InputManager.Xbox360GamePads[0];
if(gamepad.ButtonDown(Xbox360GamePad.Button.B))
{
    this.CurrentMovement = TopDownValues[DataTypes.TopDownValues.FastMovement];
}
else
{
    this.CurrentMovement = TopDownValues[DataTypes.TopDownValues.Default];
}

Introduction

This tutorial covers how to create enemy movement in a top down game with direct control over the enemy's input device. Compared to the Enemy Pathfinding tutorial, this tutorial shows how to directly control the input device manually. This approach is considered low level and is not recommended for beginners. If your game includes enemies which can pathfind through a map then the Enemy Pathfinding tutorial is recommended.

New Project Setup

This project tutorial assumes a Top Down Standard starting point (using the wizard), but the steps here can be used to add an Enemy entity to any project. We assume that the game already has levels.

Enemy Entity

We'll be creating a new Enemy entity for this tutorial. To do this:

1. Click the Quick Actions tab

2. Click the Add Entity button
3. Enter the name Enemy

4. Check AxisAlignedRectangle

5. Check Top-Down for the Input Movement Type

6. Leave the rest of the defaults and click OK

We will also change the color of the enemy rectangle to tell it apart from the player:

1. Expand the Enemy Object folder

2. Select AxisAlignedRectangleInstance

3. Select the Variables tab

4. Change Width to 16

5. Change Height to 16

6. Change Color to Red

Adding an Enemy to Level1

To add an enemy to Level1:

1. Expand the Screens folder, then expand Level1's Objects folder

2. Select the EnemyList

3. Click the Quick Actions tab

4. Click Add a new Enemy to Enemy List
5. Modify the X and Y values for the new enemy so it is inside of the level boundaries by changing X to 160 and Y to -160

Setting the InputDevice

So far our Enemy instance is an entity with no behavior - it simply stays in the same spot when the game runs. First, we'll mark it as using Top-Down movement:

1. Select the Enemy entity

2. Click the Entity Input Movement tab

3. Set Input Movement Type to Top-Down

4. Set Input Device to None (Can Assign in Code)

Now our Enemy has the behavior of top-down movement, but it is not using an input device for movement. Custom input can be set by defining an input device class which inherits from FlatRedBall.Input.InputDeviceBase. To do this:

1. Open the project in Visual Studio

2. Create a new class called EnemyInput. Mine is in an Input folder.

The EnemyInput class needs to inhert from the FlatRedBall.Input.InputDeviceBase class which provides virtual methods to control how the input device behaves. Although the InputDeviceBase class offers many virtual methods, the only two that the top-down movement logic uses are:

• GetDefault2DInputX

• GetDefault2DInputY

We can override these to return values between -1 and 1. In this case we'll return constant values to test the functionality, as shown in the following code snippet.

internal class EnemyInput : FlatRedBall.Input.InputDeviceBase
{
    protected override float GetDefault2DInputX()
    {
        return 1.0f; // 1 means all the way to the right
    }
    protected override float GetDefault2DInputY()
    {
        return -.5f; // Negative values are down, so -.5 means halfway down
    }
}

Next we need to assign the EnemyInput on the Enemy. To do this:

1. Open the Entities/Enemy.cs file in Visual Studio

2. Modify the CustomInitialize as shown in the following snippet:

public partial class Enemy
{
    private void CustomInitialize()
    {
        var input = new Input.EnemyInput();
        this.InitializeTopDownInput(input);
    }
    ...

Now we can run the game and see the enemy move down to the right.

Building the Enemy Input

This tutorial primarily shows how to create an EnemyInput class which can be used to control your enemy. So far the device returns constant values for GetDefault2DInputX and GetDefault2DInputY. A real game would use logic to determine what to return, such as the position of the Player, or how far along the enemy has moved along a patrol path.

At this point the rest of the implementation is up to you depending on your needs.

Introduction

This tutorial provides information on how to change the input device used by the entity. By default the entity uses the first Xbox game pad if one is available, otherwise the entity uses the keyboard. Sometimes this functionality is not desired, such as if the game supports multiple players or AI-controlled entities.

IInputDevice

The Top Down entity code interacts with the IInputDevice interface, which provides a standard set of values for controlling game objects. Both the Xbox360GamePad and Keyboard implement this interface, so if the default implementation for this interface meets your game's needs, you can use these objects as-is. Otherwise, your game can implement its own IInputDevice to change how the top down entity is controlled. First we'll look at how to customize the input to use different keyboard keys.

Changing Input Keys

As mentioned earlier, our Player entity defaults to using an Xbox gamepad if one exists. If not, it uses the keyboard. Even though we won't customize this code, we can see its implementation by looking in Player.Generated.cs and searching for InitializeInput.

Ultimately, these calls make their way to calling CustomInitializeTopDownInput. Since this is a partial method, we need to add it ourselves to our Player if we want to customize the input. To do this:

1. Go to Player.cs

2. Add the following code to the Player.cs file

partial void CustomInitializeTopDownInput()
{
 this.MovementInput = InputManager.Keyboard.Get2DInput(
    Microsoft.Xna.Framework.Input.Keys.J, // Key for left movement
    Microsoft.Xna.Framework.Input.Keys.L, // Key for right movement
    Microsoft.Xna.Framework.Input.Keys.I, // Key for up movement
    Microsoft.Xna.Framework.Input.Keys.K);// Key for down movement
}

The player will now move around with the IJKL keys (rather than the default WASD). Note that this will also override input even if you have an Xbox gamepad plugged in. If this is not desired, we can change the input if it's using the keyboard. This is an example of how to keep the input device, but only change the movement code conditionally:

partial void CustomInitializeTopDownInput()
{
 if(this.InputDevice is Keyboard keyboard)
 {
   this.MovementInput = keyboard.Get2DInput(
     Microsoft.Xna.Framework.Input.Keys.J, // Key for left movement
     Microsoft.Xna.Framework.Input.Keys.L, // Key for right movement
     Microsoft.Xna.Framework.Input.Keys.I, // Key for up movement
     Microsoft.Xna.Framework.Input.Keys.K);// Key for down movement
 }
}

This code could contain further updates to change desired input based on other input devices such as Xbox360GamePad.

Changing Input Device

The code in the section above modifies which keys are used from the keyboard. It could be expanded to also handle other input devices like Xbox gamepads. However, instead of changing which keys are used when using the keyboard, you may want to change which input device is being used by your player. This is typically done in the GameScreen. This allows the GameScreen to initialize input, especially if your game allows the player to pick which input device to use. For example, to force the player to always use an Xbox gamepad, modify the following code in the GameScreen's CustomInitialize:

void CustomInitialize()
{
 // Forces the player to use the first Xbox gamepad:
 Player1.InitializeTopDownInput(InputManager.Xbox360GamePads[0]);
}

Creating Multiple Players

If your game followed the previous tutorials, then your GameScreen has a PlayerList with a single Player named Player1. In this setup, the GameScreen will always have at least 1 player, but can have more. A quick way to support multiplayer without any UI is to detect the number of Xbox gamepads plugged in. If more than 1 is plugged in, we can create additional players very easily. The following code will create one player per Xbox gamepad plugged in. Notice that we only create additional players if we have two or more gamepads since the first player is automatically created.

void CustomInitialize()
{
 var connectedGamepads = InputManager.Xbox360GamePads
   .Where(item => item.IsConnected)
   .ToArray();

 for(int i = 0; i < connectedGamepads.Length; i++)
 {
   // By default the FlatRedBall project includes one instance of a player, so we don't
   // need to create one for index 0
   if(i > 1)
   {
     // create the player:
     var player = new Player();
     PlayerList.Add(player);
   }
   PlayerList[i].InitializeTopDownInput(connectedGamepads[i]);
 }
}

To see more than one player you must have at least two gamepads plugged in to your computer. Also, keep in mind that the players will initially overlap so you must move one to see both.

Introduction

This tutorial sets up an entity with Top Down controls. It provides a default implementation which requires no code. Later tutorials show how to interact with this plugin using code.

Requirements

The FRB Editor provides support for top-down entities through the Entity Input Movement tab. Any entity can be created as a Top Down entity; however, the most common setup is to have a Player entity which uses top down controls.

Empty projects can use the Project Setup Wizard to create a top down player entity. Existing games can add top down controls to new or existing entities with a few clicks. This tutorial shows you how to do both.

Project Setup Using the New Project Wizard Preset

The simplest way to set your project up is to use the new project wizard. FlatRedBall automatically launches the wizard when creating a new project.

To create a top-down project, select the Standard Top Down button.

Now your game should be set up with a fully-functional top-down entity. You can verify this by clicking on the Player entity and then clicking on the Entity Input Movement tab. The Player should be marked as having Top-Down as its Input Movement Type.

Alternative - Manually Creating GameScreen and Player Entity

This section will explain how to manually add a GameScreen and Top-Down entity. You do not need to follow this section if you have used the wizard as shown in the previous step.

1. Select the Quick Actions tab

2. Click the Add Screen button
3. Click OK to the default GameScreen name (all games should have a single GameScreen)

To add a Player entity:

1. Click the Add Entity button
2. Name the entity Player

3. Check:

   1. Circle under Collisions

   2. Top-Down under Input Movement Type
4. Leave the rest of the defaults and click OK

If you already have an entity created, you can make it a Top Down entity:

1. Select the entity

2. Click the Entity Input Movement tab

3. Click the Top-Down option

By default your GameScreen should have a list of Players (it was an option earlier when creating the Player entity). We recommend always creating a list of Players even if you intend to only have one player. This standard appears throughout FlatRedBall's documentation and can make moving from one project to another easier.

If you did not add a PlayerList earlier by keeping the Include lists in GameScreen, or if you created your GameScreen after your Player, you can manually add a PlayerList by following these steps:

1. Verify Player is selected

2. Click the Quick Actions tab

3. Click the Add Player List to GameScreen button

You will also need a Player instance in the list. To do this, drag+drop the Player onto the GameScreen and it will be added to the Player list.

Moving the Entity

Now that the entity is marked as a Top Down entity and now that we have an instance of the entity in the GameScreen, we can run the game and see the player move. By default the entity uses a gamepad if one is connected. Otherwise, the entity will use WASD keys on the keyboard.

Introduction

Enemy pathfinding allows enemies to navigate through complex levels. This can be used to move to a target position (such as a patrol point) or follow an entity (such as enemies chasing a player). This tutorial shows how to create a pathfinding enemy. Specifically, it covers the following topics:

• Creating a TileNodeNetwork which defines the walkable parts of a map

• Creating an input device which is used to control the enemy so it follows its desired path

• Creating line-of-sight pathing for more natural movement

Creating a TileNodeNetwork

First we'll create a TileNodeNetwork. This is defined in our GameScreen, but will use the Map for each level. For a more thorough walkthrough of creating a TileNodeNetwork, see the TileNodeNetwork page.

To create the TileNodeNetwork:

1. Select the GameScreen

2. Click the Add Object to GameScreen under Quick Actions, or right-click on GameScreen and select Add Object

3. Select the TileNodeNetwork type

4. Enter a name such as WalkingNodeNetwork

5. Click OK

Next we'll define a tile to use for pathfinding. To do this:

1. Open any of your levels in Tiled

2. Select the Tileset that you use for your GameplayLayer. By default this is called TiledIcons

3. Click the wrench to edit the Tiles

4. Select a tile that you would like to use for pathfinding

5. Change the Class for that tile to WalkableTile

6. Save your tileset (TSX)

Next, select your current level (such as Level1Map) and paint the WalkableTile onto the GameplayLayer. Note that if you would like to be able to walk on areas which already have other tiles, you can create a new layer specifically for Tiles.

Be sure to save both your level and the tileset.

Finally, we can indicate that the WalkableTile should be used to populate the nodes in the Tile:

1. Select the WalkingNodeNetwork Object under GameScreen

2. Click the TileNodeNetwork Properties

3. Select the From Type option

4. Select Map as the Source TMX File/Object

5. Select WalkableTile as the Type

Optionally, you may want to also set the Visible variable to true so the TileNodeNetwork shows up in your game.

The game should now show the TileNodeNetwork. Note that you can also make the GameplayLayer invisible in Tiled so that the TileNodeNetwork is easier to see in game.

Notice that the links between nodes are either vertical or horizontal. We will discuss diagonal movement later in the tutorial.

Creating Enemy InputDevice

Now that we have a TileNodeNetwork defined, we can create an input device. Of course, we need to have an Enemy defined. For this tutorial I'll use a simple enemy with the following characteristics:

• It is named EnemyBase - this naming convention is used so that the enemy could be used as a base Entity for derived variants. Larger games would likely need multiple enemy types so this sets up to expand easily.

• The Enemy has a single Circle collision. More complex games may include multiple types of collision, but it's important to note which collidable object will be used as the solid collision - we'll use this for line-of-sight pathfinding later in this tutorial.

• The enemy uses the Top-Down movement types, just like the Player.

• The enemy's InputDevice is set to None. As indicated in the FRB Editor, this must be assigned in code or the game will crash.

Next we'll define the InputDevice. You may be familiar with the InputDevice as hardware input which can control the movement of the Player (such as the Keyboard or Xbox360GamePad). Although these are common implementations of the input device (IInputDevice interface), the concept of an InputDevice is something which can be read by an Entity (such as the Enemy) to determine how it should move.

In this case the InputDevice will not be tied to actual hardware. Instead, we will return input values which move the EnemyBase through the map by following the path obtained from the WalkingNodeNetwork.

Fortunately, the TopDownAiInput class is an InputDevice which automatically returns these movement values according to a desired path.

First, we will assign this InputDevice in the EnemyBase's CustomInitialize:

TopDownAiInput<EnemyBase> topDownAiInput;

private void CustomInitialize()
{
    topDownAiInput = new TopDownAiInput<EnemyBase>(this);

    // This helps us visualize the path the EnemyBase takes to get to
    // the player
    topDownAiInput.IsPathVisible = true;
    // Use a darker color so it stands out over the bright level tiles
    topDownAiInput.PathColor = Color.Purple;
    this.InitializeTopDownInput(topDownAiInput);
}

void CustomDestroy()
{
    // The top down input path must be made invisible so it cleans up
    // any shapes it creates in the path:
    topDownAiInput.IsPathVisible = false;     
}

Notice that the topDownAiInput is defined at class scope - this lets us access it in other methods without needing to cast the InputDevice every time. Also, the IsPathVisible and PathColor properties can be used to control the appearance of the path that the EnemyBase is going to take to get to the player. We will enable this to show the path. Also, it may be worth turning off the WalkingNodeNetwork visibility so that the EnemyBase path can be seen more clearly.

Initializing TopDownAiInput

Next, we'll create a method to set up the node network and target player. Add the following to EnemyBase.cs:

public void InitializePathfinding(Player player, TileNodeNetwork nodeNetwork)
{
    topDownAiInput.FollowingTarget = player;
    topDownAiInput.NodeNetwork = nodeNetwork;
}

For this tutorial we assume a single player which never changes. A multiplayer game may require changing the target based on which player last hit the enemy, proximity, or whether the current target is dead.

Also, note that this method must be called by the GameScreen. We will add the code to call this method later in this tutorial.

Finally, we can set the path to follow the player in CustomActivity.

// initialize it to a large negative number so the path updates immediately
double lastTimePathUpdates = -999;
// how often the path should update. We do this to improve performance
double pathUpdateFrequency = 1;
private void CustomActivity()
{
    if(TimeManager.CurrentScreenSecondsSince(lastTimePathUpdates) > pathUpdateFrequency)
    {
        lastTimePathUpdates = TimeManager.CurrentScreenTime;
        topDownAiInput.UpdatePath();
    }
    // We only call UpdatePath once every second since that doesn't need
    // to update too requently, but this should be called every frame so the
    // enemy's movement values are updated according to its path.
    topDownAiInput.DoTargetFollowingActivity();
}

Notice that this code only updates the path every second. Updating the path is a fairly quick operation, but it can be expensive if the game includes hundreds of EnemyBase instances. We'll check once per second to prepare for a larger game.

Now that our EnemyBase has the code it needs to pathfind to the player, we can add code to the GameScreen to call InitializePathfinding.

EnemyBase instances can be created both before and after GameScreen.CustomInitialize is called, so we must handle both cases.

To handle EnemyBase instances created before CustomInitialize is called (if they have been added directly to a level in the FRB Editor or live edit), we can loop thorugh EnemyBaseList and call InitializePathfinding.

To handle EnemyBaseInstances created after CustomInitialize (if they are added using a factory or variant object such as through a spawner) we can subscribe to the factory method. Note that a game which has derived enemy variants must subscribe to all derived variant factories to handle creation.

Modify the GameScreen.cs to include the following code:

void CustomInitialize()
{
    // This foreach handles enemies created before the screen's initialize.
    foreach(var enemy in EnemyBaseList)
    {
        PrepareEnemyPathfinding(enemy);
    }
    // This event handler handles enemies created after the screen's initialize.
    Factories.EnemyBaseFactory.EntitySpawned += PrepareEnemyPathfinding;
}

private void PrepareEnemyPathfinding(EnemyBase enemy)
{
    // This assumes Player1 is already created. If your game
    // creates its Player instances later, you need to make sure
    // the Player instance has already been created before this is
    // called.
    enemy.InitializePathfinding(Player1, WalkingNodeNetwork);
}

Finally, we can add the following code to GameScreen to create EnemyBase instances when clicking with the mouse.

void CustomActivity(bool firstTimeCalled)
{
    FlatRedBallServices.Game.IsMouseVisible = true;
    if(GuiManager.Cursor.PrimaryClick)
    {
        Factories.EnemyBaseFactory.CreateNew(GuiManager.Cursor.WorldPosition);
    }
}

We can now click to place EnemyBase instances. Each EnemyBase instance follows the player according to pathfinding along the WalkingNodeNetwork and the position of the Player.

Notice that the EnemyBase moves fairly quickly - the same speed as the Player. You may want to reduce the EnemyBase's movement speed to make it easier to test pathfinding.

Customizing Pathfinding Behavior

So far we can create an EnemyBase by clicking in the game. The enemy base instance follows the player using the WalkingNodeNetwork. We have lots of options for customizing the way the enemy follows the player.

First, you may nave noticed that the enemy follows the player on a path by only moving horizontally or vertically. The reason for this is because our WalkingNodeNetwork is set up to only have four links per node: up, down, left, and right. we can include diagonal nodes to allow the enemy to also move diagonally.

Some games, such as the Legend of Zelda on the NES and the 2D Final Fantasy games do not allow the player, NPC, or enemies to move diagonally. If this limitation matches your game, then you can keep this default setup.

However, if your game requires diagonal movement, you can enable it in the TileNodeNetwork properties for the WalkingNodeNetwork.

Now our EnemyBase instance can travel diagonally.

You may have noticed that at times the EnemyBase backtracks - in other words at times the enemy seems to walk backwards rather than following its path. This can happen when the path is re-evaluated. The new path requires the enemy to move backwards slightly to move to its next node.

To help explain this problem we can visualize a simple path that an enemy may take. It's important to remember that each node in the TileNodeNetwork is always placed at the center of the tile. The following image shows an example path. The blue circles represent the node positions, the red circle represents the enemy, and the purple lines represent the path the Enemy takes.

Notice that the enemy moves directly towards the first node diagonally. This happens regardless of where the enemy is located - by default the very first segment in the path connects the enemy to the path. In this case the movement seems to be what we might expect, but in some situations the enemy may be positioned such that its first movement requires it to backtrack, as shown in the following image:

Notice that in this case the closest node to the enemy is to the right of the enemy. Therefore, the first movement segment has the enemy moving to the right before it resumes moving to the left.

We can solve this by removing the first segment of the path, but only if the path has more than one point. If there is exactly one point in the path, then we should not remove it since the enemy is near its final target.

We can modify our code as shown in the following EnemyBase.CustomActivity:

private void CustomActivity()
{
    if(TimeManager.CurrentScreenSecondsSince(lastTimePathUpdates) > pathUpdateFrequency)
    {
        lastTimePathUpdates = TimeManager.CurrentScreenTime;
        topDownAiInput.UpdatePath();

        // Remove the first node in the path to prevent backtracking
        if(topDownAiInput.Path.Count > 2)
        {
            topDownAiInput.Path.RemoveAt(0);
            topDownAiInput.NextImmediateTarget = topDownAiInput.Path[0];
        }
    }
    topDownAiInput.DoTargetFollowingActivity();
}

Note that while this approach does solve the backtracking problem, it can at times cause the enemy to move diagonally to the next node in a way which may result in getting stuck behind collision.

The reason we discuss this solution is not necessarily to suggest that this is the best solution for backtracking for production games, but rather to show that the TopDownAiInput object allows you to manipulate its Path at any time. You can perform more advanced logic to determine if backtracking will occur, and to remove, add, or modify existing nodes to correct for this problem according to your game's specific needs.

Collision and Corner Clipping

At this point our enemies can pathfind but they do not respect the level's solid collision. If we enable collision we will notice that this introduces a number of problems.

To enable collision between EnemyBase and the leve's SolidCollision:

1. Expand GameScreen's Objects folder

2. Drag+drop EnemyBaseList onto SolidCollision

3. Verify that the newly-created CollisionRelationship is using BounceCollision

4. Change the elasticity to 0 so that the EnemyBase doesn't actually bounce off the wall. By setting it to 0 the wall absorbs the EnemyBase's velocity.

If we run our game now we'll notice that the enemy gets stuck when trying to follow the player along any collision.

This is happening because the collision on our enemy is too big - it has a circle with a radius of 16. This prevents it from getting close enough to tiles to properly pathfind. We can fix some of the problems by changing the EnemyBase's CircleInstance radius to a smaller value. A value of 8 allows the EnemyBase to touch the center of a tile, so we will change the value to 8.

This change helps pathfinding, but it doesn't solve all of the problems. If your game is using diagonal movement, you may notice that the enemy slows down when colliding against corners. We can force the enemy to pathfind around a house. Notice the enemy slows down when moving around corners.

This is occurring because we have enabled 8-way pathfinding, and this includes corner pathfinding. We can set our node network visibility to true to see that the node networks cut corners, in other words diagonal paths connect nodes which result in the EnemyBase attempting to push against a corner collision.

We can disable corner cutting through an option in the TileNodeNetwork Properties tab:

Now our tile node network still supports diagonal movement, but it will not attempt to move diagonally around corners as shown in this screen shot:

Line of Sight Pathfinding

So far we have made modifications to the EnemyBase entity and the WalkingNodeNetwork to address problems with collision, but one issue still remains - our enemy movement still feels unnatural. We can solve this problem by implementing line-of-sight pathfinding. This form of pathfinding initially uses the TileNodeNetwork to determine which path it should take, but it then eliminates nodes along the path if a more direct path is available. This allows an entity to move in any direction and it can make pathfinding feel more natural.

Of course, keep in mind that your game may intentionally have pathfinding strictly along a node network so whether you use line of sight pathfinding can be a stylistic choice.

To enable line of sight pathfinding, the TopDownAiInput must have two additional pieces of information:

1. The width of the collision. This is needed because line of sight pathfinding must check if a direct path exists to the target and also if following that direct path results in bumping against solid collision.

2. The solid collision to avoid

We can enable line of sight pathfinding by modifying the InitializePathfinding method as shown in the following code:

public void InitializePathfinding(Player player, TileNodeNetwork nodeNetwork, 
    FlatRedBall.TileCollisions.TileShapeCollection collision)
{
    topDownAiInput.FollowingTarget = player;
    topDownAiInput.NodeNetwork = nodeNetwork;

    topDownAiInput.SetLineOfSightPathfinding(CircleInstance.Radius * 2, 
        // This can take multiple shape collections since some games use more than one
        // TileShapeCollection for pathfinding
        new List<FlatRedBall.TileCollisions.TileShapeCollection> { collision });
}

Notice that we use CircleInstance.Radius*2 to determine the width of the entity. If using a different shape, or multiple shapes, your code needs to account for this. Also, keep in mind to also add any offsets if your shape is not centered on the X or Y. Finally, you may need to increase this value if your collision shapes can adjust during runtime - such as being modified by AnimationChains.

Since this method now requires passing in a TileShapeCollection, we need to modify GameScreen.PrepareEnemyPathfinding to pass in the SolidCollision as shown in the following code:

private void PrepareEnemyPathfinding(EnemyBase enemy)
{
    // This assumes Player1 is already created. If your game
    // creates its Player instances later, you need to make sure
    // the Player instance has already been created before this is
    // called.
    enemy.InitializePathfinding(Player1, WalkingNodeNetwork, SolidCollision);
}

Now our enemy follows the player directly if there is a line of sight. If not, the enemy performs line of sight checks to skip nodes which are not necessary. Notice that when navigating tight spaces the enemy follows the node network, but when navigating open spaces the enemy moves more directly towards its target.

Conclusion

This tutorial has shown how to create an enemy that performs pathfinding towards a player. This pathfinding can be customized to address common problems, to enable or disable diagonal movement, and to use line of sight pathfinding for more natural movement.