Weekly Report (July 14th)

Konnichiwa!

And it's done, the combat is finally no longer a random-number-generator-fest. I mean, it still is, because action picking is still largely based on whether the roll was successful or not, but at least now the selection is governed by a certain set of rules. The system is in no way perfect, but it's a massive improvement over the complete lack of one and a huge step in the right direction.

So, what the decision-making is right now. When an NPC has to take their turn in combat, a process of combat action picking is initiated. The process relies on effects the performing NPC's available combat actions posses rather than the combat actions themselves. I mentioned before that I had overhauled the combat actions to have multiple effects, so I take full advantage of that. 

Right now, the algorithm is as follows:

1) If available combat actions have a TryEscape effect, and the NPC's party is threatened with imminent defeat (based on current health thresholds), the NPC has a chance of trying to use a combat action with the TryEscape effect, but only once per battle, just like the player;

- if failed to assign and perform a combat action at this stage =>

2) If available combat actions have an AddStat effect, the NPC may try to use a combat action that influences a fellow combatant's stat (for now it's either health or stamina) - basically, if a friendly NPC is badly wounded or tired, there's a chance that the combat action performer will try to use a combat action that replenishes the relevant stat;

- if failed to assign and perform a combat action at this stage =>

3) If available combat actions have a RemovePerk effect, the NPC, granted there are grounds for trying to remove the perk (for example, if a friendly combatant has bleeding, the NPC may try to remove it via a health potion, a healing spell, or the first aid skill), may decide to use a combat action with the relevant RemovePerk effect;

- if failed to assign and perform a combat action at this stage =>

4) If available combat actions have an AddPerk effect, the NPCs may try to use a combat action that adds a perk, either to a friendly combatant (like Defending) or a hostile combatant (like Bleeding or Stunned - those effects are usually added to attack/magic/skill combat actions, so it will look like the NPC simply tried to attack their opponent, when in reality they aimed to add a perk);

- if failed to assign and perform a combat action at this stage =>

5) If no combat action has been assigned at this point, the NPC will try to use a combat action that has an InflictDamage effect, with a rather high possibility;

- if failed to assign and perform a combat action at this stage =>

6) Finally, if even at this point no combat action is assigned for execution, the NPC will try to defend themselves. However, if for some reason the NPC doesn't have any defending combat actions, the function will return null, which will result in passing the turn to the next combatant. Characters shouldn't lack defending combat actions, so it's mostly a failsafe for me forgetting to add at least one such action to the combat action pool.

This is a very basic overview of what is going on when the system is trying to pick a combat action. Naturally, the process is more nuanced, with many checks and great room for improvement. Once more combat effects are added, I will need to program the conditions for them to be picked by NPCs in combat, but it's a given. You can't just add brand new combat moves and expect the game to somehow know when they can or cannot be applied.

I can finally return to working on the demo's storyline. It's been too long. It's been so long, in fact, that I will have to pretty much learn the whole process of scripting anew. Plus, there are some things I noticed just recently and want to take care of. I will get to it after a short break.

See you next week!