Attempt 1:
We tried to cut out a hole around the standing characters that would be impassable for the current moving fighter. This idea had a few significant drawbacks. First of all, the hole was rather large, which in some cases could prevent coming closer to a target, although it looked possible. Second of all, a large character could walk up to a small one, stop and cut out a huge hole around them – and the small character might end up inside that hole, not being able to move at all. But the idea was completely killed off by the fact that the hole-cutting algorithm just didn't work: sometimes it cut out more than needed, making a chunk of the map impassable. We tried to update the version of the library we used for pathfinding, but it got even worse: for some reason the new version made all the carpets in Jamandi's mansion impassable. In light of all the other drawbacks, we decided to drop it and try the next option.
Attempt 2:
Navmesh triangles are bad for recording the characters' dynamic position. And what's good? A good old square mesh. It's very easy to determine which square or even squares the fighter occupies and forbid all the others to move through them. Also, if the squares are small enough, nothing but them will be blocked. So why not use the mesh from the start? Because it has much, much more squares than navmesh has triangles. This is why path finding through them is much slower – too slow for real-time combat, where all the characters want to move all the time. But in turn-based combat only one character is moving...
To implement this idea, we had to add a mesh created using navmesh data to every map in the game. We couldn't use 5-foot squares as in the tabletop game – this would require recreating all the maps, since no one had a 5-foot mesh in mind when creating them. So, as a result, a 5-foot wide door could take up parts of two real squares. This is why we made the squares a little smaller, 0.5m each, and tried to make the areas available for passage on each map match as much as possible for both pathfinding methods.
Red cubes – impassable squares of the square navigation mesh
Doors were a separate challenge. When you open or close them, they change the impassable area position every frame of their animation. A special code makes sure these changes are reflected in the mesh.
On the whole, we were happy with what we achieved, although we had to work very hard and even fix a few bugs in third party code that we use, which didn't manifest during movement in RTwP. But the new pathfinding method gave us a chance to show the player exactly how their character would move to the selected target, and even warn them about possible Attacks of Opportunity along the way.
Predicting movement trajectory. Green - Move Action, yellow - Standard Action, red - sections where the player will get an Attack of Opportunity.
Prediction panel
By adding a turn-based mode to the game, we not only wanted to make the game more enjoyable for those who prefer this style of combat, but also easier to understand in general. In this regard, Pathfinder is not the simplest system, especially compared to modern computer role-playing games, where a turn usually consists of two simple actions – movement and attack, where the attack can be replaced with additional movement.
There are at least three important types of actions in Pathfinder – Standard, Move, and Swift. And to make it even more confusing, Move can be used not only for movement, but also for other actions and even spells. In RTwP mode all these details are somewhat hidden from the player, although knowing your way around them is required to play at high difficulty levels. But in turn-based mode they are key, and players who aren't very familiar with the system might be surprised to find that this or that action is impossible depending on seemingly irrelevant circumstances.
A prediction panel with action breakdown. Sometimes an action as a whole is not spent yet, but it’s already impossible to do certain things as part of it (for example, after a 5-foot step you can't spend Move or Standard to move, but you can use them for other purposes). In such cases we use icons to show options that are still available.
We decided to try and makes players' lives a little easier in this regard and came up with a Prediction panel. This is a new panel that appears at the bottom of the screen only in turn-based mode, which shows what will happen if you give an order to the current character. At first glance, this is a rather trivial interface element many other games have. But we had to work really hard to make it show something useful.
Of course, the key problem was the fact that the game was not initially designed for a turn-based mode. The actions the characters perform were split into parts non-transparently for the external code. For example, there are no separate "go" and "hit" actions – instead, there is a "hit" command that means a character will move to the target until they reach it and are able to strike a blow. Moreover, some actions can give rise to other actions. Two things were particularly painful in this regard: touch spells and the Kineticist class.
The bad thing about touch spells (where a character must touch the target to use a spell) is the fact that their implementation can be either incorrect or inconvenient. If we read the rules of Pathfinder, first the character casts a spell, "holds the charge," and then can walk around for a year if they please and do other things until they touch the target. This being said, in the same round that they cast a spell, the character can try to touch the target as a Free Action, but in the subsequent rounds they'll have to make a standard attack and spend a Standard Action. At first glance, everything is pretty simple, but there is a nuance: in all the other computer games the most commonly used touch spell – healing – works differently: you select a target, approach it, heal it. If we implemented touch spells the way they are described in the rulebook, that is, first the spell is cast without a target, then we have to select it, the absolute majority of players would not understand it.
aethal will cast an Inflict Light Wounds spell as a Standard Action, move to the target as a Move Action, and try to touch it as a Free Action. Pathfinder movement economics, ahem, at work!
As a result, in RTwP mode touch spells try to pretend they aren't different from all the others. The player chooses a spell, then a target, and something immediately starts to happen. Namely: the player starts to move towards the target, at a certain range they cast the spell, and then keep moving with a charge in their hand. If during this time the target disappeared (died, for example), we can select a new target, using the spells icon, appearing in the Action Bar (not the greatest solution, as it turns out, since no one ever notices it, and the players feel the spell was just wasted).
We couldn't completely change the way such spells work in turn-based mode, that's why we had to adapt and teach the Prediction Panel to consider all the peculiar features of this type of spell. However, we did introduce one change: in turn-based mode the character using a touch spell casts the spell first without moving, and only moves afterwards, if necessary.
The Kineticist class problem is both simpler and trickier. It's simpler to describe. The problem with Kineticists is that they are the only class that can do something for more than 1 round. The Gather Power skill, decreasing the cost of other skills of the kineticist, may take one, two, or three actions, and the entire use of a skill may take up to two complete rounds.
Again, here we had to deviate from the official rules of Pathfinder for the sake of familiarity for computer RPG players. Actually, Gather Power is not in any way connected to the used skill. First the player announces they are going to gather power, and only later, when this process is over (possibly during the next round), can they use whatever skill for which this power was gathered. Unfortunately, in an RTwP fight it would be totally inconvenient: the players would constantly forget that their Kineticist started gathering power. As a result, we've come up with a solution: the player specifies from the start what they are going to use the gathered power for. Moreover, the game calculates how many units of power is required, and the player just sets the maximum (that is, if you allow 3 units of power to be gathered, and only 1 is required for the skill, only 1 will be gathered, and one action, not three will be spent).
The Kineticist will gather power as a Move Action, and then cast Electric Blast as a Standard Action.
In turn-based combat we couldn't change this approach within a reasonable time frame. We don't love the current result, and we'll try to improve it in Pathfinder: Wrath of the Righteous. The player is still able to set the power gathering maximum, select the skill they want to use, and only after this will the gathering of power commence. That said, if power gathering takes more than 1 action (that is, the skill will have to be used during the next round), it will not be applied automatically, since the situation could have changed completely (for example, the target could have disappeared). This is a little counter-intuitive and inconvenient, but unfortunately we are working within the limitations of RTwP mode.
Smart cursor
Another important problem for us involved the variety of actions a character can perform in their round, apart from using skills and spells. Let's run through them quickly. A character can:
● Make a full attack, spending a Full-Round Action (Move+Standard)
● Make a standard attack
● Make a touch attack, if there is a "charged" touch spell in their hand
In addition, they can choose the movement method:
● A 5-foot step, when Attacks of Opportunity are ignored, but after which they can't move anymore
● Regular movement
Moreover, during testing we found out that very often players want to spend exactly a Move Action on movement, with no risk of tapping into Standard. This is why we divided regular movements into two types: "one-action" and "two-action."
We had to give the player an opportunity to freely combine these action options and movement options, considering availability (for example, the character might not have a Full Attack, or they have spent one action on movement in this round). This was a particularly tough problem on consoles: we couldn't just make a couple of switches that the player could use to adjust the character's actions, there just aren’t enough buttons on the gamepad.
Smart cursor will show, how many attacks the character is going to make
We solved this problem by making a "smart cursor." When the cursor hovers over a target, the game will choose the optimal method of action for the current state of the character (for example, a 5-foot step + Full Attack, if this is possible). What’s more, with a single button we can sort through other available combinations, if your tactics suddenly require an action that is not the most optimal at first glance (for example, provoking an Attack of Opportunity using regular movement instead of a 5-foot step).
Initiative tracker
A compact initiative tracker from the fan-made mod was quite good, but it had a few drawbacks. First of all, it could only show a fixed number of characters. If there were more participants in combat, there was no way to see those who didn't make the displayed set. Second of all, it didn't show the health of combat participants and the effects of spells currently acting on them. And finally, it just didn't work very well with our user interface style.
So we made a decision to rewrite it completely. In addition, so it would fit the screen layout when using a gamepad, we made two versions of it – vertical, in the left part of the screen (for gamepad), and horizontal, at the top (for the mouse and keyboard). Moreover, we added character portraits to the tracker for easier navigation, as well as health and status effects, and we also made the list scrollable to see all the combat participants. What’s more, when the cursor hovers over a character on the battlefield, they are highlighted in the tracker for convenience.
The tracker design for gamepad caused controversy, but after a few discussions we agreed on the current option, where the character whose turn it is right now is shown at the very bottom. We did it like this because all the important information and fight controls are located in the lower part of the screen. Besides, a large portrait of a character at the top looked a little heavy.
Mods
Unfortunately, adding an official turn-based mode to the game completely breaks the mod created by Hsinyu Chan – it won't work with this version of the game. The same is true for modifications that change battle elements – they are not guaranteed to work in turn-based combat, and the Prediction Panel might incorrectly register changes made by them.
A cowboy’s work is never done
In general, we are happy with the results of our work, but, of course, we'll keep improving the turn-based mode according to your feedback and our concerns. First of all, we'll address some counter-intuitive controls, as well as the internal structure of the Prediction Panel, which turned out very complex and error-prone.
We hope that you'll like the fruit of our labors. If you were reluctant to play our game because of the RTwP combat, now you have no more reasons to be. If you thought it was too complicated – try playing it in turn-based mode, fights will be much more understandable and manageable. Or just visit the Stolen Lands another time for new experience – I personally am finally going to play the second DLC.
Maxim Savenkov, Owlcat Games developer.
