Tuesday, March 22, 2011

"The unexamined life is not worth living."

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.


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:


(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:


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!

Tuesday, February 8, 2011

Alpha Units Complete

The art for the three prototype units for Alpha phase is complete!

This simply couldn't have been done without Mike V's dedication and hard work.

The focus of Alpha is stability and gameplay, so I wanted to keep the unit concepts fairly simple by following a generic triad of "knight, mage, dragon". Despite this, I think we were successful in putting a unique spin on those traditional themes.

Art assets can always be added and tweaked, but the core functionality of the game needs to be solid before putting a lot of time and effort into the 'icing'.

For Alpha, each unit type will have at least two class-specific abilities, each of which will interplay with other abilities in a unique fashion.

In addition, each unit type will have several Synergies that will affect ally or enemy units in various ways.

I'll be writing more about those features in some upcoming posts. Stay tuned!

Friday, December 17, 2010


BioWare has posted a video about the combat mechanics in Dragon Age 2:

Dragon Age 2 Combat

It got me to thinking about some things I'd personally like to see in a tactical RPG combat system. In particular, when Mike Laidlaw, the lead designer, started mentioning terms like "tank" it really left me thinking about where the genre can go from here.

I've enjoyed several MMOs over the years, but for me, the now-stereotypical roles of tank, healer, DPS, etc have grown stale. They always felt a little contrived and never made much sense.

In "real life" and other RPGs, you always take out the biggest threat first. The idea that a Tank could say something SO offensive that I would attack them rather than the more deadly magic user in the back row never jived with me. It was a transparent mechanic that was a little too obvious and broke suspension of disbelief for me.

Anyway, some ideas that I think would make for an interesting gaming experience:

Terrain and Environment being much more of a factor. Positioning yourself in different ways relative to certain terrain features should provide different bonuses. If you stand behind a short wall or a barrel, ranged attacks should have a lower change to hit or do less damage. Likewise, if you're on top of a hill, that terrain feature should have a radius associated with it indicating that ranged attacks should have a greater range and be more accurate.

Positional Importance should play a more integral role. In almost all martial arts, being aware of (and controlling) range is vital. Different restrictions and bonuses should apply based on distance from your opponent and position relative to them.

Some real life combat range examples for armed and unarmed combat according to Bruce Lee's Jeet Kune Do and the Filipino martial arts of Eskrima are described in the following links:

Jeet Kune Do Ranges

Eskrima Ranges

I'd love to see a combat system with different 'scales' available for a character to 'zoom' between by using combat maneuvers, akin to 4x strategy game such as Sins Of A Solar Empire

Auto-attack would go away entirely. Even mundane moves like a 'slice' would have to be used with care and at the right time and from the correct distance.

A battle between a character who prefers to grapple vs a sword-wielding opponent might then revolve around the grappler attempting different maneuvers to execute a takedown or to otherwise close the distance. If successful, the weapon-user would be forced to drop his sword and either grapple, attempt to unclinch/disengage, or pull a side-arm such as a dagger. From the sword-user's perspective, he would enjoy a huge advantage as long as he could keep the grappler at a distance and avoid being backed into corners or herded into obstructions.

Just some random ideas that popped into my head. I hope someday I have more time to prototype them out.

Wednesday, December 1, 2010

Alpha Incoming!

Things have been going quite smoothly with development! We're planning to be ready for an Alpha release by the New Year.

Once again conceptart.org came through. Our post for a background artist received THIRTY responses over the course of a couple weeks, with 25 coming in only two days.

I felt bad having to turn away so many talented artists, but we only had a single opening!

To narrow the field, we asked for a sample of work. It was a very efficient method, but in retrospect I now see that it also comes off as a bit sketchy. As was pointed out to us, some less scrupulous studios use this tactic to get free concept art and ideas...in the future we'll have to come up with a better way to sort through applicants.

In either case, we're now two Mikes strong! I'd like to welcome Mike Phillips (http://www.mikephillips.ca)to the team. As you can see from his portfolio, he's extremely talented and we're eager to see what he comes up with for the first battleground.

Work on the "knight" unit type (the last of the three units planned for Alpha), should be completed shortly. He's been the most difficult of the three so far, but we're almost there! A few more refinements and Mike V. (http://sites.google.com/site/michaelvportfolio) will be able to get started on the animations. Mike has done a simply FANTASTIC job with bringing the mage and dragon units to life.

  • Timed Mod Events - Synergies can now add Mods to units that will trigger effects at intervals. This will allow for some very interesting gameplay dynamics. Currently we're planning for the knight to have a Synergy called Lifefont, which periodically heals allies of a small amount of damage. Since mods can stack, a trio of these guys will be very hard to take down!
  • Smart Unit Updates - Only the state changes since the last update are sent to the players now. This should cut down dramatically on the bandwidth used to keep the players up to date. Right now we're seeing updates consume ~40-60kB per game, which isn't too bad at all.

  • Added audio support to the Resource Manager - HTML5 has a weird quirk where HTMLAudioElements cannot be played multiple times simultaneously. My solution was to maintain a list of them instead, dynamically allocating new ones for each sound effect if all existing instances of a sound are already playing. This was especially necessary for the mage character since at high levels his Fireflail ability can generate quite a few fireballs
  • Implemented a flexible particle system and integrated it as a new SceneNode type. It has support for arbitrary Particle class implementations as well as Effectors. Currently I've implemented Wind, Gravity, and Gravity Wells. Chrome is so ridiculously fast that my meager dual-core rig can handle ~500 particles at once in addition to all the other graphics. Not bad for not having a GPU at your disposal!

Tuesday, October 19, 2010


Currently in development, Warlore is the flag-ship game of 1d20 Interactive. It is a web-based real-time tactical strategy game utilizing the latest HTML5 and web-based technologies including WebSockets and Canvas.

In Warlore, players will recruit units, organize combat squads, and lead their warriors into battle under the banner of their favorite general.

Every action your units take will contribute to your general's leadership expertise. Likewise, your general's prowess will bolster your units and allow them to reach their maximum potential. Over time, the types of units your generals lead and the actions they perform in battle will determine what kind of leader they become.

Along with unique and powerful abilities, each unit type has synergistic qualities that will help or hinder other unit types, allies, and enemies. Discovering these interactions and choosing the correct mix of units will be critical to the player's success.

Monday, October 18, 2010