Behind the Scenes: Conceptual Composition for Fun and Profit
Time for another behind the scenes look at the technical aspect of Vacant Sky Awakening. This one is a little more high-level and touches on game design, so the non-technically-savvy readers don’t have to worry about their eyes glazing over.
Lately, I’ve been putting the finishing touches on the skill editor. One of the challenges of making a skill editor before all the content is set in stone is that it can be hard to predict exactly what tools to lend the user.
Let me give an example. In more typical RPGs, a skill could have the following attributes:
There tends to be a linear progression in skill power in these games, in which the skills you learn are just more powerful versions of ones you’ve learned previously, dealing higher damage and costing more MP. Though certainly easier to design and program, that’s also kind of boring.
In Vacant Sky Awakening, a much greater emphasis is placed on support skills, most of which produce unique effects that can’t simply be qualified as status effects (such as granting an extra turn). On top of that, skills can have lots of conditions, such as burning an amount of TP, or requiring you to have at least a certain amount of HP.
Although I could certainly put a checkbox for every single possible quality a skill could have, I decided to disassemble skills into constituent pieces called components. Skill components are the building blocks of skills – any skill can be expressed as a set of components.
Examples of components include:
* Inflict damage
* Can’t miss
* Apply status effect
* Costs TP
* Requires TP
* One use per battle
When I want to create a new attribute for a skill, all I need to do is create a new component for it. To ease this workflow, I’ve created a C# attribute I can stick on a class declaration that causes the editor to read it and create a button for it. Similarly, each field in that class is marked with an attribute that specifies its name and what kind of input widget to create for it.
This approach is very flexible and resilient to change, an absolute must when working on an episodic title where new mechanics can be added in the future that I have no way of predicting right now. It’s also very generalizable; I could apply the same concept to items (in fact, I probably will) just as well.
Thanks for reading this through to the end. I hope it was interesting!