Psychochild's Blog

A developer's musings on game development and writing.

18 February, 2011

What went into the design of The Fae’s Wyrd?
Filed under: — Psychochild @ 6:57 PM

Frequent commenter DamianoV wanted a better glimpse into the sausage factory:

An interesting write-up would be a discussion of the deliberations you underwent in the design and implementation of The Fae’s Wyrd.

Instead of banging out a long comment, let me write a post. :)

DamianoV wrote:
How did you define and fine-tune the effects of the 4 elements in the 4 abilities?

As I’ve pointed out before, my starting point was the elemental advancement system I outlined before. Really, the three purposes of the game was: 1) to test out the elemental advancement system, 2) to develop our Flash skills, and 3) to maybe make some money. You can design a system, but even the best prototype isn’t a good substitute for putting it within the context of an actual game. Note that I think a design writeup like this is invaluable for planning. You always have to adjust to reality, but it gives a great basis from which to work. I know other designers advocate a much more lose design methodology (and I’d say we used one for the game overall), but detailing out some aspects of a major system like this can help.

Speaking of adjustments, you’ll notice that one thing we changed was to remove “attack speed” and add in “slice”. My original design envisioned something like the “active time battle” system from the Final Fantasy games. So, faster attack speed means being able to go faster. Given how we structured the in discrete rounds, that wouldn’t work.

So, I was inspired by a few other grid-based RPGs and introduced the “slice” technique. Basically, the more slice ability you have, the more often you can use the “slice” command. With a melee weapon, you can “slice” through all monsters in the same column (front or back), and with a ranged weapon you can hit monsters in a single row. This added a strategic element in that your choice of target might change if you figured you would get a slice next round, especially with a bow wielder.

The actual adjustment of how much to-hit is added by adding a Water shard to your offense ability was initially about math. Your total chance to hit is your to-hit value less the enemy’s dodge. I calculated “average” values and figured what would be a good value. To put this in perspective, characters start with a 100 to-hit value and 10 dodge. So, a character trying to hit him- or herself would do so 90% of the time. Monsters get a bonus dodge every “rank” between 1-3 points. This means that if you put half your offense shards as water (+5 to hit per shard), you’ll have a very good chance to hit most monsters; I didn’t want to require the player to put all offensive shards as water to do so, since “to hit” is a rather boring stat. I played the game through several times to make sure that felt right, especially at the lower levels.

The other interesting design issues I considered was how fast players should advance compared to the monsters. Originally I had it so that you got 1 guaranteed shard at the end of every level, and monster “rank” went up ever 5 levels; with 4 characters, you would advance about 1.25 shards per character per monster rank, not including shards randomly found in chests or after combat. That seemed too slow, so I increased it to 2 shards at the end of every level and monsters going up rank ever 3 levels. This meant that avoiding combats and chests you would go up 1.5 shard per character per monster rank. This allowed the player to control their difficulty level somewhat, where a player could do more fights and try for more chests if they felt combat was getting a bit too tough.

DamianoV wrote:
What considerations went into the design of the interfaces (character creation, exploration, combat) in terms of what information was offered and how much control and input was allowed?

Dave ‘Over00′ Toulouse designed the interface details, and Sara Pickell did the art for most of them. I’ll let either of them comment on their own blogs or in comments if they have any particular insight to share.

As for exposing information, we played around with a few options, but ultimately we felt it was best to expose as much info to the player as possible about upgrades, etc. We went with what was easy to implement in our system for the most part. We originally just had weapons showing stats, but our donors gave feedback that they wanted easy comparison. We added that for them near the end.

Not to slam the work Dave or Sara did, but I think the interface is the weakest part of the game. I’m a crap UI designer, in that I know enough to know what I don’t know and understand that I’m crap at it. I think Dave did a pretty good job, but there are obviously issues that could be addressed. When the game was reviewed by Flash Game License, the comments we got were that the interface was decided a bit too old school for its own good. (I suspect if we had drag-and-drop functionality, at least, that would make it feel a bit more modern.) Given our lack of real bids, I suspect this is a big drawback of the game.

As for the game itself, we’re still deciding what to do. One way or another it’ll be released. It’s just question of if we can get a sponsor for it, or if it just shows up on our own site, for example, for anyone to play.

Any other questions? Leave them in the comments and I’ll answer as I can.


  1. At the risk of sounding overnerdy or greedy, I’d really like to see a FAQ sort of maths treatment of the relevant playable stats. Sometimes I find myself reading those number-heavy Strategy Guides more than playing the game. Let’s call that an occupational hazard.

    I can totally understand not wanting to put that out there, but that’s the sort of data I love to sift through and see patterns. The math that you’ve outlined above are a nice teaser of what you’ve got going on under the hood, so thanks! :)

    Comment by Tesh — 19 February, 2011 @ 8:54 PM

  2. It’s funny, but as much as I’d examine a game by maths much as you describe, Tesh, I really don’t want to know any details when I play the game. That’d pretty much ruin the experience for me.

    (Depending on the game, I’m fine with knowing such details after the first playthrough. I do like reading strategy guides afterwards.)

    Comment by unwesen — 20 February, 2011 @ 3:46 AM

  3. RPG without drag and drop? That IS pretty old school. In my memory I have to go back to Ultima V for that.

    Comment by silver — 20 February, 2011 @ 8:37 AM

  4. Yeah there was a lot of learning for this project and that resulted in the project taking much longer than expected and the interface not as nice as it could have been.

    Adding stats comparison for example gave me quite some headaches not because it’s really hard to do in the end but just to figure out how I should get started to do this in AS3 with the code structure we had. I ended up rethinking the tooltips so what should have been a breeze for someone with experience was a bit complicated for me who was learning while doing it.

    So things like drag and drop were simply left out as I already had my hands full (and we were still trying to not take 6 months to release that). Revisiting the interface might end up in more work than expected as things might not be really fit for it as they are right now.

    It was a great learning experience in the end and one that was required.

    Comment by Dave Toulouse — 20 February, 2011 @ 1:58 PM

Leave a comment

I value your comment and think the discussions are the best part of this blog. However, there's this scourge called comment spam, so I choose to moderate comments rather than giving filthy spammers any advantage.

If this is your first comment, it will be held for moderation and therefore will not show up immediately. I will approve your comment when I can, usually within a day. Comments should eventually be approved if not spam. If your comment doesn't show up and it wasn't spam, send me an email as the spam catchers might have caught it by accident.

Line and paragraph breaks automatic, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Email Subscription

Get posts by email:

Recent Comments


Search the Blog


March 2017
« Feb    



Standard Disclaimer

I speak only for myself, not for any company.

My Book


Around the Internet

Game and Online Developers

Game News Sites

Game Ranters and Discussion

Help for Businesses

Other Fun Stuff

Quiet (aka Dead) Sites

Posts Copyright Brian Green, aka Psychochild. Comments belong to their authors.

Support me and my work on