18 February, 2011
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. :)
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.
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.