Unison Skills Scripting Session: Gathering Requirements

This is a series of tutorials focused on how to write a script using some sort of process. Some software engineers call these processes “Software Development Life Cycles“.

Regardless of the process you use, these are typically the phases that you would go through

1. Gather the Requirements
2. Design a Solution
3. Implement the Solution

In this tutorial, we will be looking at the requirements gathering step.

We will assume there is an imaginary client that is looking for a script that will add “unison skills” to their game.

Gathering the Requirements

Before you can begin to design a solution it is important to understand what we’re trying to accomplish.

We want to accomplish something called “unison skills”, so we would need to first figure out what that is so that we are all on the same page. This is especially important if you’re writing scripts for someone else: your idea of unison skills may differ from theirs depending on how you interpret it, your experiences (in games, for example), and so on. You don’t want to just go ahead and write something, only to realize that’s not what they want.

Here is a description that you might get:

When two or more battlers use a particular set of skills together, instead of executing the skills they selected, they will both perform a new skill.

That’s a start.

Asking More Questions

The description above sounds ok, but for me it’s not enough to write the script. You need to ask more questions to clarify issues that will likely come up.

There is no harm in asking for more clarification. If your client refuses to answer questions, then I would not even bother doing work for them because chances are when the script is delivered, they’ll point out that certain things aren’t “what they want” and then refuse to compensate you for your time and efforts.

Here are some questions based on the description and other thoughts:

1. What does it mean to use skills “together”?
2. When they “both” perform the new skill, how are damage calculations and other factors considered?
3. When is the skill performed? If one actor is really fast and the other is really slow, does it make a difference? Would the faster person be held back because the other person is too slow to get ready?
4. What about skill consumption? If one actor’s skill requires 10 MP and the other requires 20 MP, and the new skill requires 50 MP, how much MP does it cost for each actor?
5. What happens if one of them is paralyzed before the unison skill is executed? Can they still perform it?
6. What are the rules for targeting? If one actor targets A and another actor targets B, is it still executed?
7. How do they actually choose the unison skill?

These are questions that come up to me based on my experience with game development. Some of these questions may or may not have come up for you. You may very well have more questions in mind because you are aware of something that I haven’t thought of yet.

Either way if you have questions or concerns, raise them.

Getting More Answers

Hopefully you will be able to get some good answers for those questions.  Because this is a tutorial, I have full control over how our imaginary client will respond to questions, so let’s come up with some answers:

1. For now, we will assume the default battle system. Two skills are said to be used together when they will be executed on the same turn.

2. Design your solution based on options.

One option would be to just pick the strong or weakest battler (maybe a weighted average?) as the basis for calculations. However, this only takes care of damage formulas, and some devs might want to consider other properties such as element or effects.

Thus, another option is to consider each battler individually. Some actors might have weapons that cause poison. Other actors might be weak. If our skill allows a poison weapon to actually inflict a poison state, we want to include this. What this means is

• The sum of the damage is equal to the sum of each actor’s damage, based on the damage formula
• “Normal” attack element will consider each actor’s own attack element
• “Normal” state effect will consider each actor’s attack states

3. This can be provided as options as well.  For now we’ll say that the unison skill is only executed when all actors are “ready”. So whenever the slowest person’s turn comes around, that’s when it will occur.

4. There are different ways to handle this, so provide them as options to the dev:

• Deduct consumption based on battler’s original skill (original)
• Deduct consumption based on unison skill (unison)
• Deduct unison skill consumption in addition to the original skill consumption (both)

5. There are a few options available, including

• Battlers must be able to execute the unison skill. If the skill requires all of them to wield swords, then they better all have swords.
• Battlers must be able to execute their own skills. If one battler used a wand skill and another battler used a sword skill, and wands were suddenly sealed so that the wand skill cannot be used, then the unison skill cannot be executed because that battler is unable to perform their skill.

6. Some options for targeting rules include

• All battlers must target the same target.
• Target doesn’t matter. As long as they use the same skill

7. Unison skills do not necessarily require the player to figure out that using a specific set of skills in a specific way will result in a different skill. This can be one of the mechanics, but it can also be done so that the unison skill is treated just like any other skill: player will select it from the menu, and perhaps choose which battlers will be part of it.

For now, we will assume that the player just has to figure out which skills to use. The solution should be designed so that other ways of selecting unison skills can be implemented easily.

Ready to Design a Solution

At this point, if you are satisfied with the requirements, you should have more information available to design a solution. We will look at this in the next tutorial.

Naturally, you may come up with more questions while you’re coming up with a solution or while you’re implementing the solution itself.  You should simply go back and ask for more clarification.

Note that the requirements I’ve provided are much more general than what a  game would usually require. My intention is to be able to re-use the script in multiple projects with different sets of requirements.

Summary

Gathering requirements is an important step. Ask questions, get answers, and ask more questions if you need to. You should get as much information about what the client wants before designing, implementing, or delivering the solution.

Spread the Word

If you liked the post and feel that others could benefit from it, consider tweeting it or sharing it on whichever social media channels that you use. You can also follow @HimeWorks on Twitter or like my Facebook page to get the latest updates or suggest topics that you would like to read about. I also create videos showcasing various RPG Maker techniques on my Youtube channel.