Sent out this newsletter just now:
*************************************
Hey Defender's Quest Fans!
We've got some news!
The game is basically finished - while we clean up a few things on the technical side, we're waiting on our lawyer to finish the paperwork that will allow us to legally sell the game. The minute that's done, we can put the game up for sale. We don't know exactly when that will be, but from the looks of it'll probably be a week or so, pushing release back to January.
On the development side, we've been having a REALLY successful pre-release test, and fixing lots of bugs and balance issues. The game is very nearly ready. All that's left is to fix a few remaining bugs and tie up some loose ends, and then verify that the build is stable.
To that end, we have the goal of producing a "release candidate" build of the game before the end of this week.
A "release candidate" is a special build of the game that we release to our testers and REFUSE TO TOUCH while testers do their best to break it. That's because every time we fix a bug or add a feature, we might accidentally introduce a new bug, so we can't release a build to the public that's been modified recently. So, after several days of solid testing, if our release candidate survives, we can be reasonably sure that it's ready to present to the public at large.
Seeing as most of our team members are going to visit their parents for the holidays, we'll be unable to work on the game for a period of about 3 or 4 days. This is the perfect time for any testers looking for something to do over the break to have a crack at our release candidate. When we come back, we'll check the bug reports, and if there's no significant problems, we will have officially "gone gold," as they say in the indstury.
Hopefully our lawyer will be done with our paperwork by then and we can open our doors for business!
As we said before, this initial release will be a "beta" release at the discounted price of $6.99, but all you newsletter subscribers will be able to buy it for $4.99 with the coupon code I'll send you.
We'll be checking in again real soon!
Thanks,
Lars Doucet
Level Up Labs
News! Facebook and Google+ Pages!
Just sent out this newsletter:
Hey there Defender's quest fans!
First of all, a huge thank-you goes out to everyone who signed up for the pre-release test. We've gotten some really great feedback and have uncovered (and eliminated!) many crucial bugs. If you haven't signed up for the test but are still interested, we're still taking volunteers:
http://www.fortressofdoors.com/2011/12/news-calling-for-testers.html
As a reminder, if you want to see the game in its best state, I'd recommend waiting until it comes out :) Sign up for testing if you don't mind braving bugs and unfinished content.
NEXT, we've set up a facebook page and google+ page! We'll be updating them as time goes on (just bare bones for now), so please "like" / "+1" us and tell all your friends about the game!
http://www.facebook.com/pages/Defenders-Quest/308928752464186
https://plus.google.com/u/1/109122598390891962328
Speaking of the game's release, we're very nearly there! Only a few minor things are left to do - here's what we're working on:
-Proof-reading grammar and spelling
-Finishing up some cutscenes
-Adding some missing art
-Balancing the last batch of levels
-Adding sound effects
-Fixing as many bugs as testers can uncover
All three builds (Mac/Windows/Linux) seem to be installing and running smoothly, but we could always use some more Mac and Linux testers to make sure, as the majority of our testers are running Windows. So if you run Mac or Linux and haven't signed up for the test, we'd love to have you!
We are very close to release - we're in the process of setting up our online store and contacting distribution partners like Steam/Desura/Impulse, etc.
We can't announce the official release date yet, but it should be soon! We will let you know as soon as the game goes Gold.
Thanks for everything!
-Lars
Hey there Defender's quest fans!
First of all, a huge thank-you goes out to everyone who signed up for the pre-release test. We've gotten some really great feedback and have uncovered (and eliminated!) many crucial bugs. If you haven't signed up for the test but are still interested, we're still taking volunteers:
http://www.fortressofdoors.com/2011/12/news-calling-for-testers.html
As a reminder, if you want to see the game in its best state, I'd recommend waiting until it comes out :) Sign up for testing if you don't mind braving bugs and unfinished content.
NEXT, we've set up a facebook page and google+ page! We'll be updating them as time goes on (just bare bones for now), so please "like" / "+1" us and tell all your friends about the game!
http://www.facebook.com/pages/Defenders-Quest/308928752464186
https://plus.google.com/u/1/109122598390891962328
Speaking of the game's release, we're very nearly there! Only a few minor things are left to do - here's what we're working on:
-Proof-reading grammar and spelling
-Finishing up some cutscenes
-Adding some missing art
-Balancing the last batch of levels
-Adding sound effects
-Fixing as many bugs as testers can uncover
All three builds (Mac/Windows/Linux) seem to be installing and running smoothly, but we could always use some more Mac and Linux testers to make sure, as the majority of our testers are running Windows. So if you run Mac or Linux and haven't signed up for the test, we'd love to have you!
We are very close to release - we're in the process of setting up our online store and contacting distribution partners like Steam/Desura/Impulse, etc.
We can't announce the official release date yet, but it should be soon! We will let you know as soon as the game goes Gold.
Thanks for everything!
-Lars
News! Calling for Testers!
Just sent this newsletter out today:
(REPLY TO: defendersquest@gmail.com)
Hey Defender's Quest fans!
First, thanks so much for being patient with us as we prepare for our preliminary "Beta Launch" this month, at a special discounted price of $6.99 ($4.99 for you newsletter subscribers!)
(We're getting very close - things are coming together and as we approach release we will send out frequent updates.)
Second, thanks to everyone who sent in their save files. We have waaaaaay more than we need at this point! You guys are awesome.
Third, thanks to everyone who sent us e-mails of encouragement and support. It's really great to hear from you, and nothing motivates us quite like hearing that you guys can't wait until our game comes out! Our only hope is to meet (and hopefully exceed) your expectations :)
Fourth, some people were wondering why they hadn't received a coupon code yet. We haven't sent them out yet :) Those will be sent over the newsletter at the same time as the Beta Launch.
Fifth, on to other business:
We don't have a specific date to announce just yet, but we can say that we're veeeery close. All that's left right now is bug-fixing, balancing, and plugging in art for a few cutscenes. To that end, we'd like to recruit some of you to help us test the game before we launch. If you want to VOLUNTEER to be a tester, send an email to defendersquest@gmail.com and put "TEST VOLUNTEER" in the subject line and we'll hook you up with the latest builds of the full version of the game.
NOTE FOR TESTERS:
Now, let me explain real quick - if you volunteer to test the game, you'll be seeing an incomplete version of it. If your motivation for testing is just to play the game sooner, I STRONGLY recommend just waiting until it comes out - testing games is not always fun. The final version will be much better than any unfinished test version we can provide you with right now.
If your motivation is to help us make the game better, and you don't mind braving bugs, unbalanced levels, and a few rough, unfinished, cutscenes, then by all means sign up! We appreciate anyone who volunteers their time and effort to help us make the game better.
So, here are some basic guidelines for being a tester. If we provide you with a test copy, you agree to:
1) NOT re-post it anywhere or otherwise share it with people
2) Thoroughly test the game and look for bugs, glitches, balance issues, etc.
3) Provide us with useful and detailed written test reports (we'll give you templates and instructions)
4) Give us complete permission to use any information, ideas, data, or anything else you share with us
The main things we're looking to discover through testing:
1) Obscure technical details -
Does the game work on old computers? Does it crash on Linux? Does it run slow on Mac? Does it fullscreen properly on a netbook? Does it break on dual monitor set-ups?
2) Bugs - when and where does it crash, break, or otherwise screw up?
3) Balance - let us know when and where the game throws you up against an insane difficulty wall or suddenly becomes way too easy.
Here's some things we're NOT looking for in testing, because it's way too late in the game to address now:
1) Cool ideas for new features
2) Revisions to the story
3) Art style changes
Thanks for everything! We'll be sending out more updates as we get closer to launch, so stay tuned! And of course, if you don't like getting these newsletters, feel free to unsubscribe using the link at the bottom.
Thanks,
Lars Doucet
Level Up Labs, LLC
(REPLY TO: defendersquest@gmail.com)
Hey Defender's Quest fans!
First, thanks so much for being patient with us as we prepare for our preliminary "Beta Launch" this month, at a special discounted price of $6.99 ($4.99 for you newsletter subscribers!)
(We're getting very close - things are coming together and as we approach release we will send out frequent updates.)
Second, thanks to everyone who sent in their save files. We have waaaaaay more than we need at this point! You guys are awesome.
Third, thanks to everyone who sent us e-mails of encouragement and support. It's really great to hear from you, and nothing motivates us quite like hearing that you guys can't wait until our game comes out! Our only hope is to meet (and hopefully exceed) your expectations :)
Fourth, some people were wondering why they hadn't received a coupon code yet. We haven't sent them out yet :) Those will be sent over the newsletter at the same time as the Beta Launch.
Fifth, on to other business:
We don't have a specific date to announce just yet, but we can say that we're veeeery close. All that's left right now is bug-fixing, balancing, and plugging in art for a few cutscenes. To that end, we'd like to recruit some of you to help us test the game before we launch. If you want to VOLUNTEER to be a tester, send an email to defendersquest@gmail.com and put "TEST VOLUNTEER" in the subject line and we'll hook you up with the latest builds of the full version of the game.
NOTE FOR TESTERS:
Now, let me explain real quick - if you volunteer to test the game, you'll be seeing an incomplete version of it. If your motivation for testing is just to play the game sooner, I STRONGLY recommend just waiting until it comes out - testing games is not always fun. The final version will be much better than any unfinished test version we can provide you with right now.
If your motivation is to help us make the game better, and you don't mind braving bugs, unbalanced levels, and a few rough, unfinished, cutscenes, then by all means sign up! We appreciate anyone who volunteers their time and effort to help us make the game better.
So, here are some basic guidelines for being a tester. If we provide you with a test copy, you agree to:
1) NOT re-post it anywhere or otherwise share it with people
2) Thoroughly test the game and look for bugs, glitches, balance issues, etc.
3) Provide us with useful and detailed written test reports (we'll give you templates and instructions)
4) Give us complete permission to use any information, ideas, data, or anything else you share with us
The main things we're looking to discover through testing:
1) Obscure technical details -
Does the game work on old computers? Does it crash on Linux? Does it run slow on Mac? Does it fullscreen properly on a netbook? Does it break on dual monitor set-ups?
2) Bugs - when and where does it crash, break, or otherwise screw up?
3) Balance - let us know when and where the game throws you up against an insane difficulty wall or suddenly becomes way too easy.
Here's some things we're NOT looking for in testing, because it's way too late in the game to address now:
1) Cool ideas for new features
2) Revisions to the story
3) Art style changes
Thanks for everything! We'll be sending out more updates as we get closer to launch, so stay tuned! And of course, if you don't like getting these newsletters, feel free to unsubscribe using the link at the bottom.
Thanks,
Lars Doucet
Level Up Labs, LLC
New Art Style
Let's talk a bit about the new art style we've been trying out. The biggest weakness we have right now is that the team doesn't have a dedicated artist. I (Lars) consider myself a half-decent artist, but I've been so busy programming, blogging, running around putting out fires, etc, that I have very little time to dedicate to art at this stage of the project.
We initially assumed that we could just get away with using me for both jobs, but that's something we won't be doing again. Next project - dedicated artist for sure.
So, a few weeks ago we took a good look at our art style and decided to make some changes. Our goals:
1. Make something we're happy with
2. Create backgrounds that don't look like barf
3. Make the characters more expressive
Nothing good needs to be said about the old backgrounds. They're hideous, and they're all being replaced:
The old art style just clashed and was honestly something really thrown together while we focused on other parts of the game. The new style is simple, clean, and works well with the new character style.
As for the characters, the old art style was a collaboration between myself and our writer, James - he designed the characters and then I did some cleanup work, shading, etc. In the end, this not only took too much time, but had mediocre results (which I'll take the blame for). Although I'm partial to the comic-book style with outlines and shading, it takes way too long, and is prone to errors when I'm rushing (if you look closesly, you'll find places where shadows are going in two different directions). With a dedicated artist this wouldn't be a problem, but given our situation we decided a style without outlines and hard shading would be faster, mesh better with backgrounds, and easier to revise.
NOTE: We're not looking for an artist right now (at least not for this version of the game). We've already had people offer to work for free - we appreciate the sentiment, but we won't hire someone without compensation, and right now we can't afford more team members. If the game is successful, and we plan on a sequel or porting it to a new platform - then, definitely, send us your portfolios :)
For now, James is doing all the new art, with only a little bit of help from me, freeing me up to do a lot more programming and systems work. So, let's take a look at some of the new stuff:
I wasn't really happy with Azra's proportions, hair-style, and expressions. She also looked like a cross between an 8-year old and Kim Possible. We want good expressions to really sell the story, and the new art style frees us to do that. The lack of outlines and hard shadows makes it easier to just get in there and change things in a few minutes without getting caught up in detail. The previous style was very difficult to revise - so if we had a mediocre pose, we were more likely to stick with it rather than throw it away and start over. That, and we can crank out a lot more unique poses for specific lines of dialogue, rather than just re-using the same three or four over and over again.
All the characters have way more poses now, and the expressions are really great, the story feels like it's coming to life in a way that it didn't before.
For those who complained about the scene with Ketta from before - that was the first scene we did in the new style, so we'll definitely be giving it another pass before shipping :) Also, Ketta's new character design was inevitable regardless of art style, because a disturbingly large amount of testers didn't realize she was a woman, and in battle players had a hard time distinguishing her head icon from Slak's because they both had big red afro's. We'll post an updated version of that cutscene as soon as we polish it up, and hopefully it will address people's concerns that it wasn't expressive enough. If not, oh well - we can't please everyone :)
We've also updated in-game dialogue, which looks way better and conveys a lot more emotion:
Anytime you change an art style this drastically, it comes with risk. I've already gotten a few negative comments by people who preferred the old style, for instance. All I can really say about that is that I do appreciate any feedback we get, negative or positive, and I hope you guys understand that we'll do our best to address everyone's concerns, but ultimately we have to go with what we think is best for the game. Also, the little snap-shots I put out aren't always going to be indicative of what you see in the final version of the game, so we'll keep changing/polishing right up to the end.
We WILL be releasing a new version of the demo to coincide with our "Beta" launch, so you'll be able to see how it looks AND plays before deciding to buy.
We hope you like it! And if not, we hope you at least still like the game :) I'll be posting shortly about all the super cool amazing awesome stuff we've been up to.
I think you're really going to like Acts III-VII, and if I may say so myself, the final battle is pretty cool. We've been giving it a lot of special attention.
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:
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
On to ze newsletter:
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 |
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.
- Is mathematically sound
- Doesn't look like a glitch
- Doesn't seem "unfair"
- 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.
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!
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:
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).
- One mage slows the enemy down
- Another mage hits it with a second slow spell
- The enemy speeds up!
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.
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.
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.
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.
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 :
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:
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.
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.
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.
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 :)
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
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).
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.
 |
| Don't show ads on our site! |
 |
| If ads are shown for some reason, show one of ours |
Bending BitTorrent to My Will
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:
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.
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.
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.
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.
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
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.
- 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.
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...
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.
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?
Any thoughts?
Posts
