Dragon Quest Battle System - Part IV (Final)
This is the final part of the Dragon Quest Battle System tutorial.
On this entry, we’ll be tackling the spell and item menu. Then, we’ll add the hit and spell effects. Finally, sounds and music will be the icing on the cake.
If you haven’t checked out the other posts before, please have a look here: Part1 — Part2 — Part3
Spell Menu
With the command window set-up, I decided I would have the first three spells working: Heal, Hurt, and Sleep.
As you can see, it’s pretty much like the CommandAttack. It inherits from it. Since both the spell and attack command deal damage, it made sense to structure it this way. The spell is like a specialized form of attack. One of the differences is that we have to check the user’s MP before trying to execute it. Also, the damage formula is different since it takes into account the resistance to the spell type.
Now, you might wonder, wait a minute, the heal spell doesn’t deal any damage at all. That’s right, but we can deal negative damage when we want to heal. The process is the same. The main difference from heal to a damaging spell is the spell’s target. In the case of DQI, you’ll heal yourself. This is a neat way to use the same code to do different things. You can also see that it would be easy to target another character.
Now, another main difference is that the spells are in a sub-menu. The spells itself works like choosing the attack command, but to get there we need to have our sub-menu.
The CommandMenu is another command that the character can have. In the original DQI when you don’t have a spell and select the sub-menu a message displays. This class holds that message in case we need it, and also aggregates the spells itself.
We also need another phase to pick a sub-command. The spell window works like the base command window. It actually uses the same class, but it points to different data.
Sleep Spell
The sleep spell needed a bit more code for it to work. First, we need to take into account the status effect. We now have to consider the characters to be able to receive a condition (eg. sleep, dead, silenced).
The condition class is used by the character class to handle status effects. It allows us to add a status effect to the character and to check the situation of it.
The status effect handles the effect itself. It will track the number of turns it has passed with the effect and it stores two messages for us. One for when the effect is on another when the character gets rid of it. As you can see I’ve left up a comment there. If we wanted to make a healing item or anything else, it would be pretty direct as well.
The way it’s set up it’s easy for us to expand it an allow for more than one effect to take place. You can have a buff on while being poisoned and so on. It took a while but I was happy with how everything turned out.
Item Menu
Once we have the spell sub-command set up, the item one is pretty straightforward. Items work pretty much like a spell in a general sense. They have different parameters in this case.
As you can see, we’ll pass along what type of usage this particular item has. In DQI you start with a “Torch” item that can only be used when inside dungeons. So in this case we’ll set the UsageType to FieldOnly. When we try it in battle a message will popup.
Hit and Spell Effects
To handle the hit effects on the enemies let’s take a look at the BattleCharacter class.
As you can see it’s pretty simple. In our case we want the slime to blink when it’s hit. So once it does get hit with a command we’ll call the TakeHit function. The function will start a coroutine that will toggle the visibility of the sprite for a short period of time.
For the spells, we’ll make a grayscale effect. It shifts the color from the regular one to it’s grayscale. So like toggling the sprite effect but with the color. Unity offers a script to do grayscale on your camera on their standard assets package.
Like with the screen shake effect, we add a parameter to signal the grayscale effect. We then call it in case it’s set.
Sound and Music
Since I already have a class that handles all the audio this section was more brute work. The basic idea is that I have two controllers, one of music and another for sound effects. One manager will load up the audio files and set them to each controller. We then have a variable pointed to it for ease of use.
We then fire the music when the game starts and when each of the attacks happens. I also had to add to the command class a variable that mentioned what audio to play. The battle character as you can see already has that. So when the enemy takes a hit, it will have an audio set to it already. This way it will be synchronized, the hit effect with the audio being played.
Final Thoughts
Thanks for following the process up to the end. I hope you enjoyed it.
If you haven’t seen the other posts you can check them here:
Part1 — Part2 — Part3
Originally published at https://www.tumblr.com on December 15, 2016.
