Tuesday, March 22, 2011

"The unexamined life is not worth living."
-Socrates


As an avid gamer of over 20 years, and having been involved with game development for just over five, I'm continually amazed by the mutual exchange of wisdom that exists between so-called "real life" and gaming.

I chose to quote Socrates because in a sense, games and gaming are my life. As an aspiring developer, in order to live an examined life, I must also examine games themselves in a critical manner.

In designing the ability system for Warlore, I decided to step back and really think about how and why most roleplaying games handle their skill systems.

Historical Mechanics and Anachronisms

I've come to the conclusion that the reason so many games handle skill mechanics in such a similar manner is because that's the way it's always been done. The reasons why they were originally done that way are sometimes not due to them being "good" or "right" ways (if such a thing can exist), but rather they are the result of legacy technical limitations.

In some ways, game design is often approached in a similar manner to cultural, religious, and political beliefs. Too often we blindly and unquestioningly repeat ingrained behaviors and profess beliefs without examining where, when, and why they originated.

When approaching game design, I feel it's important to:

a) Examine things which we take for granted.

If we come out on the other side of the process still holding those beliefs, that's fine, but at least then we can be sure that the principles we're basing design decisions on have held up to scrutiny.

b) Regularly re-examine already examined beliefs.

History and time have a way of passing us by without us realizing it. Unless we occasionally re-evaluate our approach to design, we risk missing out on opportunities that new technology and innovations may have made possible.

"Real Life" and Learning

In real life, the process of learning is a continuous, gradual process that is punctuated by periods of accelerated progress which are followed by plateaus during which less progress is made. It's a type of calculus versus a sampled or iterative system. In real life, you don't suddenly "level up" after performing a task exactly 10 times and subsequently become a certain percentage better until you've done the task another 20 times.

Sampling and iterating are techniques of simplification used to generate approximations which are "good enough." We use them when faced with constraints such as limited processing power or memory, time constraints, or usability issues.

The First Final Fantasy

Like most 80's RPGs, the magic system of Final Fantasy 1 was necessarily influenced by the technical limitations of the 8-bit era. There's a reason why you were limited to 4-character long names, and there's a reason why the ability system was constructed the way it was: memory was limited and expensive back then.

In another sense, the design itself was simply just primitive. It was one of the first console-based RPGs and as such there was a lot of uncharted water that people were still exploring.

One of the fundamental design concepts to recognize here is scarcity. Like Dragon Warrior, part of the difficulty of the game was based upon having a finite amount of resources available. While Dragon Warrior used a single pool of MP that was used to fuel every spell, Final Fantasy innovated by having separate MP pools for spells of differing power and making each spell cost 1 MP.

Also of note is the relationship between the magic system, the progress curve, and the economy of the game. As your characters level up, they acquire more points at each spell level, but unlike Dragon Warrior, they do not automatically learn a specific ability at a specific level. It's up to the player to decide which, if any, new spells to learn. Unfortunately for the player, the only way to acquire new spells is to purchase them.

These dynamics led to one of the most often emulated game design decisions of the role-playing genre: multiple versions of the same ability.


Prototypical FF spell progression of Fire -> Fira -> Firaga
Image courtesy Team Jakriss

The cost-benefit curve

Alternatively known in various games and genres as risk vs reward, the power curve, or mana-power ratio, the cost-benefit curve is one of the most fundamental elements of game design

For a game system to be balanced, there must always be some reasonable trade-off that is made. Whenever a desirable effect is generated, a finite resource such as MP must be used up in exchange for producing that effect. If an ability can produce an effect that is not proportional to the amount of resources consumed relative to the scarcity of that resource and relative to other abilities, that ability will be considered imbalanced by players.

This is integrally tied to the concept of suspension of disbelief. In the most extreme example, an ability capable of instantly defeating any foe breaks the immersion of the game world. Such a capability turns the player into an administrator, tester, or moderator rather than a participant in a fantasy world.


This may be why the designers of FF1 chose to create multiple versions of the same ability. The time and effort necessary to conceive new effects + the memory necessary for the code to implement those effects + the technical limitations of the NES + the need to implement a power curve made it necessary to sample a curve by breaking it into several distinct parts.

The limited UI capabilities of the NES, along with its simplistic controller also limited the options available for players to execute the available abilities.

As a designer, I have to step back and wonder about what possibilities my own projects would be missing out on were I to simply follow this existing model blindly. Now that I have an idea about why legacy systems were designed this way, I try to think about why my systems shouldn't be.

Two reasons that immediately come to mind:
a) Technology has progressed. Those limitations of the past no longer exist. What does that mean?
b) Internal consistency of the game world

When I say internal consistency, I mean that the world you're creating might not adhere to real-world physics or rules, but it does need to conform to its own rules. The degree to which the lore of your game corresponds to the real world will determine the degree to which your game systems must also correspond to it, technology permitting.

Why is it that at level 20 in World of Warcraft a Shaman suddenly becomes capable of doing 10% more damage with a particular spell for a fixed mana cost increase of 5%? As we've discussed, that's not how we learn in real life. Each time we practice an action, we get better at it by a certain (but varying) amount in a continuous and gradual manner.

One question is: does there exist some element of lore in World of Warcraft that justifies that system?

Is there really a spell that creates only a small fireball, and one that creates only a medium one, and then a still larger one? What differences in the spell words or patterns or rituals exist in this universe and does it really make sense that a spell caster wouldn't be able to figure out those differences for themselves without having to pay someone to show them?

The next question is: Does there exist a technical limitation that mandates this system?

There are any number of justifications that could have gone into the design of the spell system. For example, the need to throttle player progress or the need to limit economic inflation.

But for you and your game, if the answer to both of those questions is "no" then there's no reason not to experiment with other possible systems.

[Edit: It's interesting to see that in Cataclysm, the WoW developers have gone to a system where abilities automatically scale in power upon leveling up!]

How Warlore Does It


In designing the ability and skill systems for Warlore, I wanted to mirror fairly closely the things I had learned about the process of real-life learning. Some key concepts that I wanted to make sure to capture were:

1) Hierarchies of Knowledge

The strength and scope of each ability's effects are based upon multiple skills that are often related in a hierarchy.

2) Continuous and Gradual Progress

Each time you use an ability, you gain experience in several skills that affect its performance, including a skill specifically associated with that ability and that ability alone. The benefit of that learning is available immediately.

3) Persistence and Sharing of Knowledge

Each use of an ability also conveys knowledge in those skills to the General in charge of the unit that used the ability. Even if that unit dies, the knowledge gleaned by the General will persist. For example, when one unit becomes more proficient at Fire Magic, all other units that use Fire Magic become better when serving under the same General.

4) Practice Makes Perfect
As mentioned above, every single use of a skill grants experience that is capable of producing results.

5) Innovation
As units improve their skill levels, their abilities will develop new functionality or expand on existing functionality.

6) There's More Than One Way to Skin a Cat
Different methods and criteria exist for unlocking the same thing.

Wait...unlocking?? Didn't I just say that arbitrary progression was bad? Yes and no. What I've been trying to get at is that your game systems, whatever they are, need to be selected and developed for a reason. They have to be justifiable. Just because we're cleaning house, there's no reason to throw the baby out with the bathwater.

In my opinion, unlockables are very compelling and make a great addition to the game. They help give players sub-goals to work towards, which maintains interest in the game.

One other goal I had for the ability system design was robustness. I feel that too often the underlying mechanics of game systems are not hidden away well enough and are not sufficiently fleshed out. You can practically see the cold, hard, unfeeling number crunching happening behind these scenes. It's too obvious that "ability X" is just a mechanism for adjusting one number in exchange for decrementing another.

In Warlore, since there is only ever a single version of each ability, each ability must stand on its own merit and grow gracefully. Since you'll be using the same "Fireball" at level 1 as you are at level 100, "Fireball" needs to grow with you. To make Warlore compelling, the player must always be forced with a decision between using one ability over another. For that reason, each ability has to have some unique set of features or capabilities that distinguish it from other abilities and which allow it to fill a strategic niche.

Well, this post has gotten MUCH larger than I had envisioned. In the future, I hope to expand on some of the ideas presented but I hope this insight into the design of Warlore's ability system has given you some ideas for your own games.

Particlemaker

I’m happy to announce the public release of Particlemaker, our internal particle system creation tool.

I’d been itching to play around with Google App Engine and I thought it would be cool to let others play around with Particlemaker's capabilities. The result is a persistent storage layer to manage importing and exporting of effect systems.

You can check it out here:

http://alpha.1d20interactive.com/particlemaker

(Google Chrome v10 or higher is required)

I was pleasantly surprised at the low learning curve of App Engine and the slick SDK that Google provides. Getting something up and running was intuitive and incredibly easy.


For now you’re limited to some stock images for use as particles, but in the future I hope to allow users to upload their own images. That will have to wait for a rating and flagging system, though, to help deal with griefers.


In addition to playing around with Particlemaker, if you’re interested in helping alpha test, we’re still looking for testers for the game proper. You can log in to the alpha environment here:

http://alpha.1d20interactive.com/main


You’re welcome to play around at any time, however it will be most helpful to participate during the scheduled server load and stability jams, every Saturday at 1PM EST.



See you in game!