Frayed Knights: The Exploding Lock and Other Stories
And now, for an "super-sized" installment of the chronicles of the creation of the comedic computer RPG, "Frayed Knights." Alliteration at no extra charge.

We've Got Trouble
We've got three months left to complete the first chapter. We're officially behind schedule. The temple of Pokmor Xang was supposed to be completed by January 1st. It ain't gonna before the first week of January is over. This means we are officially in trouble, and the project... while not in jeopardy, exactly, is slipping. I'm not sure by how much, which is something I have to determine, fast.

James has been out of communication for the last few weeks. I assumed it was due to the holidays, but it was actually because a water main near his house burst and had caused flooding - and damaged his computer. On the plus side, the computer is now fixed and the city is paying for the damages, but he's not been able to do anything for several weeks. Ouch.

Kevin's been doing an awesome job on the temple. I've got some more pictures to show off his work. No, there's not supposed to be a troll up on the balcony, but it looked cool.

From the code side of things --- well, there's some amusing stories there. Want to hear 'em? No? Well, tough. I'm tellin' 'em anyway. I've been frantically trying to get the principle path through the dungeon complete, and it's just about done. But I keep running into new things I need the game to do which I hadn't anticipated - which means writing new code.

Phat Lewtz Part Two
To get to the upper level of the temple, there's a locked portcullis you need to unlock. There are two ways of doing this. The "hard way" is to pick the lock. It's a difficult lock, so it may take several tries and some wandering monster checks. However, if you don't want to do that, you can go down to the lower wing and get yourself a key. It just so happens that some priests down near the barracks have the key. So you should be able to mug them for their key.

What I should have done - what I intended to do - was just have you auto-loot monsters the moment they die, jRPG style. That would have been simple, and would have only taken an hour or so to code up, since most of it was re-using pieces of code I already have working.

But no. I decided to take several hours to have the dying monsters drop a bag of loot, which has to be persistent (with a saved-game state and everything), had to be modeled, had to be added to the interactive object handler, and all that crud. Because I thought it would be cooler.

Sometimes I'm stupid that way.

So I wasted a couple of hours modeling and trying to texture (in my best 10-year-old-crayon-drawing manner) a bag (resulting in a "sad sack" as you can see in the screen shot), and then a few more hours working on the code that has the AI know what kind of goodies to put into the bag, and then drop the bag before they fade away on death.

Yeah, I have the enemies fade away when they die, mainly so the player doesn't end up with 20,000 polygons' worth of dead enemies hammering their frame rate after a few battles in a busy room.

About the only advantage over auto-looting at this point is that the bag of loot can be trapped. Since I'm a vicious bastard of a game designer (and a tabletop DM, just ask my players), I'm probably gonna take advantage of this little feature.

Anyway, after most of a day spent modeling, texturing, coding, and swearing, I got the bad guys dropping loot when they die. And I did a nice 2D icon of a key, and added it to the item data. Go me. That was a lot of work. I hope it was worth it.

The Exploding Lock
Okay, so now you have the key --- or not. Time to deal with a locked gate. My lock code and UI shares the code with the trap mini-game. So I created a "lock" trap type, and tested things out. I found some bugs that had crept into handling locks that had been created from me fixing the bugs in traps, and then failing to check that locks still worked. Not that locks ever fully worked. But eventually, I found myself picking the lock on the portcullis just fine. So I tried again.

And then the lock exploded.

Not that I took any damage. But the game informed me that it had "gone off." Kablooey. And then the portcullis was unlocked.

You see, when you fail at a trap, it is supposed to DO something. Activate. When you fail at a lock, it's supposed to... not do anything. The lock was acting like a trap. However, since locks have no "payloads," there was nothing there to damage me. But then the lock no longer existed. So the best way to pick a lock was to be completely inept at lock-picking.

That wouldn't do. So I had to fix a bunch of issues to tell locks that when THEY fail, they are supposed to ONLY kick the player out, reset their state, and do a wandering monster check. Once that was working, I also had to tell them to respond to a key in the player's inventory - having the key automatically unlocks the lock.

More Events, Triggers, and Scripts
My primary means of triggering events (thus far) has been trigger volumes in Torque. This requires the player to walk into the volume. I have had some special-case things for doors, chests, and other "interactive objects", but I realized that I needed things to be way more general purpose than they have been. So I went through and started adding more general-purpose event triggers on things like opening doors. So now, not only might a door be locked or trapped, but opening it may trigger something else happening in the game. Torque's robust scripting language lets you execute code anywhere - even on a string attribute of an object. I'm taking advantage of that as much as possible.

I worry that it's gonna be a nightmare to maintain down the road, though.

PUS!
So I was talking to James last night, who - with his newly repaired computer - is trying hard to catch up on lost time. He's trying to learn to straddle the gulf between high-poly modeling and low-poly (real-time) modeling. He has some questions about lighting and texturing for me.

"By the way," he says, "I have been looking up pictures of pus on the web all night for research for how the golem should be textured. Let me tell you how fun that has been."

"I'll bet," I respond. "So how's that coming along."

He proceeds to send me a link to picture of a really nasty, infected, festering sore. One that's not oozing pus so much as slowly pouring pus out of it, molasses-like. The sore itself is a deep, diseased hole, a nasty shade of red around the outside, and dark in the cavity behind where the pus is vacating with its creeping flow. The pus itself is a nasty yellowish color, with a couple of thin veins of red where blood has mixed with the ooze. "So," James asks, "Is this about the color you want for the golem?"

I'm feeling my dinner starting to protest inside my stomach. "Yes. Yes, that's perfect," I tell him. "But.... EW!!!!!!!!"

Incidentally, James is looking for a full-time 3D modeling / animation job, having recently graduated from a program teaching him the ins and outs of all this. So if you are looking to hire him away (and leave me in a lurch, but hey, I'll deal), contact me and I'll get him in touch with you.

Dealing With Schedule
So - as I mentioned up at the top, we're now officially behind schedule. The scary thing is, I'm not sure exactly how far behind schedule we really are. I believe we're only about ten days behind - bad, but not insurmountable. James is maybe a bit further than that, especially since I dumped some more work on him related to the first dungeon. Kevin's probably further along than any of us, but he's still got work to do before moving on.

So - when this happens, there are several options available:
#1 - Get more help (which can result, in programming, in making a late project even later if you wait too long to do this).
#2 - Reduce scope - get rid of some of the remaining tasks, or at least simplify them.
#3 - Figure out a way to make the process more efficient to speed up development
#4 - Buy some solutions that either do the work for you (a cheap equivalent to #1), or improve your process (#3)
#5 - Get schedule relief and the milestone moved.
#6 - Get everyone to expend more effort to get caught up.

I'm exploring all of the above options right now. #1 won't work for programming, but it could help in the writing / art departments. Writing is my favorite part, so I loathe the thought of relinquishing any of that to anybody, but it's a possibility. I need some more interiors, too, but a lot of that is for post-April. My main obstacle to #1 is having concrete tasks for everyone, rather than simply trying to throw some warm bodies at the problem.

#2 is a great choice, usually, but I'm keeping options open here for later.

I'm executing on #4 already. I'm buying a bunch of off-the-shelf stuff, with an eye for some of it getting replaced or modified as time goes on. I always say that the day job is there to finance Rampant Games, so I guess I'm putting my money where my mouth is. One thing I may have to do is swap out some of the monsters in my previous design with monsters from content packs that are already "completed" (albeit in need of some customization to make them match the style of the rest of the game).

Since we're in the MyDreamRPG competition, I really can't do anything about #5. And as far as #6 is concerned. I'm trying to discipline myself to get more done each evening. I don't know how overworked my team-mates are, and though I can wave a little bit of a carrot, they are volunteers. I take what I can get. What I need to do better is to keep them all up-to-date on what's happening with the game. When you have people motivated by the game itself, the best motivation is to see everyone else working, making progress, and seeing the game take shape. That is EXCITING. When I talk with them and see what kinda awesome stuff they come up with, I get even more excited to dive back into the breach, guns a-blazing.

Immediate Goals
This weekend, my principle goal is to get the "primary path" through the dungeon complete - all scripts, rewards, etc. I'm actually very, very close. There's some complications at the end involving checks for reinforcements in the boss battle (if you haven't nailed the priests behind you, they will join the battle and make life much harder on you. And I need to make sure the player is adequately warned of this possibility before they charge into the now-even-cooler main temple room that Kevin has been laboring to make look uber-cool:


And then I'm going to work on the village or Ardin, since I need to get it completed by the end of January. I will be using a lot of off-the-shelf models and textures for Ardin, so I hope that it can be completed with little impact on the rest of my team, so they can continue to work on the dungeon and the wilderness content (which needs to be completed by the end of February).

Did I ever mention that game development isn't pretty? Times like this, it looks messy indeed. At least the dungeon is looking pretty sharp.


(Vaguely) related hoody-hoos:
* Frayed Knights: Frantic Dungeoneering
* Frayed Knights: Twisty Paths and Flickering Torchlight
* Frayed Knights: Learning the Lingo
* RPG Design: Big World, Small Dungeon - Does Size Matter in RPGs?

Wanna Talk About It? We've Got a Forum Thread and Everything!

Labels: Frayed Knights, Roleplaying Games

- posted by The Rampant Coyote @ 4:54 AM (Permalink)