Home > Behind the Scenes, Vacant Sky Awakening > Behind the Scenes: Conceptual Composition for Fun and Profit

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:

*Name
*Damage
*Element
*MP cost
*Status effect

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!

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: