7thSage here again, welcome back to part 3 of the Godot Tactics tutorial. Sorry about the long delay. Life has been fairly hectic lately.
Hey, its me 7thSage again, welcome back to part 2 of the Godot Tactics series. This week we’ll be dipping our toes into the first bit of Gdscript for the project. We’ll create everything we need to build our tiles and generate a board or two.
It is my privilege to welcome my first contributor to the website, William Allen aka 7thSage!
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.