It’s been almost a year since the last post, but I finally have a reason to revisit this project. Brennan Anderson wrote some amazing music after following along with the Tactics RPG project and was generous enough to share it with the rest of us. Thanks to him, we will go ahead and add a follow-up post that describes working with music.
In A.I. Part 1, we added autonomous agents. Our enemy units could randomly move around the board and pick and use abilities with random targets. Now it is time to make them move and aim with a purpose. We need our enemies to be smart enough to hit multiple targets, attack from the best angles, and avoid friendly fire, etc. They should always act intelligently from the options which are available.
I’ve decided to split the A.I. implementation into two parts. This first part will cover the “what” as in “what ability do I want to use?”. This is the easier of the two problems. The next portion on “how” as in “how do I know where to move and aim to best use the ability?” is rather complex. Since this bit is easier, I will also include the code that ties the A.I. into the battle states, as well as adding another user interface view which shows the name of the ability that a computer controlled unit has chosen to use.
I’m currently hard at work preparing A.I. for this project. I was hoping to have it ready to share today – it works, but I am still polishing the code and working on writing the accompanying tutorial. While you wait, I decided I could share the decision making process I followed while architecting this portion of the project to help whet your appetite.
Now that we have enemies, we can also provide an actual “goal” for the battle. First we must be able to actually defeat the enemies, as well as risk defeat for our own units. There needs to be a consequence for a unit’s hit points dropping to zero, so we will add a “Knock Out” status effect which disables a unit from acting or taking additional turns. Likewise there should be an effect for defeating all enemy units, or allowing all hero units to perish. These are sample “victory conditions” which we will track, and which will allow the battle to end. Continue reading
It’s well past time to add some enemies to the board, but by now we’ve made all sorts of modifications to the “Hero” prefab which haven’t been propogated to the “Monster” prefab. We could spend time manually setting up each new character to have the same kind of structure, but I really don’t want to. Instead, we will use this lesson to lay the groundwork on a more flexible system. We will be making a factory to create and configure new units for us, so that introducing new and unique characters in the future will be a much simpler process.
We have enough components to make several abilities, and in this lesson will make a few more. Magic based abilities are often the most powerful in an RPG, so they need a way to be regulated. If players could use them freely the game would end up both boring and monotonous. There should be a reason for players to use different abilities at different times. In order to foster this kind of strategy, this lesson covers the use of magic and magic points.
Over the past several lessons we have implemented tempory implementations for the effect of an ability, such as manually implementing an attack damage estimation and application of the damage itself. In this lesson we will be providing a much more complete implementation which allows for very different effects ranging from applying damage to inflicting status ailments and which supports just about anything you would want to do.
There is still plenty to do before we have actually implemented a true “attack” ability. In this lesson we will determine what sort of chance there is that the unit will actually hit the target. Sometimes special status effects or abilities might alter the chances of hitting, but at a minimum we will take the angle of attack (front, side or back) into account. It is easier to hit an opponent if they don’t see the attack coming. In addition we will add another UI panel to indicate this new hit rate.
During our last lesson I suggested possible implementations for a few status effects, such as Haste, Slow and Stop. In this lesson we will actually add them. We will also learn how to manage the way multiple conditions might be keeping a status active. For some variation we will also add a Poison status effect and see how it can be tied to an item as an equip feature – a cursed sword.