Frayed Knights: Twisty Paths and Flickering Torchlight
Frayed Knights is an indie computer role-playing game (CRPG) in development in something of the style of old-school first-person-perspective dungeon-crawlers like Wizardry, the original Bard's Tale series, and the D&D "Gold Box" games. But then it totally throws the whole thing on its ear with a comedy twist and a refusal to take the genre seriously. Here is another of the weekly updates in the ongoing development saga. If bleeding out of the eyes persists after reading, consult your physician.

Dungeon Dressing - Ranch Style!
Back when I was 12 or so, I loved reading through all the appendices of the Dungeon Master's Guide for D&D. Yes, I was as much a geek then as I am now. In order to help DMs (Dungeon Masters) with their creativity, one appendix was filled with "Dungeon Dressing" (Appendix I, if anybody's counting...) A random table of all kinds of junk you might find in a dungeon. Nevermind that if you just threw those into any old dungeon room, it would make no sense whatsoever. An acrid oder, a broken arrow on the foor, a torch stub, scattered teeth, and a buzzing noise...

All that junk might work in the Temple of Pokmor Xang, though. As I was describing the level to Kevin a few weeks ago, I told him to imagine that the temple was the domain of some "trailer trash orcs." In fact, I want to give the high priest's bed a broken leg, so it can be propped up on a block or something. Unfortunately, that means content. Lots and lots of content.

So I spend a bit of time this week working on the "dungeon dressing." Not all the random bits I just described, but certain key elements like light sources, doors, gates, and other objects that need to be interactive, give off light, or respond to scripts.

Torching Things
You know what? A simple freakin' torch in a sconce can take a LOT of time. Maybe it's only because I'm still not a very fast modeler or something, but for some reason I chalked the whole idea of making a torch - something less than 100 polygons - to something I could whip out in oh, say, an hour or something. How hard can it be? (Yes, it is that very question that probably causes all insanity in game development.)

Well, not hard. But time-consuming. For those unfamiliar with the process, the steps include:

#1- Finding some pictures on the web to base my model on. Not that I actually used any of them directly, but it helped to know what different designs of torch sconces have in common

#2 - Building the geometry, which is actually pretty fast.

#3 - Texturig the model. UGH. This is probably the slowest, painful, and least-satisfactory portion of the process for me... at least for models that don't need to be rigged and animated. Fortunately I have Genetica, which is good for creating a base-layer texture for almost anything.

#4 - Repeating steps 2 and 3 for all levels of detail (LOD) of the model. Although at this stage, I'm not doing much with LOD. And to be honest, this stage usually comes after stage 5 and I know the high-LOD version is just right.

#5 - Exporting the model into Torque's DTS format. I've done this enough that setting it up for export in Blender is cake. But it takes a couple of iterations.

#6 - Creating a particle system for the torch flame. I use an example particle system as a base, but it needs tweaking. That means a lot of iteration.

#7 - Creating appropriate lighting information for the torches.

#8 - Going back and repeating steps 2 - 7 until it looks just right.

When all was said and done - the quick, stupid little torch sconce ended up taking me about three hours. And it still doesn't look perfect or anything. So there was one full night of development.

Pictures of Pimple Gods...
I repeated similar steps for a candle, a table, and a portrait of "Happy Pokmor Xang". You can see the end results in that top picture - though the candle is barely visible in the distance.

Besides this, and adding some smoke to the firepit in the altar room (the altar IS being turned into an actual 3D model even as I type this!), I have been adding scripted doors and a portcullis (still not fully textured or animated) to the level. Which brings up another interesting story...

Well, interesting if you are me. But I'm a programmer, Which means I get laughs out of stories that end in punchlines like, "Oh, and then I realized that I hadn't dereferenced the pointer before post-incrementing it, so I was stuck in an infinite loop!" Hah, hah, good times.... But I digress...

Dealing With Dungeon Speed-Runs
I was doing a "walk-through" on the dungeon, and I realized that, if you played it just right, you could actually bypass about 70% of the content as it is currently designed. Now, I'm all about the optional content and secret areas and stuff like that. In fact, my biggest concern is that with the game being so heavy on the story and dialog, that it might be too linear. So while the chapters occur in pretty linear fashion, I want the player to be able to chart his course through it pretty much as he pleases.

But, I also would like to not have players complain that the first dungeon is way too short, or that the Frayed Knights is only fifteen minutes long.

So I did a little bit of redesign, drawing upon my experience as a Pen & Paper RPG game-master. There are all kinds of ways of solving this problem, and I'm going to try and adopt a similar policy for all content in the full game:

Hard Barriers
First of all, you've got hard barriers - the traditional way to handle things that you see in almost every game. This comes down to designing the areas in a fashion where it's simply impossible to get to point E from point A without passing through points B, C, and D. This can be done with dungeon layout, as well as providing obstacles between A and E that can only be removed by visiting these other areas. I resolved this by adding some defensive portcullises to the dungeon that must be raised in some other area. Yeah, boringly traditional, that's me.

Soft Barriers
But I also wanted to introduce the concept of soft barriers. Which means more coding on my part. These are things that encourage the player to hit the other points without forcing the issue.

Example #1 - the key to a locked door is in another area. However, you can still pick the lock. It may just take more time and risk.

Example #2 - As they approach the big "boss encounter", the Frayed Knights note out loud that since they haven't cleared out the areas behind them yet, they could find themselves surrounded in an upcoming fight. Which happens, if the player refuses to take the hint --- the player will have to face one or two waves of reinforcements during the boss battle (depending upon how much of preceeding areas they've tackled). So they can brute-force it if they want.

I'm going to try and be more mindful of creating some more of the "soft barriers" to challenges in the future. Basically, the soft barriers provide the player with additional choices. I figure that's a good thing. The trick is to make sure the player knows he's got a choice. In example two, it comes from the characters making a mention of a possible threat. In the first example, how does the player know that the key to the door is available?

So that's what's been going on this week. Mostly between the hours of 11:00 PM and 2:30 AM. How's your week been?


(Vaguely) related examples of cruelty to pixels:
* Frayed Knights: Are You Experienced?
* RPG Design: The "Brute Force" Problem
* RPG Design: Why Can't I Get Past the Stupid Door?
* Big World, Small Dungeon: Does Size Matter in RPGs?

Wanna Talk About It? Here's the Forum Thread.

Labels: Frayed Knights, Game Design, Roleplaying Games

- posted by The Rampant Coyote @ 6:00 AM (Permalink)