Taking Action – Striding Into Battle

My focus this week has been to start work implementing the three-action system that is the core of Pathfinder 2E’s mechanics and allowing the player to start doing things besides ending their turn when in combat. With this being such a fundamental part of the system, I spent a while thinking about how I want to code it, which has meant other progress has been slower than usual. However, hopefully the time invested designing the system will mean that adding new actions will be faster and easier in the future.

A quick aside here – PF2E’s rules refer to Action as the resource you spend on your turn to take Actions. I think this is a bit confusing, so from here on out I’m going to use Action Point as the resource you spend to take an Action.

Thinking about actions

There are many actions in PF2E and many feats tend to adjust existing actions, create composites of existing actions, or both. To facilitate this, I want it to be easy to dynamically modify actions, and I want to be able to add new modifications or composite actions without needing to hard code them.

A couple of example actions are:

• Stride – move up to your speed
• Strike – attack another combatant with one of your currently equipped weapons
• Aid – help out an ally
• Step – move one square without triggering enemy reactions
• Sudden charge – Stride twice and then Strike an adjacent enemy
• Sheathe Weapon – put away your current weapon

My first thought was to try and group the actions by common themes. I thought that there might be three distinct groups:

• Movement
• Self-targeted
• External target

The actions I mentioned before can be placed into these groups reasonably well:

• Stride – Movement
• Step – Movement
• Strike – External Target (hostile)
• Aid – External Target (ally)
• Sheathe Weapon – Self-Targeted
• Sudden Charge – Composite – Movement, followed by External Target (hostile)

But I quickly realised that some actions didn’t fit neatly into these groups – e.g. is interacting with your inventory self-targeted or an external target? How does Sheathe Weapon work when you have multiple weapons? And having a generic function to pick target could quickly become an absolute mess of spaghetti code in multiple places. I think there could be some merit to these groupings in the future, but, for the time being, they’re not the best way for me to try and solve my problem.

After some more retrospection, I decided that I might be trying to make my solution too clever, which is a trap a lot of us software developers fall into – it’s not enough to just make something work, we need to prove to ourselves that we can do it in a more generic way that is “easy” to extend… but often ends up being an overly complicated mess.

So going back to basics, I decided that I should hard-code PF2E’s basic actions, as defined in the Pathfinder Rules, and code a way to substitute modifications or build composite actions which are loaded in from config files. Stride, Strike and Step are all in here. Sheathe Weapon falls into Interact. Sudden Charge is still a composite action – I could do this as either Stride, Stride, Strike, or Stride with a x2 speed modifier followed by Strike.

This feels like a good compromise to allow me to make progress while providing me with a solid foundation to build new actions on in the future. I’m sure that I will spot ways to make my solution more elegant as I continue to add new actions, and that’s fine.

Time to start building my first action – Stride!

Tracking action points

Alright, this isn’t actually building the action, but it is something that will help me check that actions are working correctly, and it is something that the player will need to see. I’ve created an Action Point Bar which updates when points are spent or refunded at the beginning of the turn

I placed this in the bottom left corner, which, in my initial UI thoughts when I was Starting the Combat Scene, is where I want the player to see a summary of the active character.

When the player takes actions, the filled box changes to an empty border. Simple, but effective for now.

Whose turn is it anyway?

Another deviation from “just get an action working” – at the moment, the player has no idea which token is taking its turn. This will be mitigated somewhat in the far future when tokens use a character portrait, but I wanted a way to see which token I’m controlling during testing. My quick and dirty solution was to add a border around the active combatant.

Where can I move?

I started writing the Stride action by coding the algorithm for finding valid locations for a combatant to move to. The algorithm has the following steps:

1. Start at the combatant’s square
2. Add the combatant’s square to the list of checked squares with a movement cost of 0
3. Loop through the neighbouring squares that are not occupied by an enemy or otherwise impassable
4. Add the valid neighbours to the list of checked square, recording the total movement cost to reach that square, and the route taken
5. Repeat steps 3 and 4 for each neighbour until every neighbouring square is beyond the combatant’s movement range
6. Filter out invalid destinations (e.g. squares occupied by allies)

When the player selects the Stride action, this algorithm runs and the results are passed up to the battlemap, where the valid squares are then highlighted.

Since I’m recording the route to each square as the valid movement is analysed, it was easy to display the path the combatant will taken when the player hovers their mouse over a specific square.

I’d like to implement waypoints later so that the more tactically-minded players can control the characters’ movement in a more granular way – e.g. to avoid enemies and traps.

When selecting a space to move to, the selected square is fed back into the game’s logic. With the route already recorded, it’s pretty easy to work out where the token has to move so that it travels along the path indicated. So now all that’s needed is to let the player select the target location.

We’re finally moving!

To confirm moving a combatant to a specific square, the player just has to right click and off we go!

I initially tuned the speed at which a token moves on the map to be far, far too slow. So let’s try again with increased speed.

Turns out I forgot to clear the array of squares for the token to move into. Part of PF2E’s combat system, reactions, will require me to broadcast that a combatant is moving out of their current square, so I initially structured the movement path code so that it keeps the current location in the movement array. The movement code broadcasts that location, removes it, and then takes the next square as the one to move into. If there’s only one square left, it just marks movement as complete. To solve this bug, I just needed to make sure the array is cleared when movement is marked as complete.

Finally the player can move their characters around the map! It could be a bit smoother, and there are definitely some quality of life improvements to be made, but it is working, and you can see that the action points in the bottom left corner decrease at the end of the stride. Success!

What about the enemies?

I think it’s only fair that the enemies get to move too, and that’s my main goal for next week. I can already see, however, that I’m going to have to do some research on how to create enemy behaviours that try to pick the best position in a way that’s relatively easy to extend once I start adding in things like the ability to strike and more complex information such as debuffs.

Thank you for reading!