News!

Sent this newsletter out today.  If you're not currently getting the newsletter, consider signing up! If you do, you'll get a coupon code good for a nice discount when Defender's Quest is released!

On to ze newsletter:

Hey everyone!

It's been a while since our last newsletter, and we've got lots of exciting news about Defender's Quest! 

Since we released our initial demo, we've gotten lots of great feedback. We've been working furiously ever since to address as many of the issues people raised as possible. Among countless tweaks to gameplay, balance, skills, and other features, we've also given the game a significant graphical overhaul - user interface has been improved throughout the game, and we have a brand new art style for the cutscenes (which was the #1 complaint from the demo). The public demo was updated a while ago to reflect some of the new UI changes, but you won't see the new cutscene art until release.

Here's a sneak peak at some of the new art updates, old on the left, new on the right, click to make big: 

Cutscene Art (click to make big)

Recruiting Interface   (click for big)

Battle Preview Interface   (click for big)

While all this has pushed back the release date a tiny bit, we want to stick as closely to our original goal as possible, and are now aiming for early December. 

Here's the current plan:

*********************
Early December 2011 
Initial release 
$6.99 USD 
*********************

This will be a "beta" release. This will include the full, playable game with all the story, but might have a few bugs and will be lacking some extra bonus features we plan to add later.

The beta release will cost $6.99 USD. Everyone who purchases this release will get free updates and an upgrade to the full version when it comes out. Once the full version comes out, it will cost $9.99 USD.

And, as promised, all newsletter subscribers (that's you!) will get a coupon code that lets you buy the beta release for $4.99 USD! 

****************
Q1 2012 
Final release 
$9.99 USD 
****************

One last thing, if you guys could do us a big favor:

************************
Send us your SAVE FILES!
************************

Go back to the demo - either on our website (if you played the browser version) : http://www.defendersquest.com/play_demo.html

...or just run the executable version you downloaded, and press the "export" button on your game's save slot. This creates a ".dfq" file you can save to your hard drive. Take note of where the file is, and attach it to an email sent to this address:

lars.doucet+tdrpg@gmail.com

Please include "SAVE FILE" in the subject line :)

With all your save files from the wild, I'll be able to do more reliable testing to make sure that save games from the demo will import correctly into the final version of the game. Anyone who sends in a save file for testing will get a nod in the credits, so please supply whatever name you'd like to be thanked as in the email!

Thanks again for all your feeback, encouragement, and most of all PATIENCE, as we head down the final stretch!

Sincerely,

Lars Doucet
Level Up Labs

A Status Effect Stacking Algorithm

(Cross-posted on my Gamasutra blog, which usually gets more comments)

Status effects are a cool way to add strategic depth to both Tower Defense games and RPG's, and since  our upcoming title Defender's Quest is a hybrid of both, it's chock full of 'em, and unlike some RPG's, we took special care to make sure that they're not totally useless.

In Defender's Quest, each of your party members is a placeable "tower" in the battle system, but also a unique and persistent character who levels up and gains skills over the course of the entire game.  Some of these skills cause the defender's attacks to inflict status effects .

Here's a short list of fun things you can do to monsters:

• Poison - X damage / second for Y seconds.
• On Fire - X damage / second for Y seconds, cancelled by ice
• Chilled - creep slowed by X% for Y seconds, cancelled by fire
• Frozen - creep stopped for Y seconds, cancelled by fire
• Stun - creep stopped for Y seconds
• Bleed - creep takes X% extra damage for Y seconds
• Confuse - creep walks backwards for X seconds
• Blind - creep's attacks miss X% of the time for Y seconds
• ...and many more!
  

Ice Mage freezing and slowing creeps

The Problem

As you upgrade these skills, both the potency and the duration of the status effect goes up.  Shortly after implementing this system, I ran into a dilemma - what do I do when two status effects hit the same enemy?  This problem was particularly interesting because it was both a technical and a design problem.

Every status effect has two main variables - potency, and duration.  Potency takes on a different meaning depending on the effect - for example, in poison, "potency" means damage per second (dps); for slow, it represents a speed multiplier.  Duration, however, always means how many seconds the effect lasts for.  So, stacking status effects is all about combining potency and duration in a way that:

1. Is mathematically sound
2. Doesn't look like a glitch
3. Doesn't seem "unfair" 
4. Doesn't lead to weird edge-case exploits

There's several unique cases to consider, and ideally, one algorithm should be able to cover all of them.  Let's go through the cases one by one as I step through my problem-solving methodology and come to a final decision.  

1. Different effect types

This is the easiest case. First, check to see if the new status effect "interacts" with whatever is already applied to the enemy. If there's no interaction, then just apply the second effect - ie, an enemy can be bleeding and poisoned at the same time.  However, if the enemy was on fire, and we just hit them with a chill (slow) spell, then we need to remove the fire first, since one of our rules is that fire/ice spells cancel each other.  If we hit them with a freeze (stop) spell however, we'd cancel the fire, reduce the freeze to chill, and then apply that.  

2. Same effect, identical stats

Let's say an archer with poisoned arrows hits an enemy, and then hits them again, inflicting the same status effect twice at different times.  Let's say the first poison effect (A) is 10 dps for 5 seconds, or (10dps | 5s) for short.  This will deal 50 damage over the life of the effect. One second later, the archer hits the same enemy with an identical poison effect (B), also (10dps | 5s).  In this case, the variables will be the same, so it's pretty easy to combine them, right?

Not quite - the enemy has already been walking for 1 second before the second poisoned shot landed, so (A) is now actually (10dps | 4s).  Even with identical starting stats, duration for any two effects will almost always be different in practice.

In a world where we can expect potencies to remain constant, the natural choice is to add durations together.  Not only is this simple and intuitive to the player, the alternative method of making potency increase while keeping duration constant could make dps effects like poison really difficult to balance.

So, in our above example, we just add another 5 seconds to the poison clock and now our creep is poisoned to the tune of (10dps | 9s).  All is well with the world!

3. Same effect, different stats

This is where it starts getting complicated.  What if two different archers with different poison stats hit the same enemy?  The prior example was easy because potencies matched, but here both numbers are different so simple addition is out the window.

A naive way to "combine" the values is just to average the two effects, but this fails to "conserve" the full power of both. Individually, the first effect will deal 40 damage total, and the second 50, for a total of 90.  Averaging both effects to a single (15 dps | 3.5s) will only yield 52.5 damage, not what we want at all!

So, whatever we do, combining the two needs to result in 90 total damage at the end of the day.  More generally, the PotencyDuration value of the combined effect must equal the sum of the PotencyDuration of each effect taken individually.  This principle, "conservation of PotencyDuration," should work in all cases, no matter what values the status effects have.


Conservation of PotencyDuration

Mathematically, the principle can be stated like this:

PDA + PDB = PDC

where (P: potency, D: duration, A, B: original effects, C: combined effect)

So, the first thing to do is redefine Poison A and Poison B in terms of PD values:

Now, we just have to convert the PD of Poison C back into potency and duration.  There's several approaches we can take here - do we want to match the highest duration of the two effects, or the highest potency, or something else entirely?  All it takes to satisfy equivalence is two values that multiply to make 90, but each approach will have unique subtle effects on gameplay and feedback that we need to consider as well.

1.  Match Highest Duration

We matched the duration of Poison B, the longest-lasting effect, and converted Poison A's PD of 40 into an extra 8 dps. This dilutes Poison A's potency by stretching it out over a longer time.  We're good, right?

Well, maybe not. 

Take a look at this -
here's what the player sees: 

Archer hits a creep

Creep takes 20 damage per second

Second archer hits the same creep

Creep takes 18 damage every second

What????  In the player's eyes, the additional poison shot now causes the creep to take less damage. Sure, everything is still mathematically hunky-dory, and the player isn't really being screwed over - the same total damage will be inflicted, just over a longer time.

However, I'm not sure any of that will be clear - I can easily see players refusing to let two archers have overlapping targets, thinking this is "better" strategically since they've noticed that mixing rangers results in "lower" poison damage.

This is even worse if we were dealing with a slow effect instead of a poison effect.  In this case, mage A casts slow (50% | 2s) on a creep, and then mage B hits the same creep with slow (30% | 10s).

What the player sees is: 

1. One mage slows the enemy down
2. Another mage hits it with a second slow spell
3. The enemy speeds up!

In both cases Potency-Duration is conserved, but the player will be misled because their chief visual feedback is the size of the purple numbers bouncing off of the enemy, or how fast the creep is moving.

2. Match Highest Potency

In this case, we've made the combined effect match the potency of Poison A, the strongest effect, and converted Poison B's PD value into 20 dps for 4.5 seconds.  Instead of diluting Poison A, we're concentrating Poison B, squeezing it into a shorter time-frame so that the potency can match.  With this approach, the player will see no change in the amount of damage happening each turn, but the effect will last for longer thanks to the extra poisoned arrow.  The player will see the same amount of damage bouncing off the poisoned enemy every second, but each extra poisoned hit will keep the effect going a little bit longer.


Final Considerations
Before we conclude things, let's compare our solution to our original goals.

Is it mathematically sound?

Yep! We're conserving Potency-Duration, so everything's good here.

Does it look like a glitch?

Nope! By matching the highest potency, the player won't see enemies speeding up when hit by a slow spell, or poisoned arrows "reducing" poison damage.  Now, if an enemy is hit by a stronger status effect, they will see the enemy either slowing down even more, or taking more poison damage, but this seems like a natural result.

Does it seem unfair?

Generally this approach seems fair. In fact - it might be a gift to the player.  By concentrating weaker effects to match the potency of stronger ones, the player gets more of their effect's strength up-front.  Although the overall damage (in the case of poison) is the same over the effect's life-time, getting it done faster is almost always better in a tower defense game, since killing even one tile earlier can mean the difference between a close call and letting the creep reach the exit.

However, this "gift" to the player varies a bit with the effect.  A bleeding enemy takes more damage when hit.  This effect is more useful the longer it lasts, because there are more opportunities to hit the enemy and score bonus damage.  So, whereas poison becomes more effective with our algorithm, bleed becomes slightly less.  Something like slow isn't really affected - regardless of whether the slow spell is concentrated or stretched out, the enemy will reach the exit at the same time.  Given that the algorithm has a mix of positive, negative, and neutral effects on the various status effects, it seems like a good general approach.  Negatively impacted effects like bleed might need a slight balancing buff to make up the difference.

Does it lead to weird edge-case exploits?

The only exploit I can think of is this: grouping lower-level defenders with a single high-level one, who "primes" the enemy with a high-potency effect, thus allowing all the subsequent defender's effects to match that potency and add time to it.

Honestly, that sounds like a perfectly legit strategy to me, and I don't see it unbalancing the game.
Compared to the alternatives, this approach still seems the best.


Final Thoughts

There's one final approach we briefly considered and dismissed which I want to touch on again - allowing the potency to rise when mixing effects.  I decided against this one for several reasons: first, there's no natural, obvious formula for how much to raise the potency by.  Second, raising potency shortens the lifespan of the effect, which makes for less interesting gameplay.  Third, it's much harder to predict what would happen in game if effects can rise in power just by stacking, so it seems ripe for exploitation / wrecking balance.

I hope you've enjoyed this little exercise.  I found it interesting because it's a good example of a problem where technical and design needs overlap, and I hope it's useful to somebody in their next game.

If you have any ideas of your own, or can think of a better algorithm than the one I laid out here, do share your thoughts in the comments!

Lessons in Demo Launching

EDIT: Hillariously enough, my host's servers just went down. You can still play the demo with these links:
Windows torrent (dropbox)
Linux torrent (dropbox)
Browser demo (mochi)

Cross-posted on gamasutra (which usually gets more comments)

An important phase in marketing any game is launching a playable demo.  We produced two versions - one that plays in a browser, and one that you can download and install for a nice, desktop-native experience with video features like fullscreen/resolution switching, etc.

In preparation for the launch, I spent a week getting the files and website ready for a "soft launch" where I showed it to just enough people to catch all the huge, obvious problems before the "real launch" where I would send out press releases and the like.  Response was mostly positive, and I was able to fix a lot of problems that people pointed out right away.

In today's article, I talk about the process and share some of the things I learned.

Click to play the demo!

Launching the Web Version

Deploying a web version is as easy as writing an <embed> tag, but I wanted to keep my hosting bill low, and also minimize the footprint in case high traffic from the "real launch" should take the site down. There's plenty of "free" swf hosting sites like SwfCabin, but I wanted something sturdier.  Mochiads immediately came to mind.

Mochiads is a service that lets you earn money by running pre-game ads. All in all, I wouldn't recommend this service for anyone trying to get rich : I've earned only $1,300 over 3.5 years with them, and my past games are actually pretty successful for the flash market.  Although I've made a decent living as a flash developer, almost none of it has come from ads, the bulk of my earnings having come through sponsorships, contract work, consulting, and other avenues.  Advertising is mostly chump change.

All that aside, Mochi is still good for free hosting!  I uploaded the game's demo to mochi's servers, disabled the pre-game ad, and voila!  I had an online, ad-free game demo and no server crash worries! Of course, Mochi's servers could always go down, but they're probably as or more reliable than my own hosting service, especially if there's a lot of traffic.

Don't show ads on our site!

If ads are shown for some reason, show one of ours

Mochi doesn't disallow this technique in their terms of service, and considering I'm still letting them make money off of ads in my older games, I feel okay with it.  Theoretically this means that I'm able to host the game for free without showing any ads, but if any ads crop up despite my settings I'll probably just suck it up and host the file myself, as ads turn people off and I'd much rather have a sale than measly ad revenue. This will become more important as the game gets closer to final launch.

Bending BitTorrent to My Will

Next, I needed a way to host the downloadable versions of the demo.  Hosting these files was a greater challenge than hosting the web version, as they were much bigger due to the uncompressed audio and graphics in the download version. Bittorent seemed like a natural solution - the more people torrent the file, the less stress my servers have as users start seeding to each other.

Of course, Bittorrent is not without its drawbacks.  For one, lots of people don't know how to use it.  For these players, however, there's always the web version which doesn't require them to download anything. Given that even downloading an exe file is too high a barrier for many people, this should take care of our less technical crowd.  The other problem with Bittorent, however, is that someone needs to be constantly seeding the files at all times.

Of course, I could have just left Bittorent open all day and seeded from my home computer, or asked all my team members to do the same, but that wouldn't be a permanent, fire-and-forget solution. I needed something stable, reliable, and cheap (preferably free).

One step in the right direction would be to web-seed the torrent file, linking it to a file on my web server, but that would still be a hit to my hosting bill I'd rather avoid.

That's when I stumbled across an interesting trick by googling around for a while.  Turns out, DropBox offers free file hosting up to 2 GB, and even better, provides web URLs to all your public files.  All Bittorent needs to set up a web seed is a URL - so, I dropped the demo installer files into my public dropbox, copied the dropbox URL's, and set those as the web-seed URL's for each torrent file.

Bittorent + Dropbox = free web seed!

Then, I just uploaded the .torrent files, and, magically, it all worked!  (To my knowledge, this isn't against DropBox's terms of service, either)  Now I had a web demo, and a set of cross-platform installer files, all freely hosted without paying a dime or violating any rules!

All I have to worry about now is if DropBox or Mochi's servers ever go down, but again, I'd be more worried about my own web host getting hammered then either of them.

As of this post, the windows and linux torrents are up. Mac version is coming soon!


Demo Length

Technical considerations aside, another important question we had was how to cut our game down from the full version to make a reasonable demo experience.  A lot of digital ink has been spilled on this topic, but as best I can summarize, the prevailing wisdom is :

• Give the player enough content to understand what the game has to offer,
• Stop short of satisfying them,
• Tease them with future content, 
• Convince them what's to come is worth it.

A common problem with demos is that they only give you the first few tutorial levels, so not only do you not get to do anything fun, you don't really get a taste of what features the game really has to offer.  On the other hand, if the demo offers too much, you feel you've gotten enough milk for free, so why buy the cow?

Given that our game features a fairly deep battle system with 6 unique character classes, each specialized for different combat situations, we could easily send the wrong signal by only giving them a handful of levels to play with one or two classes - we'd barely scratch the surface, and players could go away without knowing how deep the game really was. On the other hand, we still have to hold most of the game back.

For the player to feel that the full version will be worth playing, two things need to happen:

• The rest of the game needs to be much longer than the demo
• The player needs to correctly perceive that fact

Originally, our game was split into four "acts," not unlike a play. Act II fell at a natural stopping point, representing about 15-20% of total linear progress across the game's map (but only about 5-10% of the total gameplay, as later levels are longer and more involved), and introduced the player solidly to the first two character classes (berserkers and rangers) and just barely introduced the third (healer).


Sending the Right Signals

Immediately we ran into perception problems with our testers. "So... I've played through half the game already?" They said in the after-play debriefing session. "No!" I said "the final two acts are much, much longer!"  The testers stared blankly at me and replied, "Okay, I guess so - but there's no way to tell that from here.  Right now, the full version doesn't seem like it will be much longer if it's only four acts."  Perception is everything - even though the second half of the game was over twice the length of the first, dividing the experience up into "acts" created the expectation that each one would be roughly the same length.

Incorrectly implies 50% of total content

So, we divided up the content to span seven equally sized acts. Hopefully, this will make players feel like they've just gotten started, rather than nearly being through with the game.

Correctly implies ~20% of total content

Hold Something Back

Average play-time for the demo is between one and two hours, which is pretty high for a demo, so a few people suggested that I hold something extra back.  Originally, all mission sub-challenges were playable in the demo, so I tried locking all the "extreme" challenges after Act I.  Leaving the "advanced" challenges in would still showcase our extra missions and level design, but giving the player (particularly hard-core ones) something extra to long for.

Immediately, I started getting a reaction from testers. "I want that!" they said, pointing to the locked challenge.  I even got this reaction from players who previously had never even tried the extreme challenges.  I guess sometimes the simple act of holding something back can make people want it even more!

Encourage their Return

Since the final game isn't ready yet, we can't immediately direct someone to a "buy it now!" screen, so we need to give players some reason to come back.  For now, all we can really do is direct them to our website and encourage them to sign up for a newsletter.  I imagine most people will skip right past this, but it does give people a way to follow us and keep in touch.  Furthermore, if we wait to release a demo until the final game is ready, we lose the ability to build some buzz ahead of time, and overall sales will be lower.  As they say, better to get 10% of something than 100% of nothing.

This will be replaced by an "upsell" screen when the full version comes out

Respect their Time

Usually, when you sink a few hours into a demo, that time is lost as you have to start over when the full game comes out.  I don't have exact numbers on this, but I know of lots of people who have refused to play demos because they don't want to start over again, or, having played a demo, won't buy the full version even if they liked the game because the sting of lost time is too much.

So, we let the player export their save file.  When the full version comes out, they can import this and pick up right from where they left off.  This does open the game to cheating if players hack their save file text, but it's a single player game, so I don't really care :)

This screen is shown to the player  when they quit or finish the demo.

It's a small gesture of respect for the player's time, and hopefully when the full game is released, they'll see that little *.dfq file on their desktop and start itching to find out what happens next in Defender's Quest.


Future Considerations

All in all, the "soft launch" was a success. I got a lot of good feedback on the game, found a lot of immediate, obvious bugs to fix, and figured out some clever methods to host the game files without clogging my site with ads. When the final version comes out, we'll still be able to use this hosting method to keep our hosting costs down and our servers up should we have the "good problem" of too many users trying to play and download our game at once.

However, when we start selling the game, we'll need to have a direct download solution that works for our non-technical users who aren't comfortable with using Bittorrent.  In this case, whatever 3rd-party sales provider we use for our storefront (like FastSpring) should cover the hosting for the final game files themselves. (We'll also be trying to get the game out on Steam, etc).

The game's length feels about right, though we've gotten comments that it's still a bit long.  I don't mind being generous with the demo, so long as people still feel like buying the full game.  Right now, the experience takes you all the way to a climactic boss battle, resolves with a few cutscenes and then lets you visit the next town before you hit the "demo over" screen.

Some testers have suggested that letting the demo resolve leaves them too satisfied, and one suggested that I end it right after the boss battle, without the resolving cutscene, so it's more of a cliffhanger.  Instead of letting the party debrief and talk about the shadowy portents to come, this tester suggested I cut things off with a splash page that says "What happens next? Find out.... in the full game!"

I definitely see the reasoning, but I'm still not sure what the best decision is.  I'll keep showing the game to more people throughout the week, and once I've gotten enough feedback I'll tweak the final demo for the "real launch" next week. 

For anyone who wants to see the demo, you can play it online and/or download the installer for your OS here:

Play The Demo

So, that's my article on some of the things I learned in preparing a demo for launch. Any comments, criticisms, questions?

Designing an Anti-Incest Algorithm

(Cross-posted on gamasutra.com)


Once upon a time I was designing a game called Trondheim.  

In Trondheim, you would guide a small group of nomadic fairy-folk, the "Tronds," through a great and harrowing migration towards the mythical promised land called "Trondheim" (Norwegian for "Home of the Tronds").  The idea was that this journey would span several generations, so by the time you reached the final goal the original nomads would be long dead, but still live on in the memory and stories of their great-great-grandchildren. Each person would have a unique name and job in the tribe, and you would watch over them as they worked, married, gave birth, grew old, and finally died.

As the tribe would be small enough to track individual relationships, a problem arose: how would I keep the computer from marrying close relatives?  With a larger population, I could handle population growth abstractly, and with a population of anonymous animals I could mostly ignore the issue, but with a small group of individually named human characters, I needed to make sure no player would see Leif marry his sister Sonya.  Since the computer would decide the relationships, I needed an algorithm designed to detect and prevent incest.

Attempt #1:
Family Tree Traversal

My first idea was to simply check two potential partners for family ties, and then disallow certain relationships.  This required a list of "banned" pairings.  Though not universal, most cultures have incest taboos, the majority of which disallow marrying close blood-relatives, and often non-blood relations within the same family (aunts, step-relatives, etc) as well.  Western taboos are largely derived from the Old Testament, so I figured Leviticus was as good a place to start as any.  

Here's the list of marriage partners explicitly banned in the OT (assuming a male subject):

• Sister / Sister-in-law / Half-sister / Step-sister
• Mother / Mother-in-law / Step-mother
• Daughter / Daughter-in-law / Step-daughter
• Grandmother
• Grand-daughter
• Aunt

Using that as a starting point, I came up with the following "ban list" for my algorithm:

• Ancestors
• Descendants
• Siblings
• In-laws
• Step-relatives
• Aunts, Uncles, Nephews, Nieces
• First cousins

This broadly represents the incest taboos in modern western culture.  It differs slightly from the OT laws - I'm disallowing first cousins (not explicitly banned  in Leviticus),  but allowing second cousins, which I personally find creepy, but is a reasonable concession for a small nomadic population on the edge of survival.  Considering that marriage between first cousins is not unheard of in many parts of the western world (including the United States), our video game nomads are still adhering to a pretty conservative standard here.  I should note that although these taboos are largely a mechanism for addressing inherited diseases, there are social concerns as well, since it would strike most of us as creepy if someone married their mother-in-law, step-sister, or adopted child, even though they aren't related by blood.

Defining these relationships in computable terms requires a "family tree" data structure that grows over time and tracks everyone in the society's relationship to one another.  Whenever any two individuals are considered for marriage, the game runs an "incest check", which returns a value between 0 and 1, with 0 representing "no incest whatsoever," and 1 representing maximum incest, a sibling-sibling pairing.  The idea is to run a bunch of test cases through the algorithm, and then determine what an acceptable maximum value will be.

To calculate the incest factor, I line up each character's ancestors and compare them, father vs father, mother vs mother, patneral grandmother vs paternal grandmother, etc, and count how many ancestors they have in common. This gets complicated fast. 


Let's start with the case of two first cousins:

These first cousins don't have any parents in common - so far, so good, but they do have the same maternal grandparents.  They have 2/6 grandparents in common, and 0/4 parents in common, for a total of 2/10 ancestors, counting two generations back.  If we just count the number of shared ancestors and divide by the total number, we get a value of 0.2.  However, this raises further questions - first, how far back do we need to check?  Second, the above method leaves out the fact that although the cousins don't share any parents, their mothers are sisters.  So what do we do there?  On the one hand, since we've already counted the shared grandparents, this could implicitly account for the related mothers.  On the other hand, perhaps the algorithm should calculate the relative closeness of  each ancestor and then use those as weighted values to affect the final outcome.  At this point, some sort of recursive algorithm that cascades up and back down the family tree would be needed.

As much as that sounds like fascinating math problem, maybe there's an easier, more direct, way to do this.

Attempt #2: Virtual DNA

Since incest is primarily (but not exclusively) a genetic concern, let's try a genetic approach.  The easiest way is to just to assign each character a virtual "DNA" string at birth.  For our initial population, let's start with a diverse gene pool, with each individual having completely unique DNA.  To explain this in story terms, let's assume our society was not originally nomadic - they once lived in a great civilzation underground, but were chased out in a catastrophic invasion of subterranean trolls. This means that at the start of our game, our intitial "tribe" consists of unrelated refugees all thrown together by chance. 

Let's take a look at the DNA of two of our nomads, the tribe chieftans:

Our incest-checker compares the DNA strings, and looks for matching "genes."  There's zero matches here, an incest factor of 0, so this pairing is "legal."  Trondfar and Trondmor have two children, Trondson and Tronddatter, and each inherits half their DNA from their father and half from their mother.  (For simplicity's sake, we just inherit every other gene from each respective parent.  The charts below arbitrarily sort the genes for easy comparison.)

The incest-checker would return a value of 1.0  (all genes match) for these two, so they can't get married. Instead, Trondson marries a girl named "Sonya," and Tronddatter marries a boy named "Leif," (neither of whom are related):

Then, Trondson and Sonya have a son, "Trondsonson", and Tronddatter and Leif have a daughter, "Tronddatterdatter", yielding these two first cousins:

If these two were considered, the incest-checker would return a value of 8/16, or an incest value of 0.5, which is pretty high.  What's useful about this approach is that we no longer have to track direct relationships, just check how close each person's "DNA" is to another. We can supplement this by also tracking immediate relationships like step-relatives, adoptees, and in-laws to catch "non-blood incest."  All in all, the genetic approach works elegantly, quickly, and doesn't depend on laboriously checking geneology records.  It should be pretty easy at this point to run baseline checks on the relationships we want to disallow until we can determine what the maximum acceptable value is.  Under this model, second cousins would have an incest factor of 0.25.


There are, however, a few short-comings to this method, which brings to...

Attempt #3:

Virtual DNA 2.0

Virtual DNA is a good approach, but it could be improved.  For one, if I choose to make character appearance variable, it seems natural that characteristics such as hair, skin, eye color, etc, could all be driven by individual genes in the DNA string.  Even in a simple indie game with limited sprites, simple pallete-swapping and Mendelian inheritance could make it so children share characteristics with their parents. This requires some tweaks.

So far, we've only been using the virtual DNA to check against incest.  If we're using it to drive physical features, we need to model real genetics more closely.  With the old model, two children of the same sex from the same parents would have the exact same DNA, and thus the exact same appearance. In the new model, each person has two sets of DNA, one from their father, and one from their mother.

Here are our chieftans, then:

Trondson and Tronddatter would still get half their genes from Trondfar and half from Trondmor, but which genes they get in each slot is random. Trondfar passes on a DNA strand that contains a random mix of his two DNA strands, as does Trondmor:

This new system is more realistic, and accounts for inheritance better, but we've got a problem - with such a low number of "genes", it might be easy for our incest checker to fail!  Whereas the previous model would record a match on every gene for a sibling pair (since they are all essentially identical twins), the new model won't.  Let's look:

That's 6 matches for the father's genes, and 7 matches for the mother's, or about a 40% match overall.  In real life, siblings have just over 50% of their genes in common, on average (skewed high because of identical twins), so this result is pretty accurate.  However, since the inherited genes are chosen randomly, it's still conceivable the algorithm could run into edge cases like this:

Here, only about 15% of the genes match, an incest factor of 0.15.  The anti-incest algorithm would mistake these two for distant relatives instead of siblings.  Now, the chances of the above case are pretty slim, but even with just a few thousand people playing the game it would not be uncommon for players to report brothers and sisters randomly pairing off.  It wouldn't cost much to extend the length of the string to say, 50 genes from each parent (100 total), which would essentially eradicate the statistical likelihood of such flukes.  Even if I don't plan on using every single gene to drive some physical trait, the much longer DNA strand will ensure that the incest checker still works.  Interestingly enough, this is a lot like DNA in real life, where most of it doesn't seem to code for anything (that we know of, at least).

Throwing in a safety check to account for close relatives (and non-blood relatives) should keep things from getting creepy.

One final note - no fancy algorithm will protect our society from in-breeding in the long term with such a small population, as after only a few generations of interbreeding almost everyone will be related.  To fix this, we can include an "immigrant" mechanic (similar to the one in Dwarf Fortress), where other Tronds who escaped the cataclysm will randomly run across your tribe and join you, providing fresh, unrelated genes.  

So, there's a random page from my notebook. Maybe it will help someone in a project or something.
Any thoughts?

RPG's, challenge, and grinding.

Cross-posted on gamasutra.

As part of an ongoing series on our upcoming tactical RPG Defender's Quest, I'd like to talk about RPG's, challenge, and "grinding." Let's start with accessibility.

Accessibility

Accessibility is about expanding your game's audience by removing barriers.

The word "accessibility" immediately brings disabilities to mind, and as I'm disabled myself, let's start there.  Many games require good vision, hearing, reflexes, as well as two hands and ten fingers.  Often, these physical requirements are arbitrary, and the game could easily be redesigned so that a person with poor vision, no hearing, slow reflexes, and only one hand could still play the game to completion. These accommodations are rarely difficult or expensive to implement, and include such simple features as customizable controls, variable game speed, and visual choices tailored to the color-blind.

Of course, you can't accommodate everything.  It's tough to make visually intense games accessible to the totally blind, for instance, just as it's tough to make mountains accessible to quadriplegics.  I'm talking about printing books in braille here, not installing chair lifts to the top of Mt. Everest.

But the disabled aren't the only people who are often turned away from games, and physical skills are simply one barrier among many.  Plenty of non-disabled players are turned away in droves from games they could have otherwise enjoyed, usually by the game's difficulty.

Difficulty

Difficulty is probably among the top three reasons why people never finish a game.  Just as removing assumptions about physical skills expands the game's audience to the disabled, removing difficulty expands the game's audience to less hard-core players.  But how can a game remove difficulty without under-mining the experience?

A perfect example of an incredibly difficult and hard-core game that expands its audience through accessibility is VVVVVV. 

The accessibility options allow you to slow the game down, turn visual effects on and off, and even make yourself invincible. These options help expand the game to both disabled and casual players alike. It's quite surprising to see such features in such a hard-core game, especially given how many developers like to brag about how hard their games are (Demon's Souls, anyone?).

As my disabilities (Narcolepsy and Tourette's Syndrome) don't affect my ability to play games, I just kept the normal settings.  For me, slowing the game down or making myself invincible would "ruin" the experience.  So you know what?

I didn't turn them on.

I played the game and had a blast.  Furthermore, the game has extra difficulty modes and challenges for those who somehow find it too easy. These are normally unlocked through play, but you can unlock them yourself from the main menu if you want.  Personally, I like the feeling of achievement that comes with unlocking things myself - so you know what I did?

I didn't unlock them from the menu.

Meanwhile, I'm sure some gamer who hates being forced to unlock content they already paid for got to enjoy the bonus features immediately.  Another controversy solved through choice - everybody wins, so long as "winning" isn't defined as "forcing everyone to play the game the same way."

Removing barriers for other players, and even adding special features just for them, in no ways affected my enjoyment of the game.  Instead, I got exactly the experience I wanted, and so did plenty of other players.  This took a game that started with a narrow, niche appeal, and expanded it as far as its core design would allow.  I've heard some hard-core gamers argue in comment threads that any extra effort spent making a game accessible should have been spent "making the game better," instead.  Not only does this smack of entitlement, I fail to see how enabling diverse play styles doesn't count as "making the game better."

But more importantly, an interesting principle seems to be emerging here:

Players naturally seek out a level of challenge that matches their abilities.

Corollaries:

1. If the game is too easy, players will try to make it more challenging. 
2. If the game is too hard, players will try to make it easier.

I think games should be designed so that all the tools the player needs to make the game easier or harder are right at their fingertips, without forcing the player to resort to hacks, cheat codes, and custom mods just to get an experience that's right for them.  This should be done in a way that doesn't insult the player or cheapen the experience they're trying to set for themselves.

So, what does this have to do with RPG's, grinding, and Defender's Quest?

Grinding

Grinding is one of the oldest accessibility options in games.  If the player can't beat the next boss, she can always beat up some monsters, level-up, and try again.  This allows players of widely different skill levels to complete the same game on their own terms.

Whereas elite Final Fantasy I players could beat the last boss at the recommended Level 35, noobs like my 8-year old self  had to grind up to level 50 to stand a chance.  It wasn't a perfect solution, but it did offer a convenient "safety valve" that ensured that the game would not be impossible.  Back when it was an uncommon experience to see the end screen of any video game, RPG's were the only kind I could expect to finish.

At its best, grinding assures the player that victory is possible if they just keep playing.

At its worst, grinding artificially extend the game's length, and exploits the player through Skinnerian principles and addiction mechanics (as in certain facebook games*).

*Full Disclosure: I work on facebook games for my day job.

Grinding is simultaneously crude and elegant.  

It is crude because it punishes weaker players, who must spend more time grinding, and who often have less time to spend in the first place.  Furthermore, grinding itself is usually tedious.

It is elegant, however, because it lets the player smoothly adjust challenge just by playing the game, without any up-front commitments.  Not only can a casual player lower the bar by grinding, a hard-core player can raise it by refusing to grind, like trying to beat the Final Fantasy I at level 25.

When done correctly, the game's challenge becomes self-regulating. The player can naturally adjust the challenge level up or down as she progresses through the game.

Sam is a player that has weaker skills than the designers expected, below even what the game considers a "casual" level of play. Sam thus has to grind throughout the game to keep the challenge low.  Sally grinds a little bit, keeping the game around the "normal" level of challenge, whereas Bob refuses to grind except for just once late in the game, raising the bar as high as possible.

Now, let's see what happens to Sam's experience if we remove the option to grind.  Sam must now pick from "Easy," "Normal," and "Hard" difficulty modes at the start.  Being a weak player, Sam opts for "Easy" mode, only to find that most of the experience is still too hard for him.  Game designers often misjudge what counts as "easy," so I will join with Ernest Adams' in demanding that "Easy Mode is Supposed to be Easy, Dammit!"

The dark blue curve represents the level of challenge Sam would like to pursue, but without the ability to grind, he has no choice but to follow the difficulty curve dictated by the game's so-called Easy mode.  With no way to adjust this, Sam will probably quit soon after Dungeon 1.

Dynamic Difficulty Adjustment

A common solution to this problem (besides grinding) is "dynamic difficulty adjustment", or DDA. In this method, the game adjusts the difficulty mid-game in response the player's performance.  One of the earliest examples of this is the arcade shooter Dragon Spirit.  In this game, the first level was a hidden test - if you die, instead of losing a life you simply continue the rest of the game in "easy" mode, but if you survive, you  continue in "normal" mode.  This effect is largely invisible to the player.

Of course,when the player finds out they can feel cheated, and might respond by resetting the game whenever they die on the first level.  Other approaches to DDA, such as in God of War and Devil May Cry,  fix this problem by explicitly offering the player the choice of an easier difficulty mode after several deaths.  This puts control back in the player's hands, but sometimes feels like an insult:

DDA works, but it's not perfect.  The problem is that any pre-ordained difficulty mode can never match an individual's unique challenge curve, and switching between difficulties mid-game often just means choosing between "too hard" and "too easy."

Grinding doesn't work for all genres, but I prefer it to DDA for RPG's.  Both methods lower the difficulty bar, but grinding at least makes me feel like I've done something.  DDA just makes me feel like a loser who needs to go back to the bunny slope. 

Player-Driven Goals

Another solution to the difficulty problem is to let the player set their own goals.  Donkey Kong Country 2 is a great example, which I'll leave to David Sirlin to explain.  Summary: simply beating DKC2 is "fairly easy," but finding all the secrets and going for 100% completion is difficult, and the player gets to decide for herself what she wants to achieve. In this way, DKC2 lets the player chart her own difficulty curve.  When the game is "too easy," she can go after more secrets to ratchet up the challenge, but when the game gets "too hard," she can settle for just beating the level. 

I'll disagree with David on one minor point - simply beating DKC2 is not "fairly easy" - either that, or my wife and I totally suck at classic video games.  Either way, my point is that so long as the player is free to chart his own path, you can't go wrong by both lowering the floor and raising the ceiling on the game's difficulty.

Back to the Grind

For Defender's Quest, we combined player-driven goals with grinding in a way that we feels expands the game's appeal to as wide an audience as possible, without watering down the core gameplay or wasting anyone's time.

Let's start with a screenshot:

In keeping with the conventions of tactical RPG's such as Final Fantasy Tactics, and other tactical games like Advance Wars, each battle is a unique set-piece on a large map.  This comes at the cost of a free-roaming overworld, but given our non-existent budget and disdain for random battles it felt like the right choice.  Our game's tightly focuses on battles, customization, and story.  Exploration will have to wait for the sequel.

There are exactly zero random battles in Defender's Quest.  Each battle is uniquely designed, and comes with several challenge variations ranging from very easy to very difficult.  To progress to the next battle, all the player has to do is survive a battle on the easiest challenge.

The three "main" challenge modes are normal, advanced, and extreme, which correspond to the three stars underneath each battle on the map.  The different modes are balanced such that "normal" is the natural starting point, with "advanced" and "extreme" being extra challenges the player should come back for later when they've gained a little experience.  

This lets the player set their own goals, as well as making grinding less boring.  If the player just wants to play through the game, they can ignore the higher challenges.  If they do get stuck, however, they don't have to waste time playing the same battles over and over again - instead, they can try some of the harder challenges from earlier levels, which are now within their reach.

Furthermore, each of these different challenge modes features a unique variation on that level's basic design.  This lets achievers ratchet up the difficulty and go for 100% completion, while still allowing weaker players to progress without getting stuck or bored.

Even with these challenge modes, however, we found that some players still needed the ability to "drop down" to something easier than the baseline.  This caused a bit of a dilemma, since we didn't want more advanced players to get turned off if they accidentally picked the easiest challenge, mistaking it for the intended starting point.



To solve that, we added a vertical separator and gave the new challenge mode the name "casual," as well as tool-tips to explicitly spell out the differences between challenges.

Also, rather than adding a fourth star underneath each battle, we made beating casual mode simply fill the first star half-way, so that "normal" mode is still clearly the baseline and intended starting point:

Casual mode was a hit with many of our testers.  It not only opened up the difficulty space, but also increased the game's appeal to an unexpected audience.  Many testers mentioned that since they'd grown up they have a lot less time to play games, especially 60+ hour epic RPG's.  Not only does casual mode offer a solution to getting stuck, it offers a solution to not having time.  The upper and lower bounds for completing Defender's Quest now sits at roughly 5-50 hours.  Players can fly through in casual mode (ideal for the sub-set of RPG fans who are "just here for the story"), or they can squeeze every ounce of tactical goodness out of the battle and upgrade systems by trying to go for "perfect" on every single challenge.

We made one last choice, however, that I feel might be controversial:

Story is never held hostage by difficulty

Beating a level's casual challenge with only a passing score is all that is necessary to progress and see the next cut-scene.  Furthermore, the game has multiple endings, all of which are equally achievable no matter which challenges you beat.  Let me relate a quick story so you can understand where I'm coming from on this one.

Certain games are appealing because they are difficult.  The reward of conquering an insanely-hard game is all that much sweeter, especially if that reward is a better ending.  For instance, I will never forget the feeling of triumph I had when I beat the "Running Hell" challenge in Cave Story for the first time, unlocking the best ending, which prevents the death of a beloved character I previously thought to be inevitable.

Conquering a tragedy by being totally freaking awesome adds punch to a happy ending in a way that schmaltzy Hollywood fare simply can't match.  It ranks among the best experiences I've ever had in a video game.

As a designer, however, I wonder how many Cave Story players ever made it that far.  Furthermore, this particular challenge was right at the edge of my abilities.  Wouldn't a weaker player have felt the same sense of challenge and triumph if he could play right at the cusp of his skills?  Would allowing him that triumph cheapen my victory, knowing that I could have lowered the bar for myself?  And even if supposing it would cheapen my victory, why should the game's designer pander to me rather than the other guy?

Inevitably, some small fraction of players will find ways to see the endings to games they can't beat.  Either they will use a cheat code, hack the game, or wait for tools like emulator save-states to arrive that let them play the game in a way they can handle.  Rather than forcing these persistent few to jump through hoops simply to enjoy a video game, why don't we as game developers meet them half-way, and just give them well-balanced tools up-front that don't spoil the experience for anyone?

Those are my thoughts. I'd be interested in hearing yours!

And for those of you who are wondering, yes, I beat the "Running Hell" challenge in Cave Story, as well as the punishing spike-fest that is VVVVVV, but somehow never beat Donkey Kong Country II, even after 16 years.  Those bramble levels with the stupid parrot are tough, man!