Frayed Knights - Meet Thrump
This is Thrump.

The name isn't actually short for anything. It's just his name. At least, the name he tells people. I personally think he's Conan's younger, better-looking brother. He doesn't say a whole lot. He's kinda the strong, silent type.

Thrump is sort of Arianna's counterpart (and opposite) for the rival group of adventurers active in the Ardin area, the Heroes of Bastionne. The ones who beat the Frayed Knights to the eyes in Pokmor Xang pilot, for those who have played it. At least on the surface, he seems to be the warrior stereotype that Arianna is constantly fighting against.

Thrump is a follower. Arianna is a leader.

Thrump is massive and musclebound. Arianna is ... not.

Thrump holds his tongue and his temper. Arianna's anger management issues are legendary.

Thrump is physically intimidating. Arianna makes up for volume what she lacks in presence.

Thrump is a respected up-and-comer in the adventurer community. Arianna still draws snickers from those who know of her first independent mercenary stint where she was hired to escort a manure cart... and failed.

Reconstructing Ardin

I'm still working on Ardin right now. The original version of Ardin from the pilot was more of a rough draft intended for future expansion. While the village itself isn't a hotbed of adventure and intrigue as the two other small towns in Frayed Knights, there are still a lot of things going on that weren't even hinted at in the pilot.

So I've been shuffling things around, adding / creating new buildings, like my half-finished three-story tudor-style house there in the screenshot. The village also needs a focal point, besides the river. And then there's the various people in the community, and on the outskirts, with rumors, quests, hints, shops, and stuff to do.

The idea is that Ardin is something of a boom-town. Adventurers have come here on rumors of excitement and treasure. And they bring money with them. The villagers - old and new - are cashing in. So they've got a brand new (and I should add, totally rockin') inn, and some other new construction going on (hmmm.... I should probably create one or two half-finished buildings under construction, shouldn't I?). Some of the long-term residents resent the sudden appearance of adventurers, but it's still new enough that many - particularly younger citizens - find it fresh and exciting.

As far as the shops (well, *a* shop right now) are concerned, they are kinda-sorta working, though I'm still dealing with some design issues. Like what happens to items after you sell them. But the new interface, like the rest of the inventory system, is drag-and-drop. As much effort as it took to get things functional (and prevent bugs, like items getting perma-stuck under your cursor), there's just not much sexy to talk about a merchant trade interface. I ended up going far more traditional than I thought I would, just for the sake of my own sanity.

Merchant snark is still 100% free, though.

Another issue with Ardin was the invisible walls from the pilot. Everybody - myself included - hates invisible walls. Even when I know there's absolutely nothing for me to see out there. So - if nothing else - I'm at least making the walls visible kinda visible. So long as there is some consistency in knowing that you can't go up or down steep cliffs (and I will need to mark said faces with a texture that makes it clear it's not passible) or across rivers or so forth, that should resolve most issues.

Beyond that, when you go far enough (or hit the right point on the road, or whatever), you get a quick-travel menu asking where you want to go. Any area you have either visited before or heard about (via a quest or whatever) is available on the menu for travel. This won't happen the first "day" (the timeframe seen in the pilot) - as you really only have two places to visit (if you are in the one, you will only travel to the other). But after that, things start opening up, and you shouldn't have to walk far before being able to travel quickly to anywhere else in the game.

And - hey - BONUS! This opens up chances for secret locations that have to be discovered via conversations, reading old texts, etc. I'm not sure I'll be able to exploit that capability very well with the limited time I have available, but that would make for easy expansion and downloadable content later, wouldn't it?

Edit: Thank you, Ian, for pointing out that the previous name was taken. I wanted a misspelled onomatopoeia that suggested a beefy warrior-type. :)

Labels: Frayed Knights

- posted by The Rampant Coyote @ 10:29 AM (Permalink) 1 comments links to this post

 
Frayed Knights: Heroes of Bastionne
It's time for another installment of the seemingly never-ending saga of the development of Frayed Knights, the indie RPG that refuses to take itself too seriously.

Cold Medicine and Dungeon Building Don't Mix

I only have a cold. I say "only" because, although it's the nastiest one I've endured in about three years, it's not the swine flu, which our neighbors down the road have. The ones with the son who is in the Junior High carpool with my daughter. Yeah, exposure potential there. Terrific. I'll count my blessings.

But a lot of building and testing (repeat, repeat...) of game levels for Frayed Knights while under the influence of both a cold and cold medication can have a strange effect. When followed by brief snatches of medication-encouraged slumber, things get... weird. Really weird.

I found myself walking (or floating) down the same corridors I'd been building (and testing, etc) in my dream. There was no escape. There was always something just not right about it, though I could never exactly put my finger on it. Over and over I'd pace the corridor in some kind of brain-loop.

So now I have a freakin' dungeon that haunts my nightmares. Great. It's not even that impressive of a corridor - there's nothing complicated about it. I may have to put some really weird encounter in there to commemorate the dream-loop I had about it.

Fear not, I will be raising the ambient levels a bit above what you see in the screen capture. I just turned everything down to see the other lights better.

Right before coming down with this happy little plague, I'd decided to completely overhaul the Tower of Almost Certain Death. I wasn't happy with what I'd done before, and it was getting hard to maintain. The tower itself was too dinky, for one thing. Adding the larger underground section helped, adding about twelve rooms to the total, but something had to be done about the tower itself. All told, the tower is a bit larger than the Temple of Pokmor Xang, clocking in at about double the number of rooms (depending upon your definition of "room").

In fitting with the Frayed Knights universe, the tower itself is only a small part of the actual structure. By room-count, it still dominates, but at least half the square-footage is underground. The wizard who built the tower wasn't quite so worried about its vulnerability to aerial attack as its convenience, but it has a traditional underground bolt-hole. Plus, the underground complex was a place to billet his guards and drudge-servants where they wouldn't stink up the place. And finally, the underground area housed one of his greatest - and most successful - experiments.

One which has now been found, and controlled by the forces of evil. Duh. You leave anything laying around like that, you just KNOW some dark overlord or something is going to take advantage of it.

The Heroes of Bastionne

Polly has been feverishly working on the rival group for the Frayed Knights - the Heroes of Bastionne. You met one of them (kinda) in the pilot - Florentine. She's getting a complete overhaul as well. New graphics, new everything. Except her attitude. That stays.

The artwork style doesn't quite match that of Shawn Boyle's drawings for the main characters, but nothing's gonna exactly match that - not even the game world itself. Though I will keep trying to make some changes to make things a little more compatible. But ultimately, the main characters are probably just gonna end up standing out a little bit from the rest of the world. That's true on several levels, so I think that's okay.

The Heroes of Bastionne are designed to be in many ways the opposites of the Frayed Knights. Florentine, their leader, is the cleric - Benjamin's counterpart. Where he's a tree-hugging nature priest who only reluctantly engages in the violence that is the adventurer's lot, Florentine is a priestess of the goddess of battle. Benjamin is the newbie on the team who isn't quite sure what's going on half the time. Florentine is the group leader, and has the most experience of them all. Benjamin is a little naive and bumbling, but Florentine at least projects the aura of being ultra-competent. Benjamin is kind-hearted, and will push to do what's right in spite of the potential for his own detriment (note that he's the one who lobbies to free the "prisoner" in the temple). Florentine is cold, calculating, and ruthless.

Oh, and Florentine is fiercely loyal to her team... and Benjamin (inadvertantly) betrays his own...

Yeah, but guess which team ends up saving the kingdom?

Labels: Frayed Knights

- posted by The Rampant Coyote @ 5:07 AM (Permalink) 5 comments links to this post

 
RPG Design: Somebody Call the Dungeon Architect!
You know, it was a lot easier back in the 80's when I was just making dungeons with pencil and graph paper.

Back in '88 or so, I was at a science fiction and fantasy symposium with Tracy Hickman, co-author of the Dragonlance novels (among many others), as well as the famed Ravenloft module for Dungeons & Dragons. He gave a few talks both on writing and publishing, and on role-playing games. Though he's nowhere close to being my favorite author, his comments were very valuable and enlightening.

Among his many topics, he talked about creating maps for the players. He said, "Have you ever tried to actually to envision or model one of the maps from the earlier modules in 3D? Like any of the castles? If you do, one thing you'll discover very quickly is that they are dumpy! Very squat and flat. That's not very realistic."

Apparently, that was part of his goal with Ravenloft, which includes a very tall castle with a lot of use of vertical space. "If you want to confuse your players," he explained, "give them a lot of vertical movement. They'll inevitably get mapping errors, and become convinced that they've run into some kind of teleport trap because nothing is lining up right."

That's mainly because the maps were done on plain ol' graph paper, encouraging a very flat, top-down design. In fact, the use of vertical movement was such a special case that in the early editions of dice & paper Dungeons & Dragons, difficulty (and treasure) was based almost entirely on how many stairs you had descended - your "dungeon level."

The CRPGs I fell in love with in the early days of the hobby often used a player-eye (or mouse-eye?) perspective of dungeon maps in sort of a fake 3D view. Not too unlike the perspective indie RPG Cute Knight Deluxe offers. But again, the dungeons were flat maps in 2D space. Stairways, ladders, pits, and so forth were simply objects that appeared that took you to different levels. The encounters generally became a little harder with each level you descended. Just like old-school D&D. Even the Ultima series, with it's top-down perspective through much of the world, used the mouse-eye view of the flat dungeon levels (of which, if I recall correctly, there were exactly 8 for each dungeon in Ultima III and IV).

Now we move to the modern era, where it almost as easy to render a dungeon in "true" 3D as it is to render those old 2D mouse-eye views. In fact, indie RPG Devil Whiskey limits movement and view to the four cardinal directions as these old-school games (it is heavily inspired by the original Bard's Tale games), but renders the view in true 3D. Ditto for the now-defunct Dungeon Maker engine. That's certainly an option. And there are some nifty things you can do with modern 3D rendering that faking it in the 2D world couldn't offer to make the world look better, including escaping the old 10' x 10' block and 90-degree turn restrictions of the older games.

But when you can really take advantage of the vertical element with 3D views and realistic architecture (and lighting, bump-mapping, or whatever else sounds good), it kinda feels like a waste to wander around a "dumpy", mostly flat world. Things that looked cool on graph paper may not translate to excitement on the game's screen.

Old-school RPG editors (Bard's Tale Construction Set, Forgotten Realms Unlimited Adventures, etc.) were pretty close to what you see with Dungeon Crafter. Fill in the floors, set the doors and walls, and away you go. Yeah, you didn't have many choices to deal with, but it was fast. But good luck figuring out a way to make these maps interesting. There's only so much you can do with flat levels of 10' x 10' squares.

So now we have all kinds of power to make virtually anything we can imagine within the constraints of the engine and the target computer's ability to render your ideas in real-time. But with this flexibility comes vastly increased complexity - by an exponential factor. Sure, you can impose some constraints on your design to speed creation time - I've got some "tiles" under construction right now which I'm going to be using to speed development of some areas. But disposing of the old, simple graph-paper grid can make things like just making sure floors and walls line up properly kinda tricky. Because, of course, sometimes you may not want them to line up. With all those options means lots of choices, and more complicated tools to accomodate those choices.

One issue I've run into in the development of Frayed Knights is lighting. Really cool lighting covers a multitude of sins, I've learned. But, with the engine I'm using, lighting can be really nice and really cheap, but it's also pretty finicky thing. The human brain relies heavily upon light, and so realistic lighting gives us all kinds of signals that help us make-believe that a picture on little flat-screen monitor is actually a window into another world. But squirrely lighting jars us out of that illusion just as easily, and causes frustration because things don't behave the way they look like they should. And then of course, there are problems with a level being too dark, too bright and washed out, or... both, as in the picture to the right. (That's all stand-in texturing, I should note... as are all the Frayed Knights pictures in this post. We're trying to crank along on geometry right now.)

Finding and fixing lighting bugs can also be a major chore. Texturing is another one. I'm not even gonna go there - entire books have been devoted to that subject.

Yet another challenge is more basic - how do you make a good 3D gaming environment? One book I own, "Beginning Game Level Design," suggests picking up some textbooks on architecture. Knowledge of architecture, set design, interior decoration, and 2D art composition skills are just as important here as game design, creativity, and technical competency with tools. In many ways, the design task is closer to that of a theatrical or cinematic set designer, as the builder not only has to satisfy the demands of style and function for the fictional creators of the environment, but also satisfy the aesthetics of the game and the demands of the mechanics.

Additionally, those really cool, visually appealing environments can play hell with the AI pathfinding and successful player navigation.

Regardless of technology, for the kind of RPG I'm interested in (and interested in making), these environments need to satisfy several requirements:

#1 - Exploration is a big deal in RPGs, so a good "level" should provide an interesting environment to explore. It should provide hints for interesting things to come. A good dungeon level should promise hidden secrets, give you glimpses of currently unattainable goals, and something new and different as you progress.

#2 - Since combat provides the meat of most RPG gameplay, the environment should provide some interesting tactical challenges - if that is a feature of the game.

#3 - A dungeon level should provide some interesting spatial/navigational puzzles. This is more appropriate for 3D environments with restricted vertical movement, but even the old dice-and-paper games had things like notorious chessboard floors and similar puzzles or "tricks" involving navigating the environment.

#4 - A good dungeon level should be visually appealing. Easier said than done, sometimes. This comes from a combination of interesting geometry, good texturing, and lighting. It should at least look plausible given the constraints of the world. Huge, flat ceilings without arches or supports look wrong. Stark transitions between material types can look bad. Bad color combinations look bad. Too much repetition of texture looks bad. Too much contrast looks bad. Too little contrast looks bad. There are probably a zillion other things that detract from the looks of things, and I won't even recognize them when I see them.

There may be a lot more science to it than I understand. There is a lot to it. So much, that it gets a little intimidating for a guy like me, for whom the term "programmer art" is something of a compliment. Nevertheless, there's something incredibly satisfying about learning to go from the old graph paper maps of my childhood to making 3D dungeons in my... um, later childhood.

(Images come from Frayed Knights, Might & Magic 1, and Wishbone's Dungeon Maker alpha version)

Labels: Frayed Knights, game art, Game Design, Roleplaying Games

- posted by The Rampant Coyote @ 7:14 AM (Permalink) 3 comments links to this post

 
Frayed Knights - Not Giving You the Time of Day
Because you demanded it - well, okay, you didn't. But because someone somewhere might be remotely curious... Wait, that doesn't sound quite right either. Okay - because I said I would, in spite of the complaints and angry pitchfork-and-torch-wielding townspeople - here's another installment in the continuing saga of the development of Frayed Knights, the comedic indie role-playing game (RPG).

When Last We Left Our Intrepid Adventurers...

This week, I focused on "The next five minutes." Not minutes 6-10 of the game, because that's already been covered (if subject to some changes) in the pilot. No, I wanted to focus on what happens in the next five (to fifteen) minutes of the game after the pilot ends.

If you remember, the pilot ends with Benjamin leaving the Frayed Knights in shame (and under threat of bodily harm) after it was discovered that he'd revealed their quest information to the leader of a rival adventuring group - Florentine - while in bed with her a couple of nights earlier. As a result, her team - the Heroes of Bastionne - had beaten the Frayed Knights to the punch, taken the prize, and used it to get into the good graces of the local member of the Adventurer's Guild.

Loose lips sink ships. And sink chances of getting a coveted membership in the Adventurer's Guild.

The pilot episode (which is going to remain in the full game in pretty much the same piece - enhanced, updated, improved, but not fundamentally altered) is somewhat constrained and a little more linear than I'm generally trying to go for. The next morning things open up a bit more. Shops are open, more people are about, and opportunities open up for more exploration.

This means a lot of work for me.

(Not) Giving You the Time of Day

One thing which I wanted to experiment with was changing the time-of-day. Now, I'm using the Torque Game Engine, which has some pretty nice lighting, but it comes at a cost - it relies heavily upon "static lighting" which it can pre-calculate in a lighting pass in advance. This is time consuming, and it caches the results so that future lighting passes take less time.

I spent a bit of time this week working on a dynamic time-of-day system, which unfortunately has a lot of ugly side-effects. For one thing, it breaks the lighting cache, so that it means we always have to relight all the time to make sure we've got things lit properly for whatever time-of-day you are entering the world. And it is time-consuming. Annoyingly so. Especially as the scenes and towns get more complex (as Ardin is about to...) .

So I'm looking for an alternative. This probably means having duplicate versions of areas -- one for daytime, one for nighttime -- which is going to be quite problematic, especially for setting up triggers and events based on area geography and my existing flag / event record system. There may be other solutions as well that might not look as good. Or I may have to fall back on not having time-of-day - which would suck. Because I'd hate to lose this:

Ardin By Day

Ardin By Night

Kicking Ben Out of the Party

So Benjamin was kicked out of the party at the end of the pilot. I didn't actually boot him from the party roster at this point, because there were more important things to worry about at the time (like getting the save-game working).

However, because the party roster WILL change a little as the game progresses, and because the player could probably use the ability to change party order around as things change, I implemented that this week. So the next day begins with Sir Benjamin NOT appearing in this party - he shows up as an NPC (non-player character).

Once again, I was impressed with how much flexibility I'd placed in my system to allow this, as well as by how much additional work I still had to do to make this happen properly. I had to create a "reserve party" to compliment the "active party," and a mechanism to switch between the two. The reserve party must also be saved with the save game - you don't want to lose a character's stats and updates in-between sessions, if they may be rejoining the party later, right?

This isn't to say that the Frayed Knights are going to have a revolving door policy on membership. Or that the world will be filled with recruitable NPCs. Since Frayed Knights has an emphasis on character and dialog, I have to keep pretty close tabs on the party. (This is part of why characters are "incapacitated" rather than killed or unconscious - I want them still able to talk! As a side benefit, it makes torture much more convenient...)

In addition, I added some other tweaks - like having speaker-less text in dialogs. And flagging it as an "aside" - an aspect of dialog that I have never used and I may never use outside of speaker-less text. The idea was that if party members are talking to each other without the other characters hearing what they were saying, this would be noted by a different color of background. In practice, I'm not sure it matters. But I like having expository text for the player.

The Big Event!

One major advantage of using Torque is the scripting system. While it can be amazingly frustrating to work with sometimes, it's also amazingly powerful. I mean, you can stick a script anywhere and execute it. I would go so far as to say it's moderately more powerful than the system in Neverwinter Nights. A lot more powerful, if you consider the ability for me to go into the source code and add even more functionality to the engine that can be accessed by scripts.

But - it's not all "hugs and puppies." There is a lot of framework in place for triggering recurring, non-saved-state events based on what is assumed to be a pretty static environment . TGE was optimized for first-person shooters, after all. Heavily conditional triggers based on sequences of other events firing don't have a lot of built-in support. Keeping track of humongously complex RPG states across saved games has virtually nothing built-in to help. So any support for this sort of thing is a do-it-yourself opportunity, which makes it a little harder to make some of the cool, complex behaviors and events like I used to do in Neverwinter Nights (which had it's own problems, as well).

Nevermind my willingness to kill for access to the amount of customizeable content I had in Neverwinter Nights, too...

Besides creating that level of support for myself (a bunch of "black triangle" work, some of which has been thankfully bearing fruit now), I've been going through a bunch of old RPG walkthroughs analyzing their quest and event structure for research. These games had fairly simple quest / event structures as well, and the designers managed some pretty cool things with very simple tools. They also managed to create some pretty amazing bugs, too, which is not anything I am immune to. But it has pretty helpful both to organize my thoughts and come up with some neat ideas, while avoiding absurd levels of complexity that I might otherwise saddle myself with.

Well, that's it for now. Time for me to hit the ol' dungeon again... meaning I have to build it. The Tower of Almost Certain Death is getting a new basement level, because it was just too small as a tower.

Later!

Labels: Frayed Knights, programming

- posted by The Rampant Coyote @ 4:45 AM (Permalink) 7 comments links to this post

 
Frayed Knights: Making Buttons Click Is Not Much Fun
And now - the continuing saga of Frayed Knights, an indie RPG in development here at Rampant Games.

Motivation is a tricky thing.

It's easy to get motivated when working on a game if there's a steady paycheck involved, or if you are working on some really cool parts, or if it's the beginning of a project and things are coming together quickly.

On the other hand, when it comes to working on user interface code in my so-called "spare time" to make a friendlier version of inventory management (something inherently boring in its own right), it can be a problem. Sometimes all you can do is just keep an eye on the goal, and power through it. I was working on this before, but I put it on the shelf for a bit for the sake of my own sanity. But I had to get back to it sooner or later.

But I now have a somewhat more functional and user-friendly inventory management screen. Inventory management is already a pretty boring subject in its own right, and layering a bunch of boring UI development over top of it is a recipe for curing insomnia. But now we've got the ability to drag 'n drop, nicely animated scrolling between pages of ... you know, stuff... and... gah. Man. I can't even talk about it anymore. Moving on...

The Vampire Village: Under New Management

Oh, Mournhold. Califer (Curtis) politely informed me that Mournhold was a major city in an expansion in The Elder Scrolls III: Morrowind. An expansion I even own, though I don't think I ever went there. Since the cool name is taken, I have to come up with a different cool name. I have a notebook with some brainstorming I did to come up with the first name, but I'm not thrilled with any of the other ones. Anybody got cool suggestions? You guys kicked butt on coming up with spell names last time...

This town remains in development, though we're broadening things a bit to try and get as much of the game "finished" as possible. I've also been working on the silver mines. The silver mines will not be nearly as cool as the castle or the the Temple of Pokmor Xang. I'm experimenting with creating pre-fab "tiles" for the mines to generate a lot of geometry in a hurry and then "fill it in" with details to hide the repetativeness. I promised Verious that I'd post some technical details about the tools I'm using and my workflow (such as it is), so 'll post more about that next time.

Polly's been working on character concept art. This is Tema. She's Victor the Vampire's main squeeze in the township-formerly-known-as-Mournhold. She has a relatively small but critical role in the unfolding events of this chapter. We were looking for something like an undead Tina Turner look, with a harder edge, and I think it worked. She's not as sweet and friendly as Victor, I'm afraid. She's still a party animal, and enjoys the local night life, but there's an entire forest filled with the undead victims of her late-night escapades.

Victor is normally a calming influence on her, but she is no longer in residence at the above castle. Her current whereabouts are a mystery.

Aw, Rats!
Kevin and I are back to work on ... uh, a rat-farm. A farmhouse filled with rats. It's sorta what happens when there aren't any adventurers around to deal with the local farmers' rat problem. There's a reason why there are all these quests to kill ten rats and bring back their tails or whatnot. These things - if left unchecked - will eventually take over the world.

It's a setup for a Chapter 2 quest involving the temple of the rat god. Yeah, in this game, you get to raid a lot of temples. A pimple god, a rat god... I may have to throw in a god of hangnails or bedbugs or something while I'm at it.

Goals for the Week
My focus this week, now that the the improved interface screen is (mostly) working, is to avoid working on any user interface issues. How's that for a goal?

I'm going to be cranking along back on Chapter 1, starting with the events of "the next morning" after the big argument between Benjamin and the rest of the party. This is the point where the game opens up a bit more, and we get some good ol' non-linear gameplay action going. There's a ton of interior work and modeling - even to get to a lame white-box stage - that ought to keep me more than busy enough!

Labels: Frayed Knights

- posted by The Rampant Coyote @ 5:22 AM (Permalink) 8 comments links to this post

 
Frayed Knights: Breaking Windows
And here's the latest update on the development of Frayed Knights, an indie computer role-playing game with a significantly tongue-in-cheek approach.

24 Hours of Crunch

I took Thursday off from The Day Job to get Frayed Knights ready to show for the Indie Game night that night. While it wasn't exactly a marathon 24-hour stretch of game development, it came pretty close. And it was, surprisingly, awesome.

I'm not sure which was more impressive: How much I got done in that 24 hours compared to the average *two weeks* of development time, or how little I got done compared to my expectations. So I guess on the whole, it was "satisfactory." But it was awesome to be "in the zone" so much on the game, focused on development. I noticed something strange when I got home that night, too. You'd think I'd be totally sick of working on it by then, but all I really wanted to do was to jump back into development. I then realized something important that I'd kinda forgotten over the last few months:

This game is fun.

Not just playing it, but I really enjoy working on it. In spite of beating my head against the wall trying to make stuff work that used to work and then quit for apparently no good reason. In spite of the pain, the frustration, and the realization that it's NEVER going to be as good or as polished or as epic or as mind-blowing or as successful as I hope. It's okay. I love doing this stuff. It's fun. It's exciting. It's challenging in a good way. Maybe the 24-hour code-a-thon or showing it to people again did something to warp my brain, but things started clicking again.

Additions and Changes...

Another thing I was reminded about this week was why I chose Torque in the first place. One spell I've been very excited to implement was "Power Word: Defenestrate." If you know what Defenestrate means, well, you know what the spell is about. For the visual, I decided to have a window magically appear, and then the enemy would be thrown through it, shattering it, and taking damage. Then the window frame would disappear.

Anyway - while it didn't turn out quite as well on the screen as it did in my head (mainly because I really didn't want to animate dozens of pieces of glass, so I faked it with a particle system), it was incredibly easy to implement, thanks to the engine. I just had to create the model, animate it, and give it a mount point. Then, for casting the spell, I mount the victim to the window's mount point, and let the animation run. I still have to trigger the explosion of glass manually (it's a little bit premature, as you can see in the screenshot), and then I have to unmount the victim before deleting the spell's visual - but it was all handled nicely through the animation system. No fuss, no muss.

Now if I had a really good animator working for me, this would be a great time-saver. But even for just lil' old me, it's helpful and makes things easier to work with.

For the demo, we added Castle Mournhold and part of the surrounding area, three monsters, several new spells, faked the leveling-up of the party to 12th level, some new dialogs and encounters, and some overall code-cleanup and fixing of bugs that have managed to embed themselves over the last several months.

What Mournhold Taught Me

Working on a latter part of the game, in "new territory" that wasn't an extension of the Pokmor Xang pilot, was a great experience for me. It really helped make me aware of several issues that I need to address for the game as a whole.

One of the unfortunately discoveries I made, once we managed to get the level playable, was that I'd really made the area too big. There was too much walking around with nothing to do - especially getting to the vampire's castle. Not good. So I'm left with a choice to try and pack more stuff into the area, or shrink the map. I'm opting - right now - to shrink the map, but I'll pack more stuff in where I can.

Mike Rubin noted at Indie Night that while I definitely favor more open-ended RPGs, the direction of what he saw in Frayed Knights was more linear. This was not an unfair assessment, and it's something I'm working on. My constraints as far as storytelling and limited content really work against me in this respect. It didn't bug me too much with Pokmor Xang, as the "bunny slope" dungeon is supposed to provide a bit more guidance as players learn the system. But the game is supposed to open up more beyond this point, and I'm recognizing that I really need to put some more effort into making this work.

Balance issues at the higher-end of the game also prompted me to revise the combat system (again), which now needs to be tested across all levels of play. Of course, we don't have all levels of play yet in, which is another issue. There are a lot of new feats and spells and powers and items at higher level that I'm not positive will work quite right. These all need to be put in the game, tested across multiple levels, and balanced ASAP.

I'm also running into things that looked great on paper, but once I have translated them onto the screen and made them interactive, I'm discovering big gaping holes in my plans.

Because of this, I'm going to be putting a bit more emphasis on rapidly prototyping the remainder of the game, rather than concentrating on specific parts as much as I have been. This will mean a lot of ugly, unfinished-looking white-boxed dungeons and stand-in monsters with generic special effects for a while. I won't be doing this exclusively - I'll still take some time out to bring parts of the game to a more alpha-ready state - but I think this will help take the game "over the hump."

Labels: Frayed Knights, Game Design

- posted by The Rampant Coyote @ 6:39 AM (Permalink) 13 comments links to this post

 
Spell Name Idea...
Umm... I wouldn't want to post this here, but with tomorrow's deadline looming I wanted to call attention to it in a hurry. (Yes it can change after tomorrow, but I could use the ideas):

I need a good spell name

Any ideas?

UPDATE: Wow. Great response - and fast, too! You guys RAWK!!!!! I think we may have a winner, though I also have some awesome names that I probably need to invent spells to go with....

Labels: Frayed Knights

- posted by The Rampant Coyote @ 1:43 PM (Permalink) 7 comments links to this post

 
Frayed Knights: Bumping Off the Cart-Man
Of all the updates on the development of Frayed Knights, the indie comedic fantasy computer RPG, this one is sure to prove, for a time, to be the latest.

This chapter is opening up with a murder mystery. Well, a death, under vaguely mysterious causes. "Okay," you might say, "I already know that is a vampire story. We've already read / seen / heard the Dracula story a zillion times in different forms. The vampire caused the mysterious deaths. Is this any different?"

Well, yes and no.

In this case, it's a wagon that went over a cliff. No visible bite marks on the victim. He's got a broken neck, crushed chest, but no bite marks.

And back in town, nobody seems to know the victim. So did he fall before arriving?

He was undoubtedly a hardy, competent fellow - nobody braves these roads unless they know how to handle the wolves. And animated skeletons of an invading army that was wiped out in a single night twenty years ago...

Based on the feedback I've received from people about Frayed Knights, the dialogs between the characters was - stunningly (for me) - very well received, with the biggest complaint being that there wasn't enough of it. Yes, this complaint greatly outweighed the complaints that the dialogs were dry, boring, and un-funny. I guess this is to be expected - anybody who volunteers to be a guinea pig for a pre-alpha test of a game probably has some kind of masochist streak running through them, so AFAIK both criticisms are probably perfectly valid.

Nevertheless, I'm trying to add Yet More Dialog to the game. This also works to help focus my design --- more dialog means packing the areas with More Interesting Things for the party to talk about, interact with, and to dilly-dally with instead of pursuing the primary plotline. Just like my dice & paper games...

The "Defend" option in combat is getting changed to be the "Special Ability" / Feat button. Defend is an ability that all characters will have, but the rest are based on their starting class and the abilities they choose when leveling up.

Polly, our new concept artist, has been working on sketches for Victor the Vampire's Significant Other, as well as the Burgomeister. The black & white sketches are looking pretty awesome.

Thursday night is Demo Night - I'm planning on showing off the game to the Utah Indie Night crowd at the NinjaBee offices. I've scheduled to take Thursday off of the Day Job to help make sure I've got everything as ready as I can get it. We're not anywhere near where I'd hoped we'd be (and for "we" I mostly mean "me"), so I'm a little disappointed and frustrated on that front. But we have some new monsters, new spells, a new environment, and part of the new chapter to show people, so at least it won't be a retread of the Temple of Pokmor Xang.

Labels: Frayed Knights

- posted by The Rampant Coyote @ 7:14 AM (Permalink) 4 comments links to this post

 
Frayed Knights: Speedy Feats...
Some quick and dirty updating on Frayed Knights, the comedic indie RPG in development at Rampant Games...

I am sleep deprived. And frustrated.

This has been a really busy couple of weeks for me working on the game, but I'm afraid I have little to show for it. The needs of the higher-level game required me to (finally) overhaul the combat system, and it has been a doozy. From the player interface perspective, not a whole lot has changed yet (which is sure to annoy some). The core of the experience isn't too different, but everything behaves in a much more orderly fashion. Things progress more smoothly within the combat sequence from event to event, which makes it a lot easier to manage from a programming side. Things were just getting out of control - both from a programmer, and as a player trying to make sense of the action.

But that's the interface side. On the underlying mechanics side, the high-level game was also getting out of control. Balancing things was getting insane. So I chose the better part of valor and wussed out. Things are a lot more "level-based" in the game now than I originally intended, but frankly I didn't see a clear path out of this without a serious round of simplification. There were basically too many moving parts in the underlying rules system, and as I deduced from literally hundreds of feedback forms, nobody was really clear how things were working under the hood anyway. It didn't make a difference to anybody. So I replaced some of the more "simulation-esque" rules for simpler, more game-y rules.

As an example - weapon damage and hit points. Based on some misplaced desire for a more simulationist approach to combat, I had hit points scale very little based on level. It was a much more slow progression. Likewise, weapons didn't scale drastically with damage done based on level. After all - why would a bigger, more ornate axe really do more damage than a plain old sharp, workhorse battle-axe? No, I reasoned, instead it would be more of a case of character skills reducing the likelihood of getting hit, and reducing the seriousness of the wounds. That's more realistic, right?

And it's more boring. It's not as fun to see the damage numbers going DOWN as your character becomes higher level!

And I had this really complicated equation for weapon damage based on the minimum strength needed to wield the weapon effectively, the weapon's base damage, the strength of the wielder, and so forth. How much did it add to the game? Very little. I am still keeping the special damage effects of blunt versus piercing versus edged weaponry, but I have simplified weapon damage so that it is... may the gods of RPGs forgive me... more based on relative level and class.

So if you are a big fighter with a big level and a big sword and big strength, you will do Really Big Numbers against a low-level opponent. Just like those JRPGs. Except probably without three-digit and four-digit damage numbers.

Another thing I have had to do is add a bunch of higher-level feats for the party (and their enemies). While they aren't all fully implemented yet, here's a subset of a bunch of new special abilities characters can acquire as they level up. Right now, I have a "default" level-up list for the four main characters from this list to speed things up, but the player will have a choice of an attribute raise or a new "feat" every level:

Lunge: Character can make extended-reach attacks with fewer penalties
Rank Smack: Character can attack an entire rank at once with a melee weapon
Guard: Character can protect one other character. Sometimes.
Counter: Character has a chance of immediately counter-attacking on a missed melee attack against them.
Hangfire Reaction: Character has a better chance of dodging a trap on a failed disarm.
Spell Homing: Single-target spells more likely to hit.
Healer At Heart: Character's healing spells are more effective.
Spell Volley: Spells can be repeated in less time.
Counterspell: Character can attempt to cancel inbound enemy spells.
Improved Counterspell: Character is very impressive with countering enemy spells.
Spell Reflection: Character has a chance of reversing countered spells back upon the original caster.

I probably need to come up with more amusing names for all of 'em. I like "Rank Smack," but it's hard to figure out what it really does. Maybe "Multi-Smack" would work better. I also need more "active" feats. Getting a bonus under a certain circumstance is all well and good, but again - the fun factor comes from being able to do something new. And cool. Maybe I should just name the feats, "Do Something Cool 1" and "Do Something Cool 2" and so on...

And then I have been fixing a ton of bugs which have cropped up - often unnoticed - in the last few months of development. My MessageVector code is no longer working - for some reason, the friggin' dialog has mysteriously vanished. It's still there, and it thinks its visible --- it's just not displaying. How long has that been happening, I wonder? How much more time am I going to be spending fixing things that were once working? There are other special effects that are no longer firing --- animations that aren't running ---- and junk like that.

Three steps forward, two steps back.

The townspeople (since the new chapter just about STARTS in a town) are another struggle. I need a lot of them. I'd prefer them to not all look alike. What I need is something kinda like this or this - but less cartoony than the first one, more feature-rich and expandable than the second, and with female characters too. Preferably with Blender support (I've always had a problem importing animations into Blender) for expansion.

I really hope things come together quickly. This coming weekend is going to be the "big push" for indie game night. Hopefully, with all the bug fixes, it at least won't be LESS functional than the pilot version!

Labels: Frayed Knights

- posted by The Rampant Coyote @ 8:55 AM (Permalink) 7 comments links to this post

 
Frayed Knights: Nuke the Town?
A couple of weeks ago, I received an email from Ruber Eaglenest, AKA El Clérigo Urbatain, with a very interesting suggestion. In a nutshell - his suggestion was to get rid of the towns, and any of the other space "between missions." All the narrative could be done with non-interactive cutscenes, and shopping could likewise be handled between missions.

He admitted that the town in the demo was rough, but expressed concern that the town added very little to the gameplay, and instead sucked development resources that could be better put into the dungeon adventuring. He also noted - very rightfully - that the limitations of 3D require a level of sparseness in the town layout, which means a lot of empty, open space. Which is boring. "The town doesn't add anything to the narrative that you could accomplish with traditional approaches. And I, like a player, just want be from mission to mission without so much waste of time in town."

Rather than just email him back with my response, I thought I'd respond here. Because he brings up a very good point. Not that I necessarily agree with him, but I think he's spot on in that the decision to the contrary demands justification.

Kivi's Underworld kinda takes this approach. Leveling up and narrative take place in a simple interface in-between missions, which are the focus of the game. There are definitely trade-offs here. On the positive side, as Ruber suggests, it keeps the emphasis on the fun part of the game. But we lose one aspect of that makes a great RPG - the emotional attachment to the world. While characters standing around in a town spouting off canned dialog aren't great emotional hooks for an RPG, they do work better than a vague text narrative.

Many of the early RPGs also abstracted the "home base" town down to bare-bones menus. And when I was working on Hackenslash, and had only 40 hours to make an RPG (from scratch), I ended up not only nuking the town, but even nuking a lone merchant for buying and selling stuff.

Ruber is correct - those kinds of things really do consume resources. Mike Rubin has talked about the difficulty of translating experiences from a more text-based world (or, borrowing from the pen-and-paper RPG roots of Frayed Knights, a verbal-based world). In a text adventure or a verbal tabletop game, it is easy to abstract out all of the extraneous details. Going to town to rest or trade equipment can take only three sentences. Of course, if the players decide to do more while they are there, and if the game master is interested, that can expand into an entire mini-adventure, and those details can be fleshed out.

But when you are making the town an actual 3D place, you can't just ignore those details. This has been a problem since the early days of RPGs. For example, a realistic town might have tons of houses with doors - but why waste development resources on stocking each of these houses with people and stuff? You'd end up with dozens of doors in town that were either locked with plot-onium force-fields, or where you would simply get kicked back to the street immediately. And then you had city population sizes that that didn't even come close to that of a realistic hamlet, let alone a bustling town. And you can't just throw in a few details of the local tavern. In a text game, you don't have to describe the furniture. But in a 3D RPG, the lack of furniture, decorations, patrons, plates, mugs, a fire, beer-stains, and all that is very noticable!

So - to some degree - abstracting a town is going to have to occur at some level in an RPG. We have to simplify. But to the level Ruber suggests?

It really depends on what you intend to do with the town. In the Frayed Knights demo, I really ran out of time to complete 1/10th of what was supposed to happen in Ardin. The assumption here is that the gameplay is what occurs outside the town. However, if you played the Ultimas, or the last two Elder Scrolls games, the Baldur's Gate series, the last couple of Wizardry games, or even Depths of Peril, you'll recognize that the towns can be as busy and active of a place for adventuring and gameplay as any dungeon.

That's where I'm going on Frayed Knights. While the bulk of adventuring is going to take place outside of civilization, the goal (assuming I'm competent enough to achieve it, which is quite an assumption) is to have the towns be interesting places to explore, and where (usually non-combat) adventuring will happen. In Mournhold Village, which I'm currently working on (another "town"), most of the key plot developments will require a bit of exploring - and even combat - within the confines of the village.

Secondarily - while the Temple of Pokmor Xang is an exception to the rule (as something of a tutorial adventure), I do not intend to keep a "mission" structure in Frayed Knights. Locations may be revisited at later dates. In fact, there is a room in the Temple of Pokmor Xang (the room to the south of the altar room) which is actually reserved for a later visit. Leaving a dungeon, going back to town, and coming back later are expected actions. Stumbling across optional content is expected. While the game will have a greater amount of linearity than I'd prefer, I'm trying to keep things as open ... and as interesting to explore... as possible.

And that includes towns.

So that's my justification, for what it is worth.

At least, it's my story and I'm sticking with it.

Progress
We've got the first high-level (but boring) monsters in the game... the Crag Wolf. The default camera positioning (and the wolf positioning, and color) are horrible. But they are in there, and managed to slaughter my party (which is still at 3rd level) within 3 rounds. My first attempt at putting the wolves in had their formations together so tightly that the rear wolves had their heads shoved completely inside the front rank wolves' butts. While this made for amusing visuals, it wasn't really what I had in mind.

The higher-level rebalancing has gone... slowly, but it's coming along. Spells haven't been coming along at all, in spite of my ranting and raving last time about them. The big thing right now has been working on feats. At every level, players can choose a new feat for the characters. Some are kinda boring, like adding +1 to Brains. Most are a little more interesting, but still still passive. Some are passive from the player's perspective, but require a bunch of coding on my end... like a feat that allows you to immediately counter-attack when an enemy attempts to attack the back rank with a short weapon (thus allowing Arianna to lay the smack down on a goblin that tries to attack Chloe with a sword). And then there are a few active feats that need to be accessed from the interface in combat.

It takes a lot of code.

We've also got concept art for Victor the Vampire. He's - kinda non-traditional. We decided he couldn't really wear black (too cliche), but white would just not work with his death-like complexion. So we settled on... baby blue.

We think the best way to attack him and flush him out of the protection of his castle is to disrupt his supply of hair gel.

And no, I have no idea how we're going to model his hair, yet. How'd they do Sonic the Hedgehog in 3D?

Mike has the first draft of the music for Mournhold Village. It's walkin' around, background-y music. Here's an excerpt, in case you are interested:

Mournhold Village Music Excerpt - First Draft

We've still got a lot of work to get done in the next four weeks, so it's gonna be busy. And I still - technically - don't have the "first five minutes" of gameplay fully functional. D'oh! Even worse - with the inventory changes - inventory activation isn't working anymore. So potions and Chloe's wand are useless. Double D'oh!

So that's where we are for now. More later. I hope.

Labels: Frayed Knights, Game Design, Roleplaying Games

- posted by The Rampant Coyote @ 5:31 AM (Permalink) 7 comments links to this post

 
Frayed Knights: Call Me Imbalanced
Here is the latest updates on the development of Frayed Knights, the comedic indie RPG in development at Rampant Games:

One of the frustrating-but-cool things about focusing on a later chapter of Frayed Knights right now is that it's forcing me to worry about the higher-level game. This means focusing on leveling up, higher-level powers, and spells.

And here's where I run into some issues.

Being Imbalanced and Breaking the Rules
The easiest handle spells and power balancing is to work on a sliding scale. Level 1 powers to 1 die of damage - level 2 powers do 2 dice of damage, level 3 powers do 3 dice of damage, etc. It works. It's safe. It's easy to balance. And it's boring.

More interesting is, say, a spell that causes another spellcaster to sneeze as he's casting his next spell, which has a chance of causing the spell to fail, backfire, or to randomly become some other spell as its cast.

More interesting? Definitely. More fun? Maybe. I'm not sure yet. But how do you balance something like that? How does it compare to a fireball which should do an average of 20% damage to any number of opponents of approximately the same level?

And does it really matter? In an MMORPG, of course, balance is everything. Players will complain bitterly at any perceived imbalance, as it directly effects the "fairness" of the game for them. Obviously this is true in PvP combat. But it is also an issue in the ostensibly cooperative, massively-multiplayer game worlds. It's an issue with pickup groups - a member of a less desirable class can find themselves reliving their most humiliating elementary school experiences as they watch everyone else get chosen for groups ahead of them. Players are concerned about the survivability of their characters in a harsh, unfriendly environment that was designed to be a challenge for someone more powerful than them. There element of competition may not be as direct as it is in PvP, but it is still there, under the surface, permeating every aspect of the design.

I've heard it argued that in smaller, cooperative roleplaying games - the type of environment Frayed Knights is attempting to emulate - balance is not only less important, but actually runs counter to what makes the game fun. What is important is not making sure that everybody is approximately equal in mathematical equation in points-per-second or points-per-round, but that every player has an equal opportunity to shine. You don't want a homogenized, approximately equal group of characters (or of powers) - you want a wildly varying group that somehow compliments each other.

After some consideration, I'm inclined to agree with that argument.

Granted, you don't want any one character class or power or spell to be so imbalanced that it hogs the spotlight, or becomes overused because it is clearly superior to all other choices. But within those broad guidelines, the design rule I'm trying to follow for Frayed Knights is this:

1. Balance is Boring! Imbalance (within reason) keeps things interesting and fun.

Then there's another aspect of the higher-level game that gives me a headache. Another design rule I'm trying to follow, as painful as it is:

2. Cool, fun abilities (be they from feats, powers, skills, magic items, or whatever) break the rules.

What sucks is, as a programmer, following the rules is easy. Breaking the rules means a lot of extra work. Giving a sword a +1 bonus to damage is freakin' trivial. Giving a sword a +100 bonus to damage is just as trivial. It follows the rules, and just adds a modifier to the math. No harm, no foul.

Creating a sword that can summon a genie after it is soaked with enough blood, or that can sing showtunes on demand, or can do any number of non-swordly effects... that's a pain.

But which sword is more interesting? Which is more fun? Maybe in an MMO, it's all about the Damage Per Second (for some players) - but outside of that competitive environment, it's more fun to have something that gives you new options, or something that's just cool and unique. Something that goes outside the boundaries and breaks the rules.

Fun for the player. Not so fun for me. That complicates code. Time for me to grow more imbalanced...

Progress Report
We are slowly cranking along here on the Mournhold stuff for the next Utah Indie Night, scheduled for April 30th.

Kevin's been furiously building the vampire's castle. It's still very early, and he'll probably be mad at me posting the image here, but here's what we've got so far.

Mike's been working on a theme for the village - it's just a guitar line right now, but he's expanding on it.

We've got the concept artist working on artwork for the vampire and his mistress. We'll see how those look soon.

As for me - my goal (before discovering how crazy this week would be with the day job and a family matters) was to get the first five minutes of this chapter working before Monday. I'm still working on that goal, but I'd say it's pretty high-risk right now. I mean, yeah, I could slap something together in a couple of hours with the existing code and everything... but at this point, we're pushing for stuff of final-product quality. I'd rather have it unfinished than throw-away.

Labels: Frayed Knights, Game Design, Roleplaying Games

- posted by The Rampant Coyote @ 8:07 AM (Permalink) 2 comments links to this post

 
Frayed Knights: Demo Planning
"If it weren't for trade shows, we'd never get anything done." I once heard that from a computer industry veteran in the early 90's. The need to prepare for demonstrations tends to drive a lot of effort. Some of it is wasted effort - a bunch of stand-in elements to keep the demo from collapsing. But having a hard deadline like that, with very specific goals for something that has to be visible to an outsider, helps you focus on what's important.

I had planned to show the next iteration of Frayed Knights for the April '09 Utah Indie Night. Which will hopefully be more towards the end of the month (as it usually is) than the beginning of the month (Greg, are you paying attention! I need more time, cap'n!). But I didn't have a clear goal. And I hadn't been communicating much with my team. Horrible, horrible management gaffes. I know this. Letting communication lapse within the team is probably reason #1 for failure. There are a lot of reasons for this, but I think the biggest is that the team motivates each other. It's not just the team lead or manager trying to do cheerleading.

As for my own progress, I've been muddled in some Really Boring Stuff. It's not particularly motivating, which means I've not been putting in all the time I've needed to put into it. Yes, I'm not the kind of superhuman go-getter I aspire to be. At least not all of the time. You know, I beat this problem every once in a while with some easy productivity tricks, and then I forget to use said methods a few months later. So I'd been struggling with some slow progress and some not particularly exciting upgrades to the game for weeks, and had no clue what I was going to show.

It was Kevin, the "dungeon master" (he's working on the signature interiors, like the Temple of Pokmor Xang), who helped shake things up. I've been giving him the signature dungeons throughout the game to work on, even though I'm not ready to support them yet. He's been struggling with Castle Mournhold, and had some questions and suggestions for me. There are some optimizations that some engines do that Torque just... doesn't. And a semi-realistic castle has all kinds of problems when rendered in a 3D world no matter what engine you use, especially with all the vantage points from which you can see - practically everything. It's hard to cull unused polygons that way.

Even after I explained the whole thing about how real-world castle design didn't work so well in Frayed Knight's fantasy world - with all the aerial warfare possibilities - there are a few "real world" style castles there. I guess I'm a sucker for tradition. Castle Mournhold is one of them. We've based it - loosely - on Bran Castle in Romania. As you can see from the picture, it does not have simple architecture.

After some discussion, we decided to try and make the Mournhold chapter the demo for the April Utah Indie Night (UPDATE: Sorry, this won't be a public release). We both finished the conversation VERY excited about what we could show. We have no illusions about having it completed - but we should be able to show the basics.

First off, it's a vampire story.

One of my wife's all-time favorite D&D modules is Ravenloft, by Tracy Hickman (co-author of the Dragonlance series, etc.). Well, it's one of my favorites, too. But thanks to her, I've played through it (and run it) more than once.

For those not up on old-school D&D - Ravenloft is one of the classic 1st edition modules, and also one of the deadliest. Not quite in the same league as Tomb of Horrors on the player-mortality scale, but up there. But it was also perhaps the first module that was very thick with plot and atmosphere. Later, they started making modules that were TOO plot-heavy, to the point where players weren't allowed to leave the rails. Some blame this departure on the success of Ravenloft. I don't know. All I know is that Ravenloft - which later inspired an entire campaign setting - was a pretty cool Dracula-esque story done the D&D way, worthy of playing through multiple timess.

One of my big inspirations for Frayed Knights was to explore how this group of characters would approach and abuse an otherwise "traditional" fantasy RPG adventure. Imagining how the Frayed Knights would plunge through something like Ravenloft just makes me giddy.

I do have the Hackmaster parody of Ravenloft, Robinloft, just to see what they did with it. It really isn't the direction I wanted to go, however. While memories of Ravenloft provide some inspiration for this chapter of the game, it's really not quite the direction I want to go, either.

For one thing, our vampire is more of a 70's era glam-rock star. Complete with platform boots, a short cape, and bright-colored clothing. With sequins and rhinestones.

That's right, our vampire glitters.

His castle is still in a horrible state of disrepair, but that's not his fault. The monsters ate the maintenance and cleaning crews, drat it all. And he's not quite the evil mastermind - he's got someone else pulling his strings. And, according to Chloe's sources, he's got information. Which means the Frayed Knights may have to take him alive - well, undead - and force him to talk. Can you imagine Arianna trying to interrogate Dracula?

We're going to have a lot of fun with this one.

We'd better, because we only have around six weeks to get the demo ready. Frantic development mode activated!

Labels: Frayed Knights, productivity

- posted by The Rampant Coyote @ 6:26 AM (Permalink) 9 comments links to this post

 
Frayed Knights: Exploring Wilderlands and Looking Under Rocks
It's time for another update on the development of Frayed Knights. This article is actually a bit more generic and fuzzy, dealing with computer RPG design issues in general, and the challenges common to all of them that I am finding myself facing in Frayed Knights.

Detailing Hexes
Many years ago, pen-and-paper RPG company Necromancer Games acquired the license to update the classic Judges' Guild material to the then-current 3rd edition of Dungeons & Dragons. For those unfamiliar with ol' D&D history, Judges' Guild was the first "official" third-party licensee to make support materials for Dungeons & Dragons, from the mid-70's until about the early 80's. TSR, the publisher of D&D, didn't believe there was a market for things like adventure modules and campaign settings at the time.

Naturally, that changed over time, but in the old days of D&D, many players were familiar with the Judges' Guild campaign setting, the Wilderlands.

In January 2003, I was invited to work on the update for The Wilderlands campaign setting for D20. The task was daunting (and unpaid, but I knew that going into it), but fun. The old Wilderlands material was barely useful. The original setting had some hex maps with numbered keys. Because there was so much there, detail was excruciatingly lacking - no better than the results of rolling random encounters. I'd have a hex that would say something like "24 Apes." Okay - so in this 20-mile hex, there are 24 apes here.

I was tasked with expanding dozens of these entries into something fairly interesting of one or two paragraphs in length (plus stat entries). So my expansion on the ape entry read:

Temple of the Ape God (EL 10)
A stone temple stands in a clearing beside a small stream. It is a simple platform, with stone beams supporting the framework for a missing roof. An altar rests before a statue of some huge ape. The statue is exquisitely carved, though time has worn down its features and it is covered with bird droppings and layers of dirt. Despite this, it is an imposing figure, dedicated to a forgotten ape god. Whether it was built by some intelligent race of apes, or by other beings worshipping these creatures, none can say. A tribe of twenty-three apes dwells in this part of the jungle and jealously protects the temple from any intruders. Their leader and alpha male is a ferocious beast that resembles the massive icon in the temple.

Plus the stat-block entry for the 22 normal apes, and the "advanced" leader. The final version was still a little on the vague side, but it was more of a "hook" for the Dungeon Master to build something out of. Is there more than a coincidental resemblance between the alpha male and the ape god statue? Maybe. I left that open to interpretation and expansion.

In fact, one of Necromancer's plans at the time was to have a series of downloadable mini-modules based on these entries, showing how the entries could be expanded into a full-fledged adventure. I worked on three of these, too.

Unfortunately, with the early announcement and release of edition 3.5 and the change in the market, plans for the Judges' Guild releases were tossed into turmoil. The final campaign setting was delayed a couple of years, completely re-worked for 3.5, and neither my contributions, nor the contributions of others that I edited, were to be found in the final version. The mini-module plan was scrapped, as far as I can tell.

The released version of the campaign setting (out of print now, but available as a PDF) was pretty cool, though. If you are ever hunting for adventure seeds, it is an outstanding resource.

Wilderlands Everywhere!

While I was disappointed with my exclusion from the much-delayed final release (and I'd lost contact with the guys in charge in the intervening years, anyway), the experience was a valuable one for me. It helped me solidify some thoughts on RPG design - and exercised some creative neural pathways in my brain.

Most importantly, it reminded me of why I loved roleplaying games so much. While the whole "playing a virtual role" and challenging tactics were all part of the fun, the "big idea" that thrilled me back when I first discovered D&D at age twelve. For me, it was all about the exploration. The expectation that behind every tree, over every hill was an adventure, beneath every rock there was a treasure or mystery to be explained, and behind every closed door was something wonderful or terrible waiting to be discovered.

I'd love one of these Wilderlands-style encounters or discoveries to be around every corner. I want an open-ended game-world bursting at the seams with details, mysteries, mayhem, adventure, and wonder.

Horizons and Computer RPGs
That is how I want a computer RPG to be, as well. Unfortunately - especially with modern games - it is practically the opposite. Too many games in the past bragged about how large their game worlds were, yet most of the actual gameplay involved long, boring journeys with nothing to do except fight random, meaningless battles.

To be fair, one of the games that came closest to meeting this expectation (for me) was Oblivion (though I expect Fallout 3 will be similar, once I install it... after I'm done with Wizardry 8). Unfortunatly, so much of the stuff found off the beaten path in every direction felt likewise random and meaningless. My brain began rebelling as it tried to perceive some kind of plot-related patterns behind things, and eventually gave into disappointment. The world lost a lot of its life for me at that point.

But it provided a good baseline. In an RPG, you don't want the player to have to go moving around too long or too far without stumbling into something to do or a decision to make. Big, empty worlds are boring.

Likewise, the modern design school of blocking off all the "uninteresting" parts is also frustrating to my exploration-seeking mind. As someone who is always wondering what is behind the next door, it's frustrating to find that all but three doors in the town are merely backdrops, untouchable and unenterable, and those back alleys and side-streets are blocked off. As my brain is always seeking what's beyond the horizon, I'm always disappointed to have those horizons taken away from me.

Practicality
But there's the problem of practicality. I mean, if you let me go down one side-street, I'll want to go down the next... and the next. I want to keep opening doors and go over the next hill - and all of that has to be pre-generated (or at least randomly generated). It must be scripted. Artwork, animations, and sound has to be created. It has to be tested. Debugged. Tracked. States have to be maintained and saved. There are triggering conditions, and especially in 3D there's only so much detail and objects that you can show on the screen at once before the player's 4-year-old machine blows a gasket.

And that's where I get frustrated as a designer / developer / programmer on Frayed Knights. As you folks know (if you played the pilot), I've fallen victim to these same game-design shortcuts that irritate me as a player. There are doors in the village that are (currently) unusable, areas that block movement without good reason, and stretches of hallways and village road that just take too long to travel without anything interesting happening (I've corrected this somewhat by increasing movement speed by 50% over that in the pilot, but it's still just a crutch).

I populated the entry hall of the Temple of Pokmor Xang with a ton of objects to poke around with, but while they provide some small insights into the setting and storyline (and some token inventory additions), they still aren't quite what I'm looking for. I'm annoyed by my own (hopefully temporary) inability to fix what I consider broken in other RPGs.

I have some ideas for improving things, but they are still just... gestating. In fact, I wouldn't mind soliciting ideas here for how to improve things and make the world more "chock full of adventure" without introducing hundreds of tons of new content requirements and technological overhead.

So what are your thoughts? How does "exploration" rate in your list of preferred RPG activities? What are your expectations? How would you deal with the ape temple encounter? What kinds of details are extraneous to you in an RPG, and which are welcome?

Labels: Frayed Knights, Game Design

- posted by The Rampant Coyote @ 5:59 AM (Permalink) 19 comments links to this post

 
Frayed Knights: Little Victories
I was about thirteen when I got a Commodore 64.

I'd learned to program in BASIC on a Sinclair ZX80 earlier that year. The Sinclair had 1K of memory. Programming games on that thing was nigh unto impossible. A random game of tic-tac-toe was about the extent of its capabilities. Going from that to a whopping 64K of RAM (48K actually usable) was like heaven. Why, with that much memory to play with, I could make ANYTHING!

But there's a difference between having the technical capabilities of making something, and actually knowing how to make it. Naturally, I wanted to make RPGs. Or adventure games. There really wasn't much of a delineation back in those days. But I had no clue how to do it. After searching for inspiration in David Ahl's Basic Computer Games and More Basic Computer Games, I had some idea of how to drive a semi-data-driven interface so I could have a webwork of connected rooms that I could walk through with a text interface of directions like "north," "e," and "up."

I got it working at about 11:00 one night. I was exultant, but I had to refrain from cranking my music up and dancing a victory dance to avoid waking up my parents. They wouldn't understand. It was a Black Triangle moment. Anybody else looking at it would say, "Huh? What's the big deal about that? People have been doing that in adventure games for years."

But for me, personally, it represented a big step. I was able to walk around a virtual 12-room text-based world. I had found "The Way," and it would later provide the foundation for a few adventure-like games I wrote in my spare time (no, none were ever released to the public). I was able to see that.

When programming, there is roughly 10,000+ different ways of doing something. The trick is trying to figure out "the right way." The way that won't disintegrate into an unmaintainable mess when you realize you missed a critical feature and have to shoehorn it in. The way that won't make your life harder as it goes from exercising test data to using real data. The way that will probably STILL get completely overhauled once you've finished it and realize how you could have done it better.

And yet the average person will not appreciate it in the least. For example, doing UI stuff. Which I am STILL working on. For the average player, the amount of work that has to go into making a working drag-and-drop inventory is probably going to be completely lost on them. They just know that it should work.

On the design and coding side, there are a lot of issues to take care of.

Like what happens to the object - logically - when it is picked up from one an inventory and dragged across the screen? Does it remain in the original inventory, but hidden in the interface? Or do I remove it from the original inventory the moment it is picked up, but before the player has chosen what he's going to do with it? What happens if he tries to shut down the inventory screen or bring up the option screen with a keypress while holding an item with the mouse? If I bring up a pop-up screen of the items stats when the player hovers the cursor over an item's icon, should I still do it if he's dragging another item around? Will that be confusing? And what if I don't WANT to move the item, but simply want to activate it?

For what seems like a simple behavior, there are a ton of questions that need answered, code that needs to be written to deal with exceptional cases, and bugs that need fixing. Or I end up walking around with a wand icon stuck on the screen and my fireball wand permanently missing from my inventory, as happened in the picture.

All these elements all have to work together consistently. Otherwise, it feels clumsy to the player. As the first iteration of many UI elements did for a lot of players who tried out the pilot. I can't guarantee this new stuff will be a huge improvement, but it will be an improvement.

It's all boring, black-triangle-y stuff, yet I find myself feeling all excited and exultant when it works. Just as I was when I completed the rudimentary system to walk around a 12-room text-based world when I was thirteen.

But really, I'm just looking forward to it all working perfectly so I can FORGET ABOUT IT and just have it work for me so I can move on to bigger things.

Labels: Frayed Knights, programming

- posted by The Rampant Coyote @ 1:25 AM (Permalink) 5 comments links to this post

 
Frayed Knights Critique, Part IV
I have been involved in the development of about a dozen commercially released games. Three were relatively big hits, and spawned sequels that also went on to become big hits. Twisted Metal, in particular, became not just a series but an entire franchise. There were many magazine pages and forum threads devoted to some of these games.

Still, I don't think I have ever seen any of my games critiqued as thoroughly in one place as Diego Doumecq has critiqued my little Frayed Knights pilot. I think the dude has played the game more than anybody else in the world who isn't me. I do not agree with everything he says, but I can't dismiss any of his points.

He has finally concluded his four-article critique that began in October of last year. He's been gentle, acknowledging that yes, the pilot was an experimental playtest release and not supposed to be a full, polished experience. But it was released in order to solicit feedback - a task which I can only call a stellar success - and Diego went way beyond the questionnaire I asked of players. Thanks, dude!

Anyway, part IV is up - bigger than any of the previous parts. Here are links to every part of the series.

Frayed Knights Critique, Part I
Frayed Knights Critique, Part II
Frayed Knights Critique, Part III
Frayed Knights Critique, Part IV

I'm not really going to do an in-depth response here. He's devoted quite a bit of time and wordcount to each point, and most of them have gone into my churning bucket of redesign already. I'll probably be devoting full-fledged posts to some of them. But I can't resist some quick-and-dirty responses, because I am a weak-willed individual. So here goes.

World scale - part of the problem stems from having people be actual "human size" rather than "Kork-Sized" (the name of the Orc model that comes with Torque). Based on the recommended scale by GarageGames, Kork is somewhere between 7' and 8' tall. People tend to model around his proportions. But there's another factor: Play City of Heroes sometime and have your character sit on a bench or something. Compare sizes. Now, part of this is also because players like to make their characters as big as possible, and the world has to accomodate the largest-sized PCs. But you get this (to a degree) in every game - things appear too small on the screen in 3D when modeled exactly to scale. So they always get a little exaggerated.

That doesn't mean I don't need to wrestle scale issues more in Frayed Knights. That's still a given, and something I hope the learning experience with the Temple of Pokmor Xang has taught us to be more dilligent about. But some of it won't ever go away.

As far as random encounters and randomness in general: I've talked about the "wandering monster" issue in games before. I'm not satisfied with how encounters in Frayed Knights - and the entire combat system - are handled, either. It strayed too far on the "bad" side. It was one of those things that looked just fine on the page and in my head, but so far hasn't translated to the screen very well. Unlike Diego, I am a fan of a certain level of randomness in RPGs. I think the "skill" in playing RPGs comes down to managing the risk of the random. But there's a certain threshold in any game where it just becomes irritating, and not fun. And I think Frayed Knights combats and encounters strayed too far down that path.

But I also changed how the whole "wandering monster" / "random encounter" thing worked about seven months ago. So I've almost forgotten how the old system (which is still in the pilot) played. I'm not totally happy with the new system either, but it works much better and is a lot less random.

Drama Stars - You know, for all the focus this system received before the release, the system sure did end up landing with something of a "thunk" noise. They are hardly ever used - even by myself. This is an argument that they either need to be dropped altogether, or expanded upon and enhanced to be more integrated into the game experience, and given a broader mandate than simply being an encouragement to avoid optional reloading. Me being the kind of overeager optimist and nutcase that I am, you can probably guess in which direction I'm shooting now.

Labels: Frayed Knights, Game Design, Roleplaying Games

- posted by The Rampant Coyote @ 7:27 AM (Permalink) 7 comments links to this post

 
Frayed Knights - UI, UI, Oh, No, Me Gotta Go...
Many of the suggestions I received for improving the Frayed Knights Pilot involved the UI. This wasn't too surprising.

Some of the changes were easy. Using the arrow keys to move around (in addition to the FPS-style WASD controls), changing the mouse-look system to be more traditional, etc. I haven't added the ability to customize keyboard commands, but that's a given for the final release (someday...).

Using What They Gave Me

In order to get the pilot playable and done on time, I did a lot of the UI work with Torque's default UI system. Torque has a pretty nice UI editor, with a fairly comprehensive set of workhorse UI elements. If you don't mind your game interface looking like standard web forms or an MFC application, it works really well. With a little bit of custom code and some good artwork, it can actually look pretty good. For between-game menus and stuff, it's awesome.

But I needed more. A big reason for creating this "Franken-Engine" of the Torque Game Engine and Torque Game Builder was to take advantage of the 2D capabilities of TGB to make cool, dynamic, polished UI elements. Unfortunately, except for the main screen and the character dialog sequences (which admittedly still need some work), this didn't happen much. Mainly this was due to lack of time. Almost as significant is my own cluelessness with respect to user interfaces.

So now I'm going back with the advantage of hindsight (though I probably need to impose tighter deadlines on myself... again) and trying to exploit the tools I now have available to make things look and function better.

It doesn't help that my programmer art still sucks, but hey - baby steps.

My Engine Sucks! (Warning - Technical)

My focus the last two weeks has been on something I intended to fix two months ago. The inventory. Granted, the inventory management screen isn't the piece I've gotten many complaints on - though several players have requested a more modern drag-and-drop style inventory screen. I personally want more animation, and a more intuitive system.

Unfortunately, one of the challenges I faced was that for some reason, my franken-engine isn't letting object-level mouse events through. There is functionality in TGB (I used version 113 - the last one with some semblance of compatibility with TGE) for objects to handle callbacks when the mouse moves over them or clicks on them, for example. I even tested it out in TGE 1.13 to make sure it works. But for some reason, when mixed with the Torque Game Engine and all the other crap I've got in there, something got lost, and it's not working. I tried a number of permutations for setUseObjectMouseEvents and everything, but no luck.

However, the window would still receive mouse events, so after a couple of days of frustration (and a couple of days where I didn't touch the game at all out of annoyance), I began implementing things "the hard way."

In retrospect, "the hard way" wasn't nearly as hard as I thought they'd be - particularly not after I uncovered some functions that made it easy to determine whether or not the mouse was "inside" an on-screen object. In fact, I think the current system - in the long term - is actually going to be a lot easier to manage, centralizing control over the inventory interface where there are a lot of complex interactions. Score!

This will also act as a template for the other new interfaces. The real problem children, which need help even more than inventory and trading, are combat, spell-casting, and the trap / lock screen. Combat in particular is gonna get a complete overhaul, based on feedback. The core idea will remain the same, but it needs some major TLC.

Inventory Design Follies (Not Nearly So Technical)

Something I'm doing differently with Frayed Knights from most other games is that not every equipped item has a hard-and-fast "slot."

I did get really complicated early in the design and have a whole system that would allow a character to wear, say, a head-scarf, an arming cap, a coif, and a helmet all at the same time (and maybe even a floppy hat on top of the helmet...), but I finally realized that the coolness of being able to do that did not justify the massive confusion and interface difficulties that this would present. Just because you can simulate something in code doesn't mean you should.

(Yes, I'm one of those wusses who shy away from the NetHack interface. How do I freaking DROP an item, again?)

Anyway, one aspect that I wanted to retain - and I think I have - is to have a lot of non-standard items. Goofy items. I always loved the "Hip Waders of Protection" from Hackmaster. Or things like the "Bad-Ass Bandanna" from Munchkin. There's no reason you can't wear both a "Headband of Pebble-Grabbing" and a "Helmet of Smackdown Protection" at the same time.

So some items have specific slots (like a helmet), and other items simply use a generic "accessory" slot. You are limited to the number of accessories you can wear at one time, though this limit can be increased as you level up. Yes, I realize how much of a girl I'm sounding like right now, but that's the way it works. Things like necklaces, rings, earrings, bracers, underwear, tights, nose-rings, armbands, socks, scarves, belts, eye patches, corsets, and other junk are labeled as "accessories." So yes, you can now wear two or three necklaces at a time.

Goals

My goal is to have a really new, improved Frayed Knights ready for show at the April Utah Indie Night event. New interfaces, new combat system, *possibly* a redone AI system, shopkeepers, new quests, new locations and monsters, better sound, etc. I'm still working on the details for that milestone. But I figure it'll help me stay motivated and make the big push over the next three months (our next Utah Indie night is next week - assuming I can make it, as my daughter has an awards ceremony the same night).

Labels: Frayed Knights, Roleplaying Games

- posted by The Rampant Coyote @ 7:36 AM (Permalink) 6 comments links to this post

 
Frayed Knights: Butt-In-Chair Work
When I was working on Jet Moto, 3D modeler Michael Makarczyk was commenting on how a certain change to the code was going to force him to go back and change how his models worked. When producer Danny Lunt asked if that was going to be difficult to do, Mike responded, "Nah, it won't be hard - it's just a lot of butt-in-chair work."

I've used that term a lot since then. It pretty much sums up about 80 - 90 percent of game development. It's not particularly exciting or sexy. It's tedious. It doesn't make great screenshots. But it has to get done.

Implementing new UI systems is like that, as I am right now in Frayed Knights. Fixing bugs in the new code is like that. I spend a lot of time stepping through code, checking variables in a watch list, and muttering "WTF?" to myself a lot.

Some bugs are easier to fix than others. Bugs where things are just happening wrong are easy. You trace back through the code, find out where the virtual wires are getting crossed, and fix them.

Bugs where memory gets corrupted are a real pain, as the bug often occurs long before you see something go wrong. The worst of these are the dreaded "Heisenbugs," which seem to never occur in exactly the same place or time, and the bug disappears in debug mode.

Not quite as bad, but also among the more annoying bugs to fix are the ones where nothing happens. Everything looks right. But events just are not firing for some reason.

It is especially tricky when you are working with a third-party codebase, and when you've got the layers of indirection between a scripting language and the actual code, as you have with Torquescript. Have I mentioned lately that I'm kinda disgusted by Torquescript? It's not BAD, but it sure can be frustrating on big projects. If something doesn't work, you have layers upon layers of possibilities to try and figure out which of many stages simply didn't do what they were supposed to. Was it the triggering condition? Some variable that's not been set that needs to be set before some process you don't know about will actually execute?

*Sigh*.

Well, back to getting my butt in the chair and getting work done. Later!

Labels: Frayed Knights, programming

- posted by The Rampant Coyote @ 8:00 AM (Permalink) 3 comments links to this post

 
Frayed Knights Pilot Critique and Delayed Consequences
Diego Doumecq has written up a third part of his critique of the Frayed Knights Pilot: The Temple of Pokmor Xang. I thought I'd link to it here, and talk about it (and Frayed Knights) a bit.

Frayed Knights Pilot Critique, Part III

Curiously enough, even in the pilot, there is something similar to the danger-o-meter he suggests. As you fight creatures in an area, the threat level (and chance of additional encounters) decreases. However, that aspect was never fully tested. I've since made some modifications and in the version that I am running, I've actually got something like that running in the UI. But not as pretty - it's just a number.

His speed-run through the dungeon made me grin. I wasn't sure anybody would actually try that, but I wanted to script it out appropriately. And yes, I wanted to make it a viable (if not the easiest) way to complete the dungeon. It needs to be cleaned up a bit, but that was the main idea. Or rather, a prototype for the idea. Was it worth the effort?

I'm going to give a cautious "yes." Yeah, I spent some extra time coding up an alternative that very few people will try, but the fact that it's there means something to me. Best-case would be to have some genuinely organic high-level AI deal with it as a more general solution. But then you wouldn't get the warning dialog.

Honestly, I never thought that I (or anybody else) would consider the lack of feedback to a player as being a virtue. But this brings up the topic for today: Delayed Consequences. Diego writes the following:

"Just imagine it, you made a bad choice but you don’t know that yet, so you go on and use another save just in case. Three hours later, the ramifications of your previous decisions surface and now you have a really strong urge to reload. But that would mean three hours down the toilet wouldn’t it? And you still don’t know the consequences for the other possibilities, so that could also mean even more hours down the toilet.

"Most likely, the player will just go on, preferring to live with a stain on their record than to waste various hours trying to do everything perfectly. He would be taking responsibility on his actions, and facing the consequences without all the metagaming that quickloading implies."

He's speaking of the encounter with Valeria inside the cell. There are basically four states that you can leave poor Valeria in (although one was broken in the pilot):

a) You never encountered her.
b) You encountered her, but refused to set her free
c) You encountered her, and set her free immediately (after an argument within the party).
d) You encountered her, don't set her free at first, but come back to let her go later.

From a design perspective, I really want all four options to be perfectly valid - there is no "correct" decision. But as to which might be considered the "preferred" set of consequences? I ain't sayin' yet. :)

If the consequences of the decision are not immediate, they MUST be non-fatal to a successful completion of the game. One of the cardinal sins of game design is allowing the player to save the game in an unwinnable state.

In theory, I could make sure that every decision is either wrong or right by changing Valeria's purpose based upon the player's decision. But that's not how I roll. I feel that robs the player of real consequences for their decisions. That, and I do like to provide some hints throughout the game with these kinds of decisions, so it's not a flip-the-coin type of issue.

The more fun kinds of decisions like this are when the player is choosing between all desirable or all undesirable options. Kinda like picking the cards in the character generation mini-game of the older Ultimas. Both options are "good," but they take you along different paths. It makes the answers non-trivial.

In the case of Valeria, that encounter was also something of an inside joke, and an attempt to twist a standard fantasy RPG trope. The "damsel in distress" thing is pretty much hackneyed. In some of the older Dungeons & Dragons modules, however, it was twisted so that said damsel, always needing rescue, was also almost always EVIL and a threat to the party. Other dungeon masters picked up on this, and routinely threw this kind of threat into their custom adventures. It kept working, too, because the adventuring parties were almost always played by teenaged boys with only one thing on their mind besides hacking & slashing.

It got to the point where finding a beautiful woman chained to a wall in a hostile dungeon automatically set off warnings. The more beautiful and scantily clad, the greater the likelihood that she was part of a trap. And yet, we kept falling for it, unless we were playing evil characters. Because you just CAN'T leave some woman chained to a wall in a hostile dungeon like that if there is the slimmest chance that she might be innocent.

Invariably, it would be a trap, and we'd get our butts handed to us one way or another. Sometimes it was immediate, sometimes not. And the DM would laugh at us for falling for it. And we'd fume, and vow never, ever to free some scantily clad beautiful girl from the torture chamber of the giants' fortress again.

But there are still yet more purposes for Valeria!

One of the things I have learned over the years is that in games, you really have to meet a character (NPC) a couple of times in different situations before you (meaning, the player) gain any amount of interest in them. Everyone else is a stage prop. I don't care if he's Lord Freaking British, if you only encounter him when he's got his butt planted on his throne, he becomes two-dimensional wallpaper.

Running into that NPC in other places seems (to me) to give them a life, a hint of a story that goes beyond them sitting in one place waiting for you, the PC, to chat with them. It provides the illusion of activity.

But I've got to do a better job with handling NPCs than I am now. This was a prototype, and I'm pleased it actually worked for Diego.

So what do you think? If you have faith that a decision with delayed consequences won't "wreck" your game (but may not make the game easier, either), are you okay with this in an RPG? Or do you really prefer to receive immediate feedback as to the consequences of your actions - the negatives and positives to faction, etc.?

Labels: Frayed Knights, Game Design

- posted by The Rampant Coyote @ 1:59 AM (Permalink) 13 comments links to this post

 
Frayed Knights: Abandon All Hope...
More on the development of Frayed Knights, the comedic indie RPG in development from Rampant Games.

First of all, Diego has part 2 of what looks to be a 3-part installment critiquing the Frayed Knights pilot. Man, I can't wait to hear what he'll say with a full-sized game! Check out his constructive criticism at his site:

Frayed Knights Pilot Critique, Part 2

To be honest, much of my time the last two weeks in development of Frayed Knights has been devoted to building the roughed-out version of the Tower of Almost Certain Death. Up until the last couple of nights, it's been a nice excuse for not working. I mean, yeah, it's been work - on the game, even - but it's been a lot of fun too. Torque Constructor has been working like a charm (for a change), and this is something I'm still learning. It's like playing with Play-Doh.

Unfortunately, even fun parts get tedious after a while, and actually become work. And there's still a lot of work left.

One interesting aspect that I'm probably going to get ripped on as I'm developing these levels is the orientation of my spiral staircases. It seems most modern spiral staircases are made to ascend counterclockwise. In actual medieval fortresses, the staircases were usually constructed so that they ascended clockwise. Under the assumption that everybody fights right-handed (poor lefties - or those who favored the "sinister" hand - were pretty much beaten into learning to favor the right hand), this gave the advantage to the defenders above. The attackers had to expose more of their body when fighting this way, and had a rougher time bringing their weapons to bear.

However, in the world of Frayed Knights, a lot of fortresses are underground, where the defenders would be below the attackers. In these cases, you'd want to build staircases that ascended counter-clockwise. So I'm just gonna have to have a bunch of inconsistent staircases - they will be built clockwise for above-ground fortresses, and counter-clockwise for underground fortresses. Or both, if said fortress goes both ways.

Not that this makes one bit of difference in the game itself. It can't handle fights on spiral stairways as it is, so it only of academic interest, anyway.

Besides building a tower so that it can at least be playable (once I have the outdoor wilderness level completed), I've done some experimental coding. I spent a lot of time (and sacrificed some shortcuts) to merge the Torque 2D codebase (now called "TGB" or Torque Game Builder) into the base Torque Game Engine (plus yet more enhancements). Yet I haven't really taken advantage of the power of the 2D engine features. For one thing, I'm experimenting with making a modern inventory system - and modernizing much of the UI - by using T2D rather than Torque's default UI system.

This was always my intention, but it means a lot more custom code. It was much easier to slap something together using Torque's UI builder and call it good for the purpose of the pilot. The inventory system is getting the big overhaul right now, with a "merchant class" sitting half-finished waiting to be incorporated in the new, improved interface.

Speaking of interfaces - man. If there's a single loudest complaint for the game, it has been the control system. Customizable keyboard commands is one of those other aspects which I always intended to be in the full version, but I didn't think it was critical for people to just test things out and see how it played. Apparently, I was wrong. Live and learn. People want to make the controls familiar so they can ignore that part of it and get on with the playing. If they can't do the former, they may never get to the latter.

Another issue which I have finally conceded defeat on is the actual movement interface. I was trying to do some funky mouse-only control scheme for the benefit of less hardcore gamers who tend to navigate around their flash games by clicking on the edges of the screen and stuff. And to try and build off of some ancient foundations laid by old-timey Ultima Underworld games.

I have come to realize that (a) Those people won't be playing my game anyway, and (b) Ultima Underworld's control system really did suck. I mean, sure, you got used to it, and it was pretty nifty once you did because it was like being five years old again and showing off to your mom how you were able to ride your bike by holding onto the handlebars with only one hand. But that still didn't make it good.

So it's going back to more of an FPS-style control. Hopefully people won't play it like an FPS. Basically, if you've played a first-person MMO or RPG, then you will have no problem adapting to the control system.

Forward, backward, turn left, and turn right default to W and Up Arrow, S and Down Arrow, A and Left Arrow, and D and Right arrow, respectively. The Q and E keys are the default keyboard commands for walking left and right (no turning). By holding down on the right mouse button, you can also look around and turn using the mouse. Otherwise, moving the mouse around only moves the mouse cursor.

See? I can be taught.

Happy or unhappy with what was posted? Let others know on the forum thread!

Labels: Frayed Knights, Game Design

- posted by The Rampant Coyote @ 4:44 AM (Permalink) 8 comments links to this post

 
Frayed Knights Pilot Critiqued
It's not often that I link to a site that shreds my hard work to pieces. Fortunately, that's because the latter doesn't happen too often. Maybe because Scorpia hasn't reviewed one of my games yet... :) But more likely because I'm nowhere near as prolific as I'd like to be, and I'm still pretty much off-the-rader as an invisible indie.

In this case, Diego Doumecq has taken apart Frayed Knight Pilot: The Temple of Pokmor Xang from a game design perspective, and has been pretty respectful of both the material and his role. And he seems to have really enjoyed the game, which makes me happy. But he has a lot of constructive, well-thought-out criticisms that he brings up that are worthy of discussion and consideration.

The issues he brings up are similar to the ones I have received in feedback forms from people who have played the game (still not quite up to 1,000 emails, but getting closer...), but he has done a very good job of putting his finger on the some of the root causes. For example, there's the problem I was well aware of when I released the game that combat was nowhere near where I wanted it to be, and I was having problems seeing the forest for the trees. Many players have pointed out the issue, but only a few have been as clear at pointing out some of the exact problems as Diego has here (and there are definitely more problems than the one Diego has addressed).

In part 1 of the critique, Diego primarily tackles interface issues - which are definitely easy targets for the game. There should be a part 2 coming up shortly, and he's also got some other game design articles and critiques available on his blog that are well worth reading. Part 2 should be appearing shortly, and I'll update this post when it appears.

I have said it before - but the purpose of the pilot episode of Frayed Knights was to solicit this kind of feedback from players. While I've got a ton of opinions on CRPGs, simply having an opinion and being able to deconstruct a game does not immediately translate to being able to create a killer design of your own. I'm a learn-by-doing kind of guy, and so this has given me the opportunity to learn what I have done right and done wrong a little bit faster.

So I want to thank Diego and all the people who have emailed me with feedback, suggestions, compliments, support, and criticisms. You folks help me become a better game developer. This sort of direct communication is what I feel can make indie gaming great!

Frayed Knights Pilot Critique at Indigo Static

Labels: Frayed Knights, Game Design

- posted by The Rampant Coyote @ 9:40 AM (Permalink) 0 comments links to this post

 
Frayed Knights: Dungeon Guidebook
Since we're back in the saddle again, I wanted to continue the more-or-less weekly discussion of the humorous indie RPG in development, Frayed Knights...

One of the more fun tasks I get to do when working on this game is the world design. When I'd take walks during lunch at the local park, jamming to really weird music and fantasy movie soundtracks on my iPod, I'd actually think of world design elements in the form of written travel guides. Yes, if you needed any more confirmation of my mental instability, this is it.

Anyway, I've written a couple of them up, and I expect them to find their way into Frayed Knights as actual in-game items (or as part of an instruction supplement). Here's the one on dungeons, which I have been promising for a while, and which has been guiding some of my thoughts the last two weeks.

These guidebooks were written by one of the most famous adventurers still living, Argus Stormhammer, the founder of the Adventurer's Guild. He wrote a whole series of pamphlet-sized guidebooks about a decade ago, and they are now considered essential reading for all adventurers.


“Dungeon” is a generic term for any underground adventuring location. As any veteran fortune-hunter knows, Kalderia – in fact, all of Zerion – is absolutely cluttered with these places. Where did they all come from? What beneficent god sprinkled these lovely caches of fortune and excitement ripe for our plucking all over the landscape of our fair kingdom?

Well, a good number – a majority, in fact – are simply naturally occurring caves or lairs of subterranean monsters. But to understand the rest – which are usually the most lucrative – one must understand history. History is the friend of the fortune-hunter, and it will serve us here.

About five hundred years ago as of this writing, the entire world was engulfed in the great Wizard War. Before that time, above-ground castles and towers were still in vogue – as they are returning to, now. But the wizards had air-power. Nepharides himself was rumored to lead an entire squadron of fire-breathing dragons. Traditional castles which seemed impregnable from the ground might as well roll out the red carpet when the hordes of winged monkeys, dragons, flying demons, and magic-carpet-riding wizards came to invade.

The solution was to burrow underground. The best dwarven engineers were enlisted to design and construct massive underground complexes to supplement or replace above-ground fortresses. Even after the war, a grand underground fortress was a status symbol amongst the wealthy and noble, and fantastic sums of money were paid for the design and construction of everything from small country cottages under forested hills, to entire underground cities.

While the dwarves were happy to oblige, they simply couldn’t keep up with the demand. Their fees were tremendous, and the waiting time began to stretch into generations. Eventually, more cost-conscious developers began hiring cut-rate help… including goblin engineers.

Now, while there are many skilled goblins at this sort of work, they weren’t always the most reputable. Many would turn around and double their money by selling the secrets of their designs to the enemies of their rich clients. Non-dwarves sometimes skimped on things like ventilation. That, or dungeon-owners would forget the population limits on their fortresses, and would host a few too many guests, or have a few too many babies. Then, before you could say, “Why is this canary dead?” entire dungeons became depopulated and forgotten.

Dungeon Delving
Now, most adventurers will brag in their tavern tales of fierce monsters and deadly traps faced in their underground forays. These threats are considerable, and I have lost many friends to these dangers over the years. I talk about them in other pamphlets. But there is another threat when deep underground, and that is bad air. There may be pockets of bad or toxic air in some of the poorer-quality mines, caves, or fortresses which may not be apparent to you until you start getting dizzy and passing out. There are magic items and spells (like one the wizards call “clean air”) to help you with that.

Water is a large threat as well. It’s usually very cold, which is bad enough, but it is also good at concealing dangerous drop-offs. And monsters. And traps. A potion of fish-breath is a handy item to keep around just in case the water surprises you with its depth.

Just because you have heard that such-and-such a dungeon has already been looted by other adventurers, don’t assume it is useless to you. It may still be a lucrative expedition for three reasons:

#1 – Many complexes that protect considerable wealth employ a false treasure room designed specifically to be more obvious of a target. The real treasure is often much harder to find. Many treasure-hunters find the false treasure, call the day a success, and leave a now-depopulated dungeon with far more wealth unprotected behind them.

#2 – Larger underground complexes were often home to a number of wealthy individuals who maintained (and hid) their own personal treasures in places other than the main treasure room. I once found a diamond necklace hidden in a cranny beneath a loose stone in complex that had been thoroughly explored by no less than three different adventuring parties.

#3 – Unless well hidden, shelters such as these seldom remain uninhabited for long. If more than a couple of years have passed since a dungeon was last explored, there’s always a chance it could have accumulated new residents – often of the lethal and hungry sort – and new treasures.

#4 – While some consider it unsavory, there is always the possibility of the types of finds euphemistically referred to as “secondhand” treasure. I know that if I were to meet my own demise in the bowels of a dungeon – a danger I have faced thousands of times – my spirit would rest easier should my array of expensive and magical gear find its way to serve another adventurer in need, even if only to provide extra coin to hoist a mug of ale to my memory in a nearby tavern.

Dungeon Classification
You may sometimes hear fellow adventurers talking about a “Bagger” or a “Lair” or a “Class C” when talking about dungeons. Fortune-hunters, over time, have evolved a classification system when speaking of their finds. Here is the most common usage of these terms:

Class A Dungeon: Also referred to as a “stronghold,” this an underground complex populated by intelligent, cooperative enemies capable of mounting an organized defense. These are among the most dangerous of dungeons, and are for experienced, combat-ready fortune-hunters only!

Class B Dungeon: Also referred to as a “lair,” this is an underground structure populated by threats incapable of mounting an organized defense together. For example, a dungeon inhabited only by unintelligent monsters, or by intelligent creatures that do not cooperate with each other to defend it might be a class B dungeon.

Class C Dungeon: A class C dungeon is one that lacks a living population, but is likely to contain automated defenses such as traps, automatons (including golems and certain sorts of undead), or incidental hazards (like hostile molds).

Class D Dungeon: Also referred to as a “bagger,” this is a dungeon with no known protection other than its obscurity or possible environmental hazards.

Now, bear in mind that this usage isn’t universal. Some adventuring groups combine the meaning of class C and D dungeons, for example, so you should always double-check your source to make sure you fully understand what they are referring to.

Until next time, keep your sword and mine sharp, and good hunting!

--- Argus Stormhammer, Veteran Explorer and Fortune-Hunter


Oh, hey! Forum Discussion!

Labels: Frayed Knights

- posted by The Rampant Coyote @ 5:53 AM (Permalink) 7 comments links to this post

 
RPG Design: Building a Better Dungeon
I spent a good deal of time last night going over visuals for dungeons - real-world dungeons, as well as artist renditions and video game dungeons. Of course modern, fantasy dungeons are very different in both form and function from their real-world counterparts. Real-world dungeons were not much more than white-washed stone pits with cells. Though as time goes by, the white-washing has gone away to be replaced by lime deposits and mold.

Which I guess is supposed to be the point of fantasy dungeons. They are generally old and no longer maintained. And they are huge complexes that serve as lairs more than a place to hold unwanteds.

Naturally, I was doing this because I was busy building content for Frayed Knights. Experimental content, but content. In some ways, this is a follow-up of last week's article, but getting down into the details. Yeah, I write about what is currently obsessing me.

The tricky thing about dungeons for fantasy adventures is that they have to ... uh... not be realistic. Realistic is boring. I mean, really - if there's only one entrance into the dungeon, all you need to do is lay siege to the entrance, ring an alarm bell, and sit in for a long siege. Or block off the ventilation. If there's an organized force of orcs or whatever in that dungeon, they should REALLY just attack as a unified swarm, overpowering the Player Characters by sheer mass of numbers.

Part of the fun of designing the world of Frayed Knights has been coming up with justification for some of the goofy logic we D&D players have to assume in order to suspend our disbelief. Like why the freak are there all these gigantic, underground complexes everywhere. Dungeons & Dragons has subtle explanations, in the form of dwarves & other creatures that were superhuman miners, and the availability of spells like "Dig" (which disappeared in 3rd edition), and "Stone Shape" and "Rock to Mud / Mud to Rock."

But what we lack in logic, we can at least make up for in consistency, and appealing to real-world conventions where they make sense (or even where they don't). Things like arched ceilings are a pain to model, but are architecturally more sound than squared-off flat ceilings we are used too. Lacking that, frequent support pillars and cross-beams to keep the tons of earth and dirt from collapsing the dungeon in on itself can help with visual appeal.

I was halfway through with this post when I discovered Shamus Young - by some bizarre act of serendipity - had addressed some of the same issues for making more "realistic" dungeons. Not realistic as in behaving realistically (in the aforementioned boring fashion), but to maintain enough verisimilitude that the details bring the world alive. Since I was just going to talk about how a certain Hackmaster module had a creature living in the kobold's latrine (and just enough kobolds would get drunk and forget to keep the monster fed), I'll simply refer to Shamus's article. He saved me about a thousand words.

GM Advice: Dungeons that Make Sense at Twenty Sided

Finally, another factor to consider is history and the effects of time. I'm not necessarily talking about ancient history (like the fact the Temple of Pokmor Xang was originally created for a much more terrible deity, a fact which might not ever even be useful in the game itself), but simply the problem that most fantasy adventure locations exist in some kind of stasis. Nothing beyond the basic routine ever seems to happen until the player gets there. The monsters just sit patiently in their little dungeon-apartments waiting for the day when the door will burst open and adventurers will appear, like the evil opposite of opportunity knocking, and kill everything in sight and take their stuff.

One aspect to consider is to consider the history of the location - from its original construction (it was originally built for a dragon, so everything is BIG) down to what happened yesterday. Barg the goblin and his mate got in a fight, and now Barg is sleeping out in the hall. That hanging bone decoration in the chieftain's sleeping chamber is actually the missing adventurer the people in town were talking about last week.

The problem with adding time details is that they risk becoming obsolete when the player comes back to the location a second time. In a pen-and-paper RPG, the GM can try and wing it (in fact, the old Against the Giants module series for AD&D made suggestions for how the giants would react to repeat forays by the players). But in a computer RPG, the static nature of those details makes it glaringly obvious its all a setup. Not that this surprises the player, but it still interferes with the suspension of disbelief. So these have to be added with care.

Dang. And I thought my job was done when I connected some 30' x 30' rooms together with short 10' wide hallways.

Labels: Frayed Knights, Game Design, Roleplaying Games

- posted by The Rampant Coyote @ 4:20 AM (Permalink) 1 comments links to this post

 
Frayed Knights Wins Game-In-A-Year Competition
I'm very pleased to announce that the Frayed Knights Pilot: The Temple of Pokmor Xang has won the Dream Games' "Game In a Year" competition that began in April 2007, and culminated in April of this year.

The competition may have ended in April, but judging between some very strong entries took a little bit longer.

The announcement was made on Dream Game's forums last night. Rampant Games was cited as being "consistent throughout development, had the best quality product which adhered to their design, provided excellent testing and feedback cycles through their community."

Oh, yeah, community! That's you guys. Thank you. We literally could not have done it without you.

We had a TON of people sign up for the alpha and beta testing of the game, and while the pilot version of the game is probably not the pinnacle of polish and freedom from bugs (or even solid gameplay), suffice to say that the alpha test team endured far, far worse. Certain people in particular worked their butts off with suggestions and detailed test reproduction steps with every single build, probably growing almost as tired of the same level as I was. I'm going to note Random Gamer, francotau, DGM, Cowgod, Samrobb, Ezin, NME, JenaRey, Space Bumby (or, more particularly, her kids --- who gave it quite a workout), Califer, Smackey, and probably others who were quite active the first month but their posts got reaped by accident.

RandomGamer, DGM, and Cowgod in particular were amazing with their constant feedback and suggestions. They would dig DEEP to help me uncover some hard-to-find bugs. And I sometimes ignored their suggestions to my own regret.

Even those who were not heavily involved in testing provided me with some great advice and suggestions in my weekly development diaries. I made some major changes during development based on the advice of clear-thinking readers who were able to point out some areas where I was completely overthinking the problem, or going down the wrong path.

Likewise - I have been deluged with feedback from people who played the pilot. I have received over 700 responses with useful feedback and comments that are helping me shape the full version of Frayed Knights. Some people sent me gigantic forms of information full of brilliant insights, and some suggestions I'm dang well trying to incorporate. Granted, it's kinda humbling to realize that just about everybody BUT me could spot some of the glaring problems with the design. But this is about you, and about the game.

Several other communities have been very supportive of this project. The folks at RPGWatch, RPG Codex, Iron Tower Studio (More indie RPG goodness - also done with Torque!), Scorpia's Gaming Lair, RPGDX, and Game Banshee have been way, way cool and have offered plenty by way of both crits and encouragement.

You. Guys. Rock.

So - what's next?

Obviously, the Frayed Knights Pilot was just the first step. It served its purpose, as a scouting mission to see where I was on the right track and where I was completely in a different timezone from the right track. It was a complete game, albeit not a perfect one. We were able to get a lot done in a single year, and I'm very proud of it - particularly as my first released RPG (if you don't count Hackenslash).

Now comes the hard part - to make twelve times the game in less than twelve times the development time. Neither you nor I have the patience to wait twelve more years for its release. So what's it going to take? I don't entirely know the answer to this question. I have ideas, but not answers.

But this first chapter of the saga is completed, and I'm thrilled with what we've been able to pull off. Again - much of the credit goes to this and "neighboring" communities.

Thank you.


Wanna talk about it some more? There's a forum thread, even!

Labels: Frayed Knights

- posted by The Rampant Coyote @ 5:28 AM (Permalink) 17 comments links to this post

 
Frayed Knights: Dungeons Scrawls
Here's an update on the progress of Frayed Knights, the comedy-based indie RPG in development by Rampant Games.

You know, it's much, much easier to draw a map out on graph paper than it is to actually develop it as a full-fledged game level. Especially when you are not very good at the latter. The programmer in me wants to create a tool that will let me just draw the walls of a level (or adapt one of several programs out there that already do that), and convert it to a .map file. There's just one problem: The end result will look just as bad as what I'm already creating. It's all about the details.

As much as I'm trying to draw upon old-school pen-and-paper D&D for inspiration, there are a few things that just won't work. And frankly, the very 2D, rectilinear dungeons of yesteryear make very poor 3D CRPG dungeons. I remember Tracy Hicman, co-author of the Ravenloft module and the Dragonlance series, bringing this up at one conference (which I mentioned in one of my Wizardry 8 walkthrough articles) - old-school D&D dungeon design is boring and flat. I don't want levels to just be populated by practically random monsters, where you just kick the door down and find out what monster is behind it. While that is very old-school dungeon crawl, even back in the late 70's / early 80's, the dungeon crawls had a lot more rhyme & reason to them and theming than even many of the CRPGs of the 90's.

But before I ever even sketch out the map on graph paper, and long before fire up my level editing tool (currently I'm taking another stab at Torque Constructor), I need to have a very clear idea for each major level. I want these settings to stand out, not to be just random geometry with random combat. Players can get plenty of exercise doing that playing Diablo or NetHack (and even those games have some theming in their levels).

I have been going through this exercise for a couple of the upcoming dungeons I'm working on. For each one, and the outdoor areas, I want to answer these questions on paper. Yeah, it's design-doc-ish stuff, but a good exercise even as the only guy working on the project. And if I manage to contract Kevin or other unlucky level designers to handle some of the actual construction, they'll need this same kinda information

I'm going to use the Temple of Pokmor Xang as the example here, since ya'll have already played it and stuff. Assuming you could stomach it. It's gonna get better, I promise! :)


#1 - What do I want the player experience to be?
In the case of the Temple of Pokmor Xang, this was to provide an introduction and tutorial to the principle game mechanics of the game. The dungeon should provide a simplified view of the breadth of gameplay, and provide a representative sample of the quality of the game to come. It should also provide a good example of the humor and parody elements.

#2 - What is the physical setting of this level? What should be unique about it?
For Pokmor Xang, this was an underground temple used by evil cultist long, ago.

In more recent years, it was reclaimed by a different cult - the cultists of Pokmor Xang, a loser of a god - and a loser of a cult. The primary "set-piece" of the dungeon is the altar room, where the ominous statue of a dark god would ordinarily appear pretty impressive and scary. In PX's case, it's should appear lame, and comical in contrast to what the apparent "desired effect" would be. The entire level should reflect this - it's a much bigger, more impressive and potentially threatening setting than it really deserves to be.

#3 - What is the history of this area? How can this history be incorporated into game elements to make it more interesting?
There should also be some old signs as to the previous ownership of the temple. This actually didn't come through very well, and would need to be enhanced. There should also be some indication of why the PX cultists are here now, explaining the storyline to those who want to follow it.

#4 - What are the principle encounter types? Why are they here? What makes them different in combat?
For Pokmor Xang, the two principle encounter types are cultists (magic-using and melee), and their disgusting creations - pus golems. Brittlebone skeletons provided a minor break in the action. Kraltic Barg is the "boss" bad guy.

The big contrast should be in the player encountering what should be a major, scary evil cult, but it is more of a fifth-string cult of bumpkins playing at being evil and nasty. The boss himself, Kraltic Barg, should actually be a little bit scary and competent, but he's content with being a big fish in a tiny pond.

Unfortunately, those encounters have failed to provide enough of a distinctive feel in combat - something I need to remedy:

* Ordinary Cultists should be a pretty straightforward melee encounter versus humans - moderately hard-hitting, moderately good at soaking damage. Pretty much the baseline for an encounter.

* Priests should make things interesting with their usage of priestly magic. The players should learn a bit about the threat from casters.

* Pus Golems should be a somewhat more unusual melee encounter, easier to take down (especially with fire), but with an unusual special attack.

* Brittlebone Skeletons should be the cannon fodder of the level. They should appear in larger numbers, present little threat, and be chomped down like Doritos.

#5 - What are some other unique features of this level? What are the non-combat encounters / events that take place (besides the usual locks & traps)? We're talking tricks, puzzles, riddles, and non-combat NPC encounters here.
The meditation room turned out to be a very visually impressive room, and I wanted an "old school" fountain puzzle to be a simple interactive object encounter - a puzzle.

The torture room was simply different by nature of its function. In this chamber, I wanted a non-combat NPC encounter with a prisoner. I wanted it to be something of a parody of an old-school "trick" - the beautiful women held captive who almost always turned out to be a villain. Her true nature is only revealed later in town (though not in the demo). This encounter isn't quite working right.

The entry hall was just sort of a subtle joke by itself - a grandiose hall for a less-than-grandiose deity. While not an encounter, it stands out.

There's a secret door next to the statue. In retrospect, I think I need to draw more attention to it so that players can learn about "secret doors."

The collapsed stairway was a bonus provided by Kevin. I need to do more with it.

#6 - How is the player expected to progress through the level? What are the non-linear level progression options? Why should the player visit this location more than once? As a final bit of functionality which is not 100% working yet (I'm probably going to have to completely revamp the AI / encounter system for this) - I also wanted to make it so that skipping earlier encounters made the boss encounter more difficult. This was something of a "soft linearity" added to the level. You could make a beeline straight for the boss chamber, but you'll have a difficult lock to bypass, and you'll have a really tough final encounter. I'm not sure how well that played out.

There's also supposed to be a special encounter behind the southern door in the statue room that can only be reached later in the game on a subsequent visit. That's not in the demo, and I won't talk about it here.

#7 - What are some of the secrets / bonuses in the level?
There's a secret door by the statue, behind which most of the best treasure in the level is found.

The torture chamber is optional and holds some extra loot, as well as an NPC encounter that should pay off a little bit later in the game.

And then there's the southern door in the statue room.

#8 - What is the player's purpose for visiting this level? What is their ultimate goal?
The player is dumped here as the starting point in the game - starting with a bang. The player finds out, through character conversation and the journal, that they are here on a good ol' fashioned mercenary expedition to loot some item for a benefactor.

#9 - How does this level advance the main story arc? How does it advance any sub-story quests?
Sub-story: The players get introduced to their rivals by discovering that they are the SECOND adventuring party to hit this temple. The first group was far more efficient.

Main Story: Kraltic Barg has a benefactor who gave him the valuable jewels that are the object of this quest in the first place. And - this may be too subtle, I don't know - the player may note a room that WOULD have been a very explosive experience given Chloe's known preference for fire-based spells.


My actual answers are a little longer in the original design document, but not in this format. I didn't want to bore you too much by just printing them here. But nevermind the answers - how would you expand on these questions?

Wanna chat in more detail? Check out the forum!

Labels: Frayed Knights, Game Design, Roleplaying Games

- posted by The Rampant Coyote @ 10:09 AM (Permalink) 3 comments links to this post

 
Frayed Knights: Back From the Dead
So here's the latest update on Frayed Knights, the comedic indie RPG in development from Rampant Games (an older work-in-progress "pilot" available here).

Frayed Knights has been dead for a couple of weeks.

Not dead as a project, but for me, Frayed Knights has been non-functional for a couple of weeks. Merging my heavily modified 1.5 codebase for TGE and the 1.52 codebase for TGE plus the AFX special effects code, plus TGB 1.3 (the last version that was pretty compatible with TGE) overlayed on top of that felt a little like making a time machine out of a DeLorean. But since even a used DeLorean costs over $25,000, this option was more economical. Plus, I didn't run the risk of splitting up my parents before I was conceived and thus unmaking myself in a time-travelling paradox.

With the stress and long hours of the previous day job behind me (and let me tell you - the loss of that stress literally felt like the relief of a physical burden - I can't tell you how much BETTER I've been feeling the last three weeks), I've felt the strength and desire to proceed to the next phase of Frayed Knights' development. This allowed me to tackle the merge which I had been putting off. But the resulting problems frustrated me and reduced me back to "tinker" mode - I'd work on a map a little bit, make some design notes, add to my "wish list," and then go back to surfing the web and playing Wizardry 8. Yes, I can procrastinate with the best of 'em.

The saddest part? Fixing things, once I committed to doing it, only took a couple of hours. I am once again reminded that I work best on a milestone schedule, with a list of tasks I am (loosely) committed to completing by a certain date.

So what does this merge give me? Well, besides a bunch of bug-fixes and optimizations for a planned Mac build, it gives me access to some new and improved interior changes used by Torque Constructor. Since I've had some waking nightmares with the "legacy exporter" in Constructor, this will hopefully improve my content development pipeline. There are some improvements to lighting, particularly with static meshes.

And then there's the AFX code. In a nutshell, it includes a whole slew of changes to the decal and particle system - primarily, though there's more to it than that - that allow some pretty awesome spell effects. There's a screenshot to the right of AFX in action in the Torque demo.

With that done, I'm back to working on some core technology. I am considering some massive changes to how AI works, how combat plays, and how inventory management is handled. I also need to finish the journal system and the transition map system now that we'll have more than two areas to go between.

Since I work best committed to a deadline (it stops me from "tinkering"), for next week I'm going to finish the design work and the rough-out of the Tower of Almost Certain Death and the first wilderness area, get trading completed with NPCs, and get started on the revised journal system. That ought to keep me busy.

And I'm gonna get back to trying to post an update weekly (or at least semi-weekly), as I was before I went into soul-sapping crunch-mode hell. Public reporting of progress keeps me from falling back into "tinker" mode.

For those who haven't tried out the demo yet, community member Demiath has uploaded a YouTube video of the first five minutes of the Frayed Knights Pilot. Which I think is extraordinarily cool. Feel free to go there and comment on how cool Demiath is, or your predictions on how Frayed Knights is going to outsell Diablo 3 when it is done (hey, if you are gonna dream, dream big...). It also helps to watch someone else play the game to remind me what things I need to fix / improve. Here it is in all its embedded glory (you will want to switch to high-quality mode on YouTube to be able to read the text):



Thanks, Demiath!

And that's it for now. TTFN!

Labels: Frayed Knights, programming, Torque

- posted by The Rampant Coyote @ 8:35 AM (Permalink) 2 comments links to this post

 
Frayed Knights: The Tower of Almost Certain Death
I haven't been quite as regular with my postings about the development of the comedy-based indie RPG Frayed Knights of late, but the game does continue development, if not quite as quickly as it was the last few weeks before the pilot milestone. Obviously, we need a new milestone schedule. But I thought I'd provide a little bit of background on the world at large and chapters / adventures / locations in development.

Naturally, all of this information may change, and could conceivably not appear in the game at all. But here we go anyway. This week: The Tower of Almost Certain Death!

Originally, this tower was called the "Tower of Certain Death" by those few locals and adventurers who knew of its existence. Every once in a while some local youths from nearby towns who fancied themselves as adventurerers would discover legends of the tower, and mount an expedition to find and sack it.

Of the few expeditions that found the tower, most ended in the entry chamber, not with death, but with a lot of ale-drinking and graffitti-drawing to mark the accomplishment. Then the expedition would return home with tales of surviving the Tower of Certain Death.

At this point, jokes circulated renaming the old tower the "Tower of ALMOST Certain Death," as it was clear that merely entering the tower did not lead to instant demise. Those who remembered the old stories warned that it was actually ascending to the top of the tower that resulted in certain death, but as the young trespassers who had survived entry chamber parties maintained, the tower was in such poor condition that a lethal fall from the top when the floor gave out was a certainty.

However, the tower eventually attracted a group of down-on-their-luck adventurers. They discovered that the upper floors of the tower were not only in far better condition than the youthful entry-level explorers had guessed, but that they were inhabited - after a fashion. The former owner of the tower - a Wizard named Thermistale - had performed an experiment which failed spectacularly, transforming him and his apprentices into ageless, mindless monsters. Besides these entities, the tower had animated statues and traps designed to foil interlopers and government inspectors. And a great deal of the wizard's treasure had remained intact.

Once the "Tower of Almost Certain Death" had been successfully sacked, nobody bothered going there anymore. Those few who tried found that the tower was well and truly looted, with nothing remaining of remote interest to make it worth the trip. After twenty years, it faded from memory.

Rumors have recently surfaced that the tower has new inhabitants, though speculation rages as to whether or not the new inhabitants are monsters or a flock of birds.

Labels: Frayed Knights

- posted by The Rampant Coyote @ 7:55 AM (Permalink) 0 comments links to this post

 
I Didn't Know I Spoke Polish...
Wow, I'm multi-lingual!

Frayed Knights Interview on Onet.pl!

For those of us who don't speak Polish, and who are at all interested (don't worry, I wouldn't be either), I provided the original English translation of the interview in the Forum.

Labels: Frayed Knights, Interviews

- posted by The Rampant Coyote @ 3:09 AM (Permalink) 0 comments links to this post

 
Frayed Knights in PC Games Germany
Simon "Seminus" Bachmann sent me this scan from this months' PC Games magazine in Germany:


I really have little clue what it says, though I imagine it has something to do with games that really DESERVE to be banned...

I've gotten quite a bit of feedback coming from the magazine this weekend - about 50 more feedback forms. Most are fairly complimentary, but note the same kinds of issues that have already been cited (movement speed, interface, combat mechanics, etc.). A few chastened me to make a game that looks and plays like modern AAA RPGs, and a few complained about having to read so much (not an uncommon complaint, really).

Exciting stuff!

Labels: Frayed Knights

- posted by The Rampant Coyote @ 4:48 PM (Permalink) 6 comments links to this post

 
Frayed Knights - Going Deep
And here's the latest update on Frayed Knights, the indie comedy-based RPG from Rampant Games. The last couple of weeks this update has been erratic, happening on days other than Fridays, but I'm getting back on schedule.

It's amazing how fast a month can go by, isn't it? Well, this month didn't fly by quite so fast. I went from crunch-mode to get the Frayed Knights Pilot out the door, to crunch-mode at the day job. When all that was over, I was pretty exhausted and took a few days off with minimal work on Frayed Knights except to "putter" and read more of the flood of feedback results on the game. I'm now pushing 400 responses. That is a LOT to read. And I have read every single one. Some were quite extensive in their recommendations... others might have just been the default entries.

Overall - the reception has been pretty good. Not overwhelmingly positive, but I have been surprised by how few negative reactions I've received. Less than 5%. I assume people are just trying to be nice.

So, this last week I've been diving back into the thick of things. My brain is being pulled in two different directions, as I'm partly back in designer-mode, and partly in the thick of bug-fixing and coding up changes. Right now, the game needs more design work than coding, but I'm too much of a programming addict.

Okay, So It Was Broken and I Had To Fix It
For everyone who wanted the "Z" key to be a toggle for freelook, you've got it. It locks the cursor to the center of the screen when you do it, which means you'll be forced to hotkey everything rather than click on buttons... and you'll have to look directly at objects in the environment to click on them - but it works. Movement speed has also been significantly increased. It feels too fast for me, personally, so it may need to be adjusted further, but I also think there's a lot of speed-demon players out there for which this is not a problem.

Dynamic combat encounters have been somewhat overhauled. I'm still toying with having them appear in the environment (along with "static" encounters), but with that will be introduced bugs that will haunt me forever, so I'm holding off on that particular headache for a bit as a consideration but not a mandate. I have gotten rid of the old D&D style "wandering monster" system and replaced it by something that is more measured and predictable. In fact, right now the player can look and see approximately when to expect the next encounter. I would also like the "probable" nature of the upcoming encounter to be discovered early if your party succeeds in figuring out what is stalking them.

What's truly amusing here is that, the first time through an area, the "static" encounters will be more surprising than the "random" encounters.

Before release, I had implemented a system where the game tried to "remember" the last spellcaster, their last spell, and the last spell target. It didn't work as well as it should. I've not updated everything so that it remembers the last combat spell and the last non-combat spell for each caster, and defaults appropriately. This should speed up spell selection a bit, particularly if you are always casting Chloe's Hotfoot and Ben's Negligible Healing.

And then there's some miscellaneous clean-up I had to do, especially in combat. Which brings us to another subject.

Going Deep
From a mechanics perspective, people (including me) were not satisfied with combat. Part of this is because it was never implemented as fully as I'd intended, particularly with special feats and abilities for characters... and AI. The AI, in particular, was pretty stupid right in the pilot, firing off spells sorta randomly.

I've changed things around a bit. First of all, the AI is actually a little more predictable now - but with that predictability I'm also trying to make it smarter. AI may have a particular sequence they like to repeat over and over again in combat, depending upon situation, but they also won't heal companions that don't need healing, and other silliness. They will also be more aware of easier / harder / more dangerous enemies, and will attack accordingly based on their intelligence and creature type. This is a long-term change as the game progresses in development, and so I'll be taking a wrench to it on a frequent basis.

One thing that I had thought I had implemented - but apparently had not - was range issues. Attacking deep into the enemy lines is a lot harder (and more dangerous) than attacking something right in front of you. Weapons do have a reach / range factor, which was being ignored --- except to set a bunch of flags for whether feats that were not fully implemented would trigger or not. Except that wasn't happening either, as apparently I'd defaulted the distance to zero and completely forgotten about the little "TODO" there of calculating the correct distance. D'oh.

So now, if you are bare-fisted, you can only attack enemies that are right in front of you. Short weapons can attack creatures one rank beyond that, but at a penalty. Long weapons can attack either group equally well (though I'm tempted to put a smaller penalty for attacking the closer rank), and - at a penalty - attack THREE ranks removed. And finally, ranged weapons can attack any rank equally EXCEPT the ones immediately in front of you - where you get a high penalty AND may trigger enemy defensive feats.

For determining distance, it includes your own party. So Chloe and Benjamin are always at a distance of two from the front rank of enemies.

Plans In Motion
I will soon be evaluating the difficulty of merging the current code base with the latest version of the Torque Game Engine. I'm not particularly looking forward to that.

We've got a TON of content work we need to get done. And I'm not talking about that... at all... right now. :)

I am working on some missing functionality, like trading.

The spell casting interface... well, that's a big complaint, still. I still don't have a clean way of handling it. Many people are suggesting a simpler interface with the assumption that there will only be a handful of spells available. I originally planned dozens. So... the question is... do I shrink the number of spells down to make the interface easier for people, or do I keep the spell count up, realizing that - while streamlining may still be improved - it will leave spellcasting a cumbersome process? Or can I do some other tricks, like limit the number of spells a player has "memorized" for the sake of simplifying the interface?

Well, that's where I am. Whaddaya think?

UPDATE: Forum post on the subject available here (thanks Corwin!)

Labels: Frayed Knights

- posted by The Rampant Coyote @ 12:57 AM (Permalink) 6 comments links to this post

 
My Game Gets More Polish
Someone said in the feedback that Frayed Knights could use a little more polish.

Happy to oblige:

Frayed Knights Polish

(Yeah, I guess capitalization counts, doesn't it?)

I have no idea what it is saying. Possibly something unflattering about my ancestry. Which isn't necessarily untrue, mind you. But I just don't know.

Labels: Frayed Knights

- posted by The Rampant Coyote @ 3:04 PM (Permalink) 6 comments links to this post

 
Frayed Knights - Feedback Frenzy
And here's another weekly update in the development of Frayed Knights - the (arguably) humorous indie RPG coming from Rampant Games.

A couple of years ago, I wrote a couple of articles about a "red line" test for games. The idea was borrowed from a professional fantasy writer who spoke at a science fiction symposium I attended in college. In her writing group, when they'd peer-review each other's work, they'd draw a red line in the text where they - as a normal reader or editor - would have stopped reading for whatever reason. The idea, during revisions, was to keep pushing that line down, further into the story, until it disappeared altogether. Then it might be ready for reading by a real editor or audience.

I thought this could be applied to games, and that's a lot of what the pilot episode of Frayed Knights was all about. It was a rough draft of the first 'chapter,' if you will, and the feedback I've gotten back has been invaluable. I'm nearing 250 feedback responses so far, and I've read every one. Even had to have one translated from German for me (I only took two years of German in high school, and hardly remember a thing....)

As far as the red line goes, a vast majority went on to finish the episode, even though I felt - from their feedback - that there were a lot of issues that might have dissuaded them from playing all the way through. There's been some really clear responses - some with very long suggestions - as to what people would like to see changed. In some cases, I can't act on the suggestions, because it's just not that kind of game, or it would be cost-prohibitive. But the most common suggestions are

But where fixes can be made, I'm making 'em. Slowly. Not so much this week - between recovering from burnout from last week's mad rush to get the pilot out, to this week's crunch-time for the ol' Day Job, I've mostly been focusing my efforts on paper and planning. And I'm going back and playing some of the "old school" games I'm trying to emulate, seeing what sort of things they did so well (even if they'd not appeal to today's gamer).

The best news so far has been - as far as I can ascertain from the feedback - that the core idea behind Frayed Knights is solid and is appealing to a lot of people. There are lots of rough edges in design, interface, and mechanics that need to be fixed and polished, but overall, I feel pretty good about it.

Watch this space for new updates.

Oh, and while I'm at it - any other Torque developers out there - is DirectX support for TGE just as crappy as it seems to be in Frayed Knights, or did I somehow break something? OpenGL runs great, but DirectX is causing flashing polygons, bad lighting on some objects, and nasty terrain anomalies.

Labels: Frayed Knights, Game Design, Roleplaying Games

- posted by The Rampant Coyote @ 5:04 AM (Permalink) 4 comments links to this post

 
Frayed Knights Pilot Release Aftermath
I wasn't really trying to make a huge deal of the pilot - this was an experimental release to help gauge how we're doing while there's still time to make major corrections. Releasing anything like this to the public, and soliciting criticism, is not something I'd recommend for anyone who fears damage to their ego. Even when the really negative comments are in the minority, one sting wipes out ten praises. At least it does for me. But the purpose of the pilot and the survey is not to make the development team feel warm and fuzzy, but rather to give us an accurate picture of where we are and where we need to go. Like checking for directions at a gas station before committing to another 200 miles. It was to help us know what major and minor changes need to be made while there's still time to make them.

And the response in the last 24 hours to the release of the Frayed Knights Pilot has been incredible. I'm sitting with 80 survey responses so far, and climbing. The response so far has been overwhelmingly positive - better than I really expected, to be honest, as much as I daydream about making a game that absolutely everybody loves.

Better yet, almost everyone - especially those who offered strong approval of the game and it's overall style and flavor - has offered criticism of aspects that they feel need to be changed. Often extremely constructive criticism, with several paragraphs of recommendations and clear explanations of what they had trouble with and what they'd recommend to fix it. We're talking details worth their weight in gold.

I am - in a word - floored. But in a good way.

Hmm, I guess that was six words. My bad.

Thank you to everyone who has participated and continues to participate in the pilot and the survey.

We're gonna push forward with the full release stuff, but I suspect a "revised pilot" will be making its way out. Hey, FK testing crew, if you feel like signing on for another tour, I'll have need of your services again sooner than expected! For those who haven't received enough punishment...

I plan to continue the regular blogging on development as it continues. I started this thing as kind of an open-development thing, and I'm going to continue in that vein. While I have my own criticisms of game design failures and so forth, the neat thing about being a critic is that you can tear down the things you see without having to build anything of your own for other people to tear down. Doing this has exposed quite a few holes and issues of my own.

Moving forward, the most commonly mentioned issues with the game are these:

* UI - in a nutshell, there are too many button presses required to do something, especially in combat. As I kind of expected, spellcasting is still too cumbersome (I can say that it is FAR better than it used to be, for all the good that does...) People have more modern expectations for the UI, and I have to respond to it. A lot of the suggestions seem to mirror World of Warcraft's design, for some reason... go figger. Unfortunately, I don't know if the built-in Torque UI tools are up to the task, so I've got a lot of work on my hands...

* Movement Speed - this is a sensitive issue. People expect first-person-shooter speeds in first-person games. The "walking speed" in Frayed Knights is far faster than realistic - it's more like a real-world run speed. But people like to zip. Especially in the village or another safe place. I'd deliberately tried to slow things down to closer to Ultima Underworld speeds for Frayed Knights - a more deliberate "dungeon crawl" / exploration pace (at a good run speed, but still...) But it frustrates people. So I'm gonna have to come up with a happy medium.

* Randomness - there's too much randomness in the game, between the random encounters and the wildly varying difficulty of combat. People might mow down four groups of two cultists four times in a row, but then get clobbered by the fifth while at full health and endurance. And the random encounters - while usually paced reasonably, approached ridiculous "Final Fantasy" levels in some cases.

* Combat - not exciting enough. And not clear enough. The melee characters don't have enough options, and the effect of some of the spells is too subtle (due to randomness and lack of clear feedback) to really tell what makes a difference. And some of the balance is off, like endurance / resting. Some things we need to focus on include better / clearer options for the characters, easier target selection, feedback on the upcoming combat order (who is going to go next), and easier spellcasting.

* Feedback - just overall, there needs to be clearer feedback on what's going on in the game that the player can either control or react to. I knew this was a problem before releasing the pilot, but we lacked the time and resources to take care of it. But there needs to be better visual display of what's going on with all the little details in the game. There are a TON of details happening in the back-end number crunching, so much that even *I* don't know what's going on sometimes. That needs to be exposed, if it is important. And if it's not important - I should consider dropping it.

* The Music (And Sound)- I actually deliberately limited the music, partly because I thought the looping stuff was annoying, and partly because Torque was having some major bugs with streaming audio. People wanted more of it - the game is too quiet with this release. And in general, more sound effects are required.

* Movement Control Awkwardness - I tried (HARD) to make a game that was completely controllable with only a mouse. Either I botched it (and yeah, I probably did - even I don't play that way), or its simply not what most of my prospective audience wants. Straight WASD and mouselook (basic first-person-shooter controls) is high on the list of requirements, though it's going to make things weird for clicking on all the things on the screen when the mouse moves your vantage point instead. I'm probably going to settle on holding down the right mouse button to turn / look (or the "A" and "D" keys...) . Maybe I'll keep the old system around (with some refinements) as an option or something.

* Key Remapping - yeah, I know. I know. Everybody's got their favorite way of playing a game, and they want all games to conform. I'm the same way. This isn't a hard task, just a tedious and annoying one... but that's about 75% of making a game. It just kept getting bumped in priority.

* Character Creation / Customization - Character creation just isn't for this kind of game. It's a game about these four characters (and some NPCs). The customization comes with leveling, and I didn't have leveling included with the game. I'm not too worried about this, but I wanted to mention it here because it's clearly pretty key.

There are also lots of suggestions / issues that aren't as common, but they jibe strongly with my own feelings towards the game - or they just make sense - and I'll be addressing those as well. The above were just the most common issues.

Again - thank you to everyone who is participating in the pilot. While pleasing everyone isn't going to be possible for any game, the suggestions will help me to make a more enjoyable game. Assuming I'm up to the task...

Labels: Frayed Knights, Game Design

- posted by The Rampant Coyote @ 6:42 AM (Permalink) 18 comments links to this post

 
Frayed Knights Now Available!

FRAYED KNIGHTS PILOT: The Temple of Pokmor Xang

Now Available!

I'm not sure what else to say. You folks who have been following the development of this game - well, half of you have been helping me test, and the other half probably know more about the game than you would if you'd already played it once. But the pilot episode of the indie RPG Frayed Knights is now available for download. This is a short "demo" adventure - a single quest which should probably take anywhere from a half hour to two hours to explore.

Labels: Frayed Knights, Game Announcements, Roleplaying Games

- posted by The Rampant Coyote @ 1:47 AM (Permalink) 14 comments links to this post

 
Drama vs. Fun?
It's kinda funny - when my job makes me work all through the night until nearly sunrise, I get very annoyed. But when I do it to myself - meh, it's just what has to be done. But after this weekend, I hope you can understand if I'm a little on the snarky side. I think I'm averaging four hours of sleep a night, which is pretty low even for ME.

Gareth Fouche, creator of the indie RPG Scars of War, posted recently about trying something similar to Frayed Knights' "drama star" system. The reaction was almost universally negative. Even when the system is presented entirely as a "bonus" on top of the regular saved-game system, it's seen as a detriment.

How dare you even consider NOT saving my entire game state! Well, except the bad stuff. I don't care about you forgetting about that.

And it goes back to the whole story versus gameplay thing. Again. A perfectly well-played game makes for a horribly boring story. Who would like hearing about the hero who always wins, always makes the best decisions, never falls for a trick, has no flaws, and rarely even suffers a setback (and then it's always because of things beyond his control)? A guy who is a lantern-jawed, cool hero who - when the chips are down - becomes a lantern-jawed, cool hero. The home basketball team that suffers win after win, until a caring coach figures out how to bring out their best and teach them about teamwork, so they can start... winning some more.

BOR-ING!

That makes for lousy stories. Yet when we play a game, we're out to win. That desire to win makes us unwilling to accept the intermediate defeats and the ups-and-downs that make a good story. So designers force them down our throats with non-interactive cut-scenes, making it clear to us that no, this twist of events that makes things more interesting is NOT in our control, so it's "safe" to accept it and move on....

Now, in practice --- at least so far, and for the imminent-release of the pilot for Frayed Knights, I can't say that my attempt to recruit the player to the storyteller side of things with the Drama Star system has been an unqualified success. I think it has a subtle effect on the game in that direction, which is good enough for me. It's been a pretty divisive topic in theory, yet in practice I don't know if the testers (hey guys, feel free to speak up to confirm or contradict this...) actually found it to be that big of a deal in either direction. I know the system still needs some tweaking, and it will undoubtedly play a much bigger deal in the full release than in the pilot (in practice, currently, you are likely to face the "boss" encounter with only barely three bronze stars - enough to rescue ONE character from incapacitation, but they will have only one hit point left and be likely to drop in the very next round unless the battle is nearly over...)

Maybe I am wimping out and I need to make the drama stars an even greater influence on the game. But as a gamer who tends to devote only "casual" time levels to playing games these days, I really don't want to use golden handcuffs on players to lock them to the game, or to give players with only 20 or 30 minutes to devote to a game per session a crippling limitation.

I remember - as Gareth points out - how frustrating it got in Diablo II trying to find that stupid portal before I quit for the day. It wasn't like you really lost any significant progress by quitting without finding the thing... all the experience points and treasure you gained was yours to keep, even if you ended up repeating a level or two. In fact, from a purely mechanical perspective, it was really a non-issue. But it exerted a powerful force on players... maddeningly frustrating on one level, but also introducing a level of tension that probably improved the game overall on another level.

But here's the big question: It's really about fun, not drama. Dramatic tension can definitely increase the fun... But there is also a point (well, a fuzzy-gray area) where story interferes with the fun. Where playing-the-game - to win - is far more enjoyable then putting up with all those dramatic peaks and valleys. Where do you draw the line?

Labels: Frayed Knights, Game Design, Roleplaying Games

- posted by The Rampant Coyote @ 8:30 AM (Permalink) 9 comments links to this post

 
Frayed Knights Pilot: 48 Hours To Go
It's almost 9 AM as I write this. I haven't slept yet. I've been working on the Frayed Knights pilot all night long.

I'm watching the upload bar slowly climb on beta 2... 75%... 76%.... 77%...

Someone's already posted a major bug in Beta 1 this morning that hasn't been fixed... so I guess Beta 2 isn't quite ready for a "release" yet. And some minor issues. I need to get some sleep. Go to church. Hopefully not at the same time. And then get cracking on it some more. I've got approximately 48 hours as of right now. Or less. A magazine in Germany needs it before close of business on Tuesday... what time zone are they in?

Yeesh. My brain is fried.

My private little victory is that I got the compass in. Was it worth the two hours I spent last night working on it? I hope so. It looks cool. I need more help text. Oh, and real documentation - or something resembling real documentation at this point. And I need to get the web survey up.

All in 48 or so hours.

Okay - the uploading is complete, and I'm notifying testers. And then... a short nap. If it's too short, it might be worse for me... less than 3 hours of sleep makes me groggier than I am without sleep at all.

Catch ya on the flip side!

Labels: Frayed Knights

- posted by The Rampant Coyote @ 7:54 AM (Permalink) 2 comments links to this post

 
Frayed Knights - Pilot Release Hours Away...
More Tales from the development of Frayed Knights, the indie RPG of humor and high fantasy.

There really ain't much to tell. Not that this has ever stopped me before.

My drop-dead date is Tuesday. I need to get the file to a magazine on that date. I'm trying to get another beta out tomorrow-esque for the testers to hammer on. There's so much I wanted to get in for this release, but won't make it. But I think the game is fun, and will do a good job of what it's intended to do - solicit feedback, and gauge the reaction of players.

The automap is back in, and better than before. This was the biggest, most critical task I've been facing, one that I wanted to get in before Beta, but failed to pull off. Aside from that, and implementing a few very minor suggestions, I'm focused entirely on bug-fixes. Doors that don't work right. Scrolling on the party inventory that isn't functioning properly. Etc.

The biggest frustration at this stage of the game is that things are progressing excruciatingly slowly. I'll be very glad when this pilot release is done and we can go crazy again with content. I expect the game WILL metamorphize somewhat in its core code based on player feedback. However, my hope is - now that we have a semi-stable game, it'll be content city. Scripts, dialogs, maps, monsters, treasures, and character progression, baby!

Watch this space for the announcement of the public release.

Labels: Frayed Knights, programming

- posted by The Rampant Coyote @ 2:45 PM (Permalink) 2 comments links to this post

 
No Indie Night For Me
Blame it on the testers.

With the time until the public release measurable now in HOURS, I'm trying like crazy to whip Frayed Knights into shape, and the testing team has left me a mountain of jobs to do.

For which I really am grateful. I need all the help I can get.

But with the events of this week, I'm finding myself short on time. The Utah Indie Night is tonight, but I'm having to give it a miss - for the first time ever.

Bummer.

Time to hit the ol' dungeon again. Utah indies, have fun and enjoy the pizza!

Labels: Frayed Knights

- posted by The Rampant Coyote @ 5:43 PM (Permalink) 4 comments links to this post

 
Frayed Knights: A Beta Odyssey
Sitting on the sidewalk, watching water pour out from under the sidewalk and the lobby of one's place of business is (hopefully) one of those weird, once-in-a-lifetime experiences that really makes you wonder.

Like wondering, "Crap, am I gonna have a job to come back to?"

The answer is apparently yes, as it's back to business as usual this week (with perhaps a weekend or two of extra work thrown in for good measure). However, it almost gave me an extra day and a half to work on Frayed Knights. It would have, if I hadn't lost yet another video card one night. A few hours of the following day were devoted to discovering the problem, acquiring a new card, and installing it.

Total gain in dev time: About the same amount of time I lost the previous weekend due to the mandatory overtime.

Well, either way, I managed to get the beta out. We've got about a week to get cracking on it. There are a ton of additional features and improvements I want to make in the pilot already. And maybe I will. But our first concern is making sure it is fully playable and stable, and accomplishes the goals of a pilot episode - which is to solicit feedback.

Some changes that have gone in over the last week or so:
-----------------------------------------------------------
* Bug: Zone exit to Ardin only works once (or doesn't work after load?)
* Fireball - Incindiary Crackleball added
* Fixed bug: Silas ignored party after Benjamin's confession
* Fixed Interactive Object dialog title width
* Fixed missing portrait for Benjamin when targeted after incapacitation
* Fireball wand for Chloe
* Fixed getting stuck inside door bug.
* Fixed autonomous dialogs
* Fixed load game at game-over
* Added Angry Flower spell
* Changed Silas and Hoss skins & portraits
* Added Fireball Wand Dialogs
* Added potion of recapacitation + recapacitation effects
* Added Frayed Knights website jump at end of game
* Enter Key and ESC key in all dialogs
* Prevented player from hopping the railing to talk to Silas and avoid talking to Florentine (although I'm really conflicted on that one... I may put it back in once I come up with some alternative dialogs with Florentine and Silas).

Times they are excitin'.

Expect a public release in 1 week.

Labels: Frayed Knights, Roleplaying Games

- posted by The Rampant Coyote @ 8:19 AM (Permalink) 4 comments links to this post

 
Frayed Knights - Pus Golem for D20
And now for this week's update on Frayed Knights, the humorous independent RPG from Rampant Games. Here's one for the dice & paper gamers! Actually, at some point I'd like to turn the entire Temple of Pokmor Xang into a paper module, but for now, here's the Pus Golem!

Pus Golem Small Construct
Hit Dice: 2D10 +10 (21 hp)
Initiative: +1
Speed: 20 ft (4 squares)
Armor Class: 12 (+1 Dex, +1 Size)
Base Attack / Grapple: +3 / +1
Attack: Slam +3 melee (1d3+2 plus Festering Wound) or club +3 melee (1d6+2)
Full Attack: Slam +3 melee (1d3+2 plus Festering Wound) or club +3 melee (1d6+2)
Space / Reach: 5 ft. / 5 ft.
Special Attacks: Festering Wound
Special Qualities: Construct Traits
Saves: Fort +0, Ref +2, Will + 0
Abilities: Str 14, Dex 12, Con -, Int -, Wis 11, Cha 1
Skills: ---
Feats: ---
Environment: Any
Organization: Solitairy or Gang (2-6)
Challenge Rating: 2
Treasure: None
Alignment: Always Neutral
Advancement: 3-4 HD (Small), 5-8 HD (Medium)
Level Adjustment: ---

This disgusting, vaguely humanoid mass stands about four feet tall, possesses the color and oder of a festering, oozing wound, and has skin the consistency of congealed blood and pus. Its jaw hangs loosely from it's distorted skull-shaped head, and vein-like streaks of blood flow slowly in a sparse webwork around its quivering, misshapen body.

While the creation of a golem is more usually in the province of powerful arcane spellcasters, often constructed of hard, inorganic materials – clay, stone, and metals. However, certain sorcerers and priests have learned that shortcuts can be taken. Golems made of weaker, more flexible materials are easier to create, but correspondingly weaker and less useful. Golems made of materials formerly part of – or manufactured by – living bodies require even less magical effort to animate, as the remaining life energy within them can help power the spell. However, few but the most demented or vile spellcasters of society would stoop to such levels. Examples include flesh golems, constructed of several fresh corpses sewn together, and bone golems, constructed of the skeletal remnants of animals or even humans.

Then there are some less common but equally vile varieties of organic-matter golems, such as pus golems, snot golems, and the dreaded dung golem (of which only one has ever been reported in an apocryphal adventure account, but that one occurrence has haunted the nightmares of adventurers for decades).

The pus golems are particularly favored among priests of Pokmor Xang for a number of reasons. For one, few of such priests ever reach levels of divine power where they'd be capable of creating anything else. As servants of the god of boils, blisters, and pimples, they tend to have an ample supply of pus required for the creation of these monstrosities. And third, they are used to the smell.

Combat
Pus golems are more frequently employed as servants rather than combatants, but in combat they are fearful opponents, primarily due to the level of revulsion they cause in their opponents. Veterans of battle against these creatures claim the smell takes days to go away, though this has no in-game effect.

Festering Wound (Ex)
Wounds caused by the pus golem's slam attack become infected with a low-grade cocktail of whetever infections and diseases were the source of its raw material. As a result, all damage caused by the creature's slam attacks take twice as long to heal, or require 2 hit points of healing to cure 1 point of damage. Remove Disease eliminates all Festering Wound effects, though the damage remains and can be healed normally. A Heal spell instantly removes all Festering Wound effects and heals damage normally.


Oh, and while I think I'm violating the D20 license by not including the full license here as part of this post, Pokmor Xang and Frayed Knights are designated Product Identity and property of Rampant Games. Licenses and copyright notices for the D20 License and OGL license can be found here.

Frayed Knights Development Update:
Well, things have gotten really weird. The day job mandated some pretty hard-core hours last week, which cut into dev time a little bit - but then a water line broke yesterday and flooded the building, so I find myself with a couple days off to spend finishing the beta for Frayed Knights. I intend to get the beta out tomorrow (instead of today), and the public release will probably be out next weekend at some point. The game is getting a lot cleaner, but the testers are identifying a bunch of issues - many of them design and interface issues - which have taken up a lot of time to correct.

A lot of time this week was also spent cleaning up Ardin village and making it look nicer. This involved fixing a lot of models that were, for some reason, not reacting well to the fog. But here's how the village looks now:


In addition, some of the NPCs have gotten a facelift - particularly Ol' Hoss (who actually looks older now), and Silas. I'm throwing in new sound effects today, so the chests don't sound like opening doors. Wands are working, and I think I can get some scrolls working before the end of the day. Because I want to treat the beta as if it is a release candidate, I'm going to try and add nothing new to the beta between its release and the public release.

And once again - the final version of Frayed Knights may differ quite a bit from the pilot. This is my chance to get some major feedback on the game.

Labels: Frayed Knights, Roleplaying Games

- posted by The Rampant Coyote @ 8:15 AM (Permalink) 4 comments links to this post

 
Frayed Knights: The Oncoming Dragon
More development diary stuff for Frayed Knights, the comedy-based indie RPG.

"The light at the end of the tunnel may be an oncoming dragon."

I saw that on a button once, as a kid. As a sci-fi / fantasy / RPG geek, I nearly bought it. It was a pretty lame word substitution for a more common pessimist joke, and I was broke, so in the end I opted not to buy this little bit of geek flair.

But it feels appropriate now. I just made the last "alpha" available to the testers (hey, testers, it's up, check the testing forum!). I call it an "alpha" because I'm still adding some new stuff to it, though with the help of the testers the bugs are getting pounded into some level of submission resembling a mid-beta (I think). But the testers are getting weary of testing the same game week after week. I expected this, Which is why I staggered out the testing groups.

The saved games from the last alpha were by far the largest source of bugs so far. I expected as much, but it has still been a pain hammering them out. As of this morning, I think I have all the save-game related issues resolved, but there could easily be more.

The next release - next week - will be our beta. Hopefully the one and only, but if any major bugs are found, I'll do a quick revision within 48 hours. Otherwise, my expectation is that the release of the pilot will be on or around the 25th. The short beta will hopefully be offset by the long alpha.

And then the oncoming dragon hits me.

There is a lot that isn't there that I hoped would be. There are a few things that I'm afraid will draw most of the attention from players, instead of other areas I'd like people to provide me with feedback. There are features I wanted to get in, and suggestions from testers I really want to implement, but I'm just out of time. That's how it always goes, though. Games are never truly finished, only released. I could keep working on this for a decade, and it would still not be "quite ready yet."

The effort I get to put in now is as much to support the release as to actually work on the game. stuff like updating the Frayed Knights website. Adding a feedback form. Getting the installer working. Finishing up the documentation. I really want to be moving on, implementing more of the requested features so far and adding the new content for the full release... but this milestone is my master right now.

For those who might be curious, here's most of the stuff that went into alpha 4, not including some minor tweaks and bug-fixes that I failed to record:

* Player now moves a little bit faster
* Fixed Bug: Front-End Music was... Whacked
* Switching between full-screen and windowed fixed res changes
* Resolution forced to 1024 x 768
* Forces full-screen if desktop size is 1024x768
* Fixed some Dialog typos
* Fixed non-container loot awards
* AI can now cast spells
* New Monster: The Pokmor Xang Priest (priest-class enemy)
* Fixed Crash on reloading saved game multiple times.
* Implemented "Curses!" spell
* Fizzles now end a character's turn
* Monster names should reflect targeting name.
* Reset drama point level on reload
* Monsters no longer attack in the middle of trap / lock dialog
* Cleaned up component connections between trap screens
* Added some minor loot to the front entry area to reward exploration
* Cancelled Drama Effect no longer consumes drama stars
* Cancel button on character selection menu no longer cut off.
* No longer force combat completion after phase 200 (old test code)
* Added Hotkeys!
* Traps: Game now chooses best default disarming character.
* Empty Bag in front hall was removed.
* Fixed disappearing item bug
* Improved drama point award for more difficult combats
* Certain events (like reaching the statue) now have an XP award
* Added Liquid Nap potions
* Fixed Pokmor Statue bug not appearing on saved games
* Escape and Enter Keys now have default actions across in-game dialogs
* Major clean-ups to world reset on load
* Fixed crash when changing zones after a load

There is a lot of work that needs to be done for the beta. I still have a list of bugs to get squashed, and there are a few features that I'd like to get into the game but which I'm not sure will make it. Things like buying and selling equipment; the leveling-up screen; improved UI art for submenus; a compass; the automap overhaul; new items (including Chloe's fireball wand); a couple of new spells; some additional hotkey commands to speed gameplay; lots of TLC for Ardin Village; additional interactives in the temple of Pokmor Xang; better combat balancing; sound volume corruption in the Torque engine; lighting optimization in the Torque engine; dropped loot for certain bad guys (that's half-implemented); and a lot more. As you can see, with only two weeks left to release, not all of that's gonna be in there.

But even so, I'm not unhappy with where it is right now. And I have to admit - as exhausting as this is, as crazy as it makes me... I really am having a good time making it.

Hopefully you'll like it.

Labels: Frayed Knights, programming, Roleplaying Games

- posted by The Rampant Coyote @ 9:01 AM (Permalink) 0 comments links to this post

 
Frayed Knights - Artificial Stupidity
More tales from the development of Frayed Knights, the humorous indie RPG!

After a nasty little delay due to circumstances beyond my control, we delivered Alpha 3 of the pilot this week. And all was well. Unless you ask the Frayed Knights testing crew. THEY can give you an earful of what's not-so-well.

D'oh.

Ch-Ch-Ch-Ch-Changes
Since it's still an alpha and not quit beta (2 weeks?), I'm still adding a few new features. Well, "new" meaning, "was kinda there but not fully functional." This week's additions included some more "dungeon dressing" - in this case, some storyline elements that point towards the larger plot of the full game. Some tiny hints as to what is really going on.

Also, I made encounters more flexible, so they can more easily include mixed groups of creatures. This was already being used in a special case - the battle against the "boss," the "Evil High Priest" (EHP) Kraltic Barg. Now there's a mixture of spell-casting priests in addition to the more warrior-based monks inhabiting the temple. This was accomplished by the tried-and-true advanced technique of swapping their colors around - or, actually, their textures. See, they are wearing BLUE and YELLOW robes! How very different, huh?

And then there's having the enemies actually cast spells, which they are doing now. They are a bit too random with their spellcasting right now (as they are with their attacks), but every enemy who has spells now has a selection of spells they will draw upon in combat. Yeah - that's artificial intelligence! Or, rather, artificial stupidity.

Speaking of randomness, another report from the testers is that the game is too easy one session, too hard the next. In other words, randomness is playing too large of a role. To combat that, I'm going to put a curve in on the damage and healing done so that they will trend more to the average.

And then there are the bug-fixes. Hoo, boy. The bugs. Some are small - like the enemy health bars overlapping the information window in the picture displayed here. Some are quite a bit larger - like the game crashing on saves, and some elements not resetting properly. I'm knocking them out as quickly as I can, but the testing crew is doing their job admirably. They've also offered a lot of great suggestions which I am trying to implement where I can. But time is running out.

One thing I'd like to add this weekend is to implement wands. I'd like to give Chloe a wand of fireballs with only a couple of shots left - but good for inflicting incendiary pain on a group. Something that's bugged me for a while (and one thing a tester pointed out) is that she's got a reputation for blowing things up, but the spells at her level are too nicely balanced to let her do that. So having an almost-used-up wand of fireballs with just a little usage left will do a nice job of explaining some of that, AND give the player a nice "panic button" type weapon to deal with larger groups of enemies in the temple.

Content Updates
On the content front, Kevin has put together a new and improved dungeon that appears to run a bit faster. Digging into the details of how Torque renders interiors, he discovered that many of his assumptions concerning visibility and optimization, based upon how Quake-style engines handle these things, were entirely incorrect. Since those were my assumptions too, this was kind of depressing. But unless I feel like re-writing that part of the engine, we're stuck with these limitations.

James has been working on the icons for the trap / lock interface, new skins for NPCs found in the tavern in Ardin, and sound effects. These have made a phenomenal difference in the game already.

Mike has a new version of the Frayed Knights main theme done. His other projects are also demanding much of his time, but he's managed to devote some effort into it so we have some great custom music instead of just licensed stuff.

What's Ahead
There are a couple more changes I want to experiment with for the pilot before I go beta with it, but for the most part, as of right now I'm looking at bug-fixes (they'll never end!) and work on the full version. The testers are asking for an example of leveling up a character, so I'm going to try to sneak in the opportunity to take Benjamin "up to" the same level as the rest of the Frayed Knights. There's not THAT much to it, so it should be easy. Right? Right?

Discuss This On a Recycled Forum Thread! Save Electrons!

(Vaguely) related silliness:
* Frayed Knights Release Update
* Frayed Knights: Beating Up Is Hard To Do
* Frayed Knights: Poor Spelling
.

Labels: Frayed Knights

- posted by The Rampant Coyote @ 7:03 AM (Permalink) 4 comments links to this post

 
Frayed Knights Release Update
For those who were signed up for testing Frayed Knights, the third alpha release came out Sunday night. Unfortunately, due to circumstances beyond my control, development was all but halted for two weeks during alpha so that I could devote all my waking hours to the folks that provide me with the means to pay my mortgage. This was about 10 days longer than the crunch mode was planned, so the impact to Frayed Knights' development was... uh, about two weeks.

Sure enough, on Monday, I got slammed with a tall stack of bugs and suggestions from the Frayed Knights alpha test crew, for which I am grateful. But I'm also very busy. I expect at least one more alpha to come out in about a week to ten days, and with *luck*, I'll be able to come out with a public beta release of the pilot shortly thereafter.

Also during this time, I need to get some more outlining of stuff needed for the post-pilot development stuff to the dev team. I've got a dizzying array of notes, outlines, and dialogs that all need to be pulled together into something cohesive. And I'm getting a lot of feedback even now that suggests things I should change for the full version which may not be able to make it into the pilot.

Once again, I gotta hand it to the testing team. They've been awesome, and have been very supportive while also not holding back on the bug reports and criticisms. That's exactly what I've needed, and you guys have my thanks.

Labels: Frayed Knights

- posted by The Rampant Coyote @ 5:52 AM (Permalink) 2 comments links to this post

 
Frayed Knights - Save Me!
More on the development of the indie RPG of high fantasy and low humor, Frayed Knights.

This week I came to the end of the day job's "crunch mode." I'm still in something of a recovery state. Unfortunately, the two weeks of crunch pretty much threw off FK's schedule by a similar amount. I'm still cranking away at getting alpha 3 out this weekend, but there won't be enough time to test it in order to make an April 1 public release.

Please, Save My Game!
But it was time to crank up the blues on iTunes (in this case, John Lee Hooker's "Boom Boom,"), roll up the sleeves, and get back to work making up for lost time. My focus has been on certain top complaints from testers. The lack of saved games topped the list.

Saved Games are working - finally. And fully. I think. I've had to make some changes to properly allow for all the other zones the game is about to incorporate beyond the pilot. One thing that IS massing is map information right now. Gotta work on that.

Which leads to a whole new headache, actually. Multiple headaches. The automap needs serious fixing, and won't be working right in the next alpha. One more reason why it won't be ready on April 1st.

Some Other Changes
Two more top complaints from testers has been mouse inconsistency between dialogs, and the spell screen not retaining it's previous settings for casters and targets. I got that fixed. One thing testers may not be so pleased with is some of my changes to combat - specifically, armor and weapon restrictions and limitations. Yeah, before you could throw chain mail on Chloe without a problem. Now, she won't wear it without having a feat (hey, it's heavy, and chaffs!) to do so, and even if she does have the light armor feat (yeah, chainmail counts as "light armor" in Frayed Knights), it will penalize her spellcasting and increase the likelihood of a fizzle.

I'm making a few more changes to combat to make it behave a little more clearly (I hope). And for the alpha 3 release, I'm trying to balance out experience point and drama point awards a little better.

On the art front, James has been frantically coming up with improved visuals for the trap / lock screen, some concept-ish art, and some new skins for some of the NPCs. Kevin's been cranking away on a farmhouse-with-a-secret. And I've also been working on some miscellaneous dialogs and story text.

Interview, Attention, and Drama Stars
The big news this week was the Frayed Knights interview at RPGWatch. This has been picked up all over the place, and possibly brought even more attention on it than I'm fully comfortable with at this point. Sure, I want a nice cross-section of players trying out the pilot in April and providing me with feedback on issues. But I really don't want people playing it with a belief that it's a full demo for the final game. It's like... a prequel. Well, really, it's like a pilot. Hence the name.

A lot of focus from various sites has been on the drama star system. That is something I really AM comfortable with. Hopefully with the alpha 3 build, I'll get some more feedback on the drama stars based on some of the improved balance (hint: When you are fighting the BOSS ENCOUNTER, you should get more than a single drama point...). I've been playing with it a little myself, and while I am sure (by design!) it won't replace the use of reloading a saved game to recover from disaster, I think it works nicely enough to reduce trivial reloads.

One of the tougher questions that gets brought up is near and dear to my heart: What about those of us gamers who have a real life and can't devote enough time to a single session to really build up a fabulous collection of drama stars capable of "resurrecting" the entire party from the brink of a TPK (Total Party Kill)? Those of us who play in little twenty-minute increments and then must save and quit? Is that unfair?

Well, yes and no. Yes, you may not often get the full benefit of the drama star system. But - if you are going to quit and know it, you can go ahead and commit your drama stars before you exit - clear off a couple of curses or reduce the long-term fatigue on Benjamin before you exit. So you can use 'em before you lose 'em.

Alpha Testers - I'm gonna have EVERYBODY on the alpha test list added for alpha 3 this time around, so if you have already signed up, be sure and check out the forums.

Forum Discussion

(Vaguely) Related Stuff:
* Frayed Knights: When One Door Closes...
* Frayed Knights: Solving the Saved Game Problem
* Ye Olde Saved Game Debate

Labels: Frayed Knights, Roleplaying Games

- posted by The Rampant Coyote @ 5:00 AM (Permalink) 2 comments links to this post

 
Frayed Knights Interview at RPGWatch
Well, now I've gone and done it!

There's an interview with Yours Truly, where I am as verbose as usual, up at RPGWatch. The focus of the article is on that roleplaying game that may be destined to prove I don't have a clue what I'm talking about when I talk RPGs.

Warning: Do not use while driving or operating heavy machinery.

Frayed Knights Interview at RPGWatch

Labels: Frayed Knights, Interviews

- posted by The Rampant Coyote @ 5:54 AM (Permalink) 0 comments links to this post

 
Frayed Knights - Be 'Fraid. Be Very 'Fraid...
It has been quiet on the Frayed Knights front this week, mainly because I've been coming home from work at 2 in the morning, crashing for six hours, waking up, throwing together a blog post and maybe 5 lines of code for the game, and going back to work.

All that being mangled, one of the nice things about actually having a team in place is that things have actually been getting done. Without me. Scary.

Kevin has been hard at work on one of the next areas beyond the pilot. Giant rats are involved. These aren't your regular giant rats. He's also touched up the texturing on the inn in Ardin. James has been cranking away at additional sound effects, so maybe now not EVERY container and door will sound alike.

Mike has provided me with the drafts of two new musical themes, one for a new main theme and one for a dungeon exploration theme. Now I just have to fix background music (AGAIN!) to make it behave.

For my part, I've cleaned up a couple of bugs, had one that I THOUGHT was clean come back and bite me on the butt (see above, re: background music), and been putting in a few minutes into the saved-game system. Yeah, still. If I could get a full 8-hour day to put into it, I could pull it off. Like - hey, today. Work, in their mercy, gave me the day off. Well, the part of the day AFTER 4:00 in the morning, when I stumbled in the door.

So - I'm off to get stuff done in Frayed Knights. Talk atcha later!

Labels: Frayed Knights

- posted by The Rampant Coyote @ 10:09 AM (Permalink) 0 comments links to this post

 
Frayed Knights - When One Door Closes...
For once, I'm going to try to be... well, less verbose in this week's design diary for Frayed Knights, the comedy-based indie RPG.

The big task this week was to get the dungeon re-entrant, and to get save games and load games working. That's right, we're in alpha, and saves and loads aren't working. I was actually considering leaving them out for the pilot (after all, it's relatively short), but the cry of horror from my alpha testers convinced me of the error of my ways.

I spent a lot of time fixing other bugs, and making sure things like armor penalties on spellcasting actually worked. But the re-entrant dungeon had me stymied for a while. What I didn't realize is that Torque is very good about cleaning up after itself between maps. Really good. So good that it will erase all of your in-game data objects for you unless you come up with a special way to prevent it from being destroyed. Woops! So things like inventory, state flags, loot lists, and the like were being completely erased when you left the dungeon. If you went to the village and then came back, almost everything was restored to its original values - you'd have to start over again.

The cool flip side of this exercise is that its also helping me track everything that needs to be stored in the saved game. I'd tried to keep some of that data separated out in the past, even creating some incomplete data-saving functions for things like the game state flags that track events in the game. So I hadn't been completely neglecting this area.

Unfortunately, just as progress was being made and the problem looked *barely* solvable by Friday (which I've set up as "alpha day" for the testing group), the ol' Day Job came through with a mandate for massive overtime this week... twelve hours a day, Saturday included. It's on a short time-frame, fortunately, but to say it impacted my Frayed Knights development schedule is an understatement.

With luck, I may be able to get Alpha 3 out (for those involved in alpha testing, especially those still waiting to get involved) on Wednesday or Thursday, and then Alpha 4 may go out on Monday or Tuesday of the following week. That will probably be the final alpha.

Due to requirements of the competition I'm participating in, the release date for the Frayed Knights Pilot is still going to be April 1st (if not the day before). It may still be a little "beta" (or a lot "beta"), but that's kind of the point. I have been getting a ton of great feedback from testers so far, and this has really helped me figure out some overall changes that may need to be made to the full release. The engine is getting made more solid every day, so hopefully the April release won't be too horrible.

Labels: Frayed Knights, Game Design, Roleplaying Games

- posted by The Rampant Coyote @ 5:02 AM (Permalink) 5 comments links to this post

 
Frayed Knights - Alpha 2 Laundry List
Boy, this week's installment of the Frayed Knights development diary will have you on the edge of your seats!

Okay, I lie.

It's not particularly exciting. I haven't actually heard many people singing the praises of the first alpha, which always makes me assume the worst. "Aw, crap, the game's a dud. NOW what?" There WERE a lot of bugs - about half of which I was aware of (though I had failed to record them all). I actually have enough bugs to carry me through an entire second week of alpha... but the sooner I know about other bugs, the better. On top of this, there are a bunch of suggestions (especially with the interface) and other last-minute enhancements I'd like to make before this goes "final."

Game development is just SO thrilling and glamorous.

DGM did make the comment that for someone who has been reading this series from the beginning, there weren't a whole lot of surprises. I think that will be an additional focus over the next two weeks - throw in some surprises. :) There are a few plot-development elements that I left out of the pilot that I want to squeeze back in.

Anyway, if you were in the first alpha group, the new download is available. Check the alpha forum for instructions.

I'll be adding people to the second alpha group today. Check your emails and private messages on the forum. I expect the alpha 1 group is gonna be all burned out after playing through one or two alphas, so I need some fresh eyes on things. If possible - keep track of how much time you spent playing (I really should automate that). Even though it's not a great estimation due to the lack of save and load functionality right now, it helps.

Sorry for splitting up the alpha into groups like this again... but having done a bit of testing myself in the past, I know how hard it can be to aggressively hunt down bugs in the fourth or fifth build that you've seen.

Outstanding major issues remaining in Alpha 2

• Temple is still not re-entrant (meaning when you go back, things aren't left the way they were)
• Save / Load games still non-functional (and still crash the game if you attempt to load a saved game)
• Inventory is still disappearing when you transition between zones
• Priests are not dropping random loot
• You can get stuck inside doors
• No buying / selling with vendor
• Hotkeys for pendant commands
• Priests not casting spells
• Item descriptions do not include stats
• Character Sheet doesn't reflect stat bonuses due to equipment
• Journal needs to update when quest completed.
• Need to fix the automap
• Removing an item from the bottom of the party inventory causes some weird inventory behavior until you close and re-open the window.
  

Fixes in Alpha 2 (at least all that I remember)

• Particles for all (current) spells
• All drama star effects are now working and use points properly (I think)
• Inventory Items are scrolling now
• Skeletons and treasure by cave-in
• More stuff in Kraltic's Room
• Bad guys in front of torture chamber
• Bad guys in front of meditation room.
• Fixed loot in pantry in food prep room.
• Current character frame pushed back and textured
• Fights through doors now force player into good visible position
• Barrel in middle priest room #2 made interactive
• Trigger zone encounters force player into appropriate position for combat.
• Fixed description and dialog of pool to repair typos, special characters, and to assume Dirk has a 10' pole to jam down there.
• fixed several typos
• Changed "K.O." to "Incapacitated" and make it separate from picture (and always up)
• Forced window / full screen to 1024 x 768
• Added base colors to Benjamin Sly portrait
• Fixed in-game options menu bug
• New texture on inn roof

That's all I've got the brainpower for this week. It's been one of those weeks...

Labels: Frayed Knights, programming

- posted by The Rampant Coyote @ 3:02 AM (Permalink) 7 comments links to this post

 
Frayed Knights: Going Alpha
More tales of the development of Frayed Knights, the comedy RPG. Or more specifically, the Frayed Knights Pilot - The Temple of Pokmor Xang!

This Week
I could tell you what I worked on this week. Which is to say, a little bit of everything. Just getting it so that the game could be completed from beginning to end without any major weirdness or bugs, up until the final "end game" menu (including stuff happening in town). I just got some new music AND a new tavern model, which required me to re-arrange everything in the tavern to suit. I really like the new tavern. A lot.


Last Minute Changes
I took Friday off, both for getting this alpha out, and for attending a wedding of two close friends of mine. This has turned out to be a good thing. Between the alpha and a bit of personal business, I ended up pulling an all-nighter, until past 6 AM. Most of the time was spent working on some major inventory screen bugs. I missed them back when there was only about a dozen things in your inventory, but with there being actual loot in the dungeon now, I discovered some problems.

I also devoted some effort to fixing odds and ends, and prepping the whole thing for alpha. I had to make some dialog changes (and I don't think all of the revisions actually made it into the alpha... oops!). There were way too many "known issues" that I just couldn't get to, but I needed to get people on the alpha. Some of the changes thrown in during the wee hours of the morning were pretty significant. I made some changes to how resting is handled that I still don't know the full impact of. And I know for sure the feedback mechanisms for some of the mechanics are woefully inadequate.

Getting the download size down from 120 megs to 71 megs was part of that effort. Writing something by way of instructions was another.

But the first alpha - and the invitations to the alpha test group - went out at the 5:00 hour. My apologies to the people who aren't in the first alpha group, but I really want to hold people in reserve as "Kleenex testers" for future alpha versions. Testers, check your private messages in the forum, and check to see when you get access to the Frayed Knights Testing and Feedback forum. Some people have it already.

The Road to Alpha 2!
Some things topping out my list for alpha 2 include such minor luxuries as actually having the item screen tell you what the item really DOES, so that you don't have to guess whether the iron mace or the broadsword does more damage. And having a visual display of how your maximum endurance drops over time would be kinda... I dunno... less confusing? And then there's the fact that players can get stuck inside of doors. That's not a happy thing. And some fixed combats end up taking place with the opposing forced practically across the room from each other but still swinging melee weapons. Yeah, that might be good to fix.

And actually implementing the weapon and armor proficiency restrictions might make the different character classes more interesting. Oh, and having the big bad evil boss guy actually USE the spells he's got in his arsenal... that might make a difference in combat. And the priests are actually supposed to drop loot once in a while. Now the operative word is only, "once."

This kind of torturous, bug-riddled gaming is what I subject my friends to. I am a bad man.

Development is going to continue at its previous pace for the next month, easily, so Alpha 4 should be pretty different from Alpha 1. My goal is to have each alpha released Friday-ish throughout March. Tuesday, April 1st, 2008 will be the public release date of the Pilot.

Placeholder Content FTW!
And just so all the testers know, Kevin wanted to make absolutely sure that they knew that the revised Tavern roof texture is only a stand-in.


Well, I managed to sneak in about three hours of sleep between 6:30 and 9:30. I have an appointment to meet someone in a couple of hours, and then I'm gonna try and get another nap in before getting ready for the wedding.

Have fun!

Labels: Frayed Knights, programming, Roleplaying Games

- posted by The Rampant Coyote @ 5:00 AM (Permalink) 3 comments links to this post

 
Frayed Knights - Alpha Candidate Close...
Wow. I just did a play-through of the Frayed Knights Pilot. It took a while. Granted, I had interruptions, but... it took longer than I expected.

And it was pretty dang cool.


There's a nice, long list of issues I've assembled - I guess you could call this an "alpha test," but I'm not releasing this one out to testers yet. I'd like to clear out as many of the issues that I *DO* know about so the testers can concentrate on the ones I do not know about.

But aside from that frustrating feeling of knowing there's way too much to get done and not enough time, it's - at least at this moment - overshadowed by the realization of how this whole dang thing is actually coming together. I'm astounded.

Labels: Frayed Knights, Roleplaying Games

- posted by The Rampant Coyote @ 8:45 PM (Permalink) 7 comments links to this post

 
Frayed Knights - GUI Kablooey
The indie RPG of comedy and fantasy, Frayed Knights, continues development - here's the story!

GUI Re-Glued
A major overhaul of the UI is in progress. The former UI was something only its programmer could love. The new UI isn't done yet, but it looks at least ten times better. Here's a spell being cast in combat. The character portraits haven't been re-done yet, and the buttons on the scroll are just stand-ins for now.

I can't tell you how many iterations we went on the interface. We came up with ideas, metaphors, slick systems, and then discarded them. Besides the obvious cosmetic differences, the button panel and entire combat interface has been massively overhauled. The new system doesn't rely on nearly as many pop-up windows or as many mouse-clicks, which is a Really Big Deal. Really. Even as a programmer who has the UI sense of a medieval torturer could tell it was Bad Design, but I wasn't sure how to fix it.

What we've got now is a cool little pendant-looking thing that now acts as the button panel. It operates in two modes - combat and non-combat (yeah, I know, "Gee, whiz!"). The sections highlight when the mouse passes over them in a really slick low-tech awesomeness, and the icons on the right-hand side change in combat mode. I'm kinda proud of it because it is very non-Torque feeling.

Earlier, whenever you attacked or cast a spell, you then had a pop-up to determine what your target was. This, on the whole, sucked. Especially since you usually keep whittling away at the same enemy until he drops. Now an enemy target is always selected by default in combat, which you can change with the pendant. In the case of spells targeting friendlies, a default friendly target appears in the spell menu, which you can change.

While the switch-over isn't complete yet, it has already made things run much nicer. Not to mention look a ton more polished. The character displays are also in the process of being overhauled, but I'm not done with that yet. It should look a little bit like the mock-up James did down below (though I have since switched some of the icons around in the non-combat pendant). And I still have to finish up the combat interface. It's still not quite to the full level of functionality of the older version - I think I'm about two hours of development away from that.

One Week Until Alpha
SHEESH! We're gonna be handling the first wave of alpha testing uh... like... next week. In only days. I'm scared. Hold me.

We just got a rough draft of the "Frayed Knights Theme" music this week from Mike "I Am Ominous" Nielsen, which will be iterated on over the weekend. The rest of the pilot chapter will use stock music, and I expect to have plenty of stock music in the full release.

There are a couple of secondary systems that just aren't there yet. And may not be by the beginning of alpha. Like... uh... saving and loading the game. D'oh. Yeah, it's a suck. But right now we're surrounded by odds & ends that we're trying to get fixed up and cleaned up before real testing starts and we get 5,000 bug reports about the same dang broken features. Each.

As I've mentioned before, we're staggering alpha into groups. So even if you are in alpha, you may not be brought on until the end of alpha. Or the middle. This helps keep people from getting burned out on the first version and never playing the later ones.

The game really is a game now - albeit one that has a very rough ending and some severe balance problems. I haven't had time to give it a full play-through in a couple of weeks - I guess that'll be fun for me during the alpha, too. Maybe next week that's the format the update will take... my playthrough. Complete with bugs.

During alpha we're going to be frantically improving and fixing things, changing the Frayed Knights website a lot, putting together a questionnaire / survey for players, and so forth. I expect the game will change a LOT between each iteration (which should be weekly).

Don't forget to sign up for the alpha if you are interested. You'll get to play before everyone else - albeit a possibly buggy, broken version!

Looking Forward
The beginning of alpha is a huge deal. The release of the pilot chapter in less than six weeks is an even bigger one. Our focus is almost exclusive on this release - but we're starting to look ahead to the rest of the game.

In a way, the full release will be "Frayed Knights 2," but we're not thinking of it that way. I'm pretty much gonna keep right on rolling in April, May, and beyond. I've already invested some time and money into what's coming next, and we've discussed ideas as a team to cement the rest of the game. The story is set, the upcoming quests have at least a general outline, and we've even begun putting together assets. I PRAY that they'll be faster /easier to put together than the Temple of Pokmor Xang, as there won't be so much necessary on the coding / engine / system side to do.

While the pilot chapter is largely self-contained, there are going to be some hints here and there as to the larger mystery and storyline going on. Although one of my fears is that the players will figure out the whole story, the upcoming plot twist, and everything else right off the bat in just the pilot episode. Then I guess I would have telegraphed things too well.

Naturally, some of what we have planned will be changed. Your feedback is going to be key. It's hard to imagine, but I expect in four months I'll be looking back on this time and chuckling at how naive I was, and how much easier things were. But I really look forward to hearing what you have to say about the pilot!


(Vaguely) related drivel:
* Frayed Knights: Pilot Prep
* Frayed Knights: Prologue and High Concept
* Cartographic Incompetence and Dirk's Interview

Okay Heroes - Let's Chat On the Forum Thread!

Labels: Frayed Knights, Roleplaying Games

- posted by The Rampant Coyote @ 5:13 AM (Permalink) 9 comments links to this post

 
Frayed Knights - Pilot Prep
So, did you want to hear a weekly update on the development of Frayed Knights, the indie fantasy role-playing game of comedy and pointless in-jokes?

No?

Oh.

Well, I don't have anything else prepared, so I'm just gonna roll with it anyway.

The Pilot Demo Approaches
This week (this month, really) has all been about the Big Sprint to alpha for the "Pilot Demo." That's the latest name for what's getting released in April. I liked the term, "pilot," thinking of pilot programs and TV show pilots. That really kinda sums up what the April release is about.

Basically, its one big test screening. To see what flies, and what lands with a thud. The engine will be "done." Armed with the feedback from the pilot, we'll build out the rest of the game, fixing what seems broken in the engine or design and moving forward.

It's kind of a cheapski way of making two RPGs, so I can get all my mistakes with the first one out of the way.

The Game Development Life Is Very Glamorous
I spent way too much time this weekend looking at... fonts. Key game elements are still laying half-assembled on the virtual workbench, and I spent hours and hours looking at fonts. And emailing the guys that made the fonts, asking for terms. Because they don't want to give you the terms up-front, in case you are a WEALTHY company like Microsoft who they can charge thousands of dollars to. So I have to play my "poor indie" card.

Interesting point - on one site that had fonts that were "free for non-commercial use" and some other fonts that were "premium" but okay for commercial use - the charge for commercial use of the free fonts exceeded that of the premium fonts. Go figger. We're not talking about extreme price-gouging or anything, but it was definitely interesting.

And no, I still haven't settled on a font yet. The two more exotic ones I tried out were almost universally panned.

Ah, such is the glamorous life of a game developer. It's all action and adventure and excitement and whooping and hollering as the game comes together...

The Game Comes Together?
The frantic final stages are both thrilling and stressful. Remember that scene in "Ghostbusters" when they are talking in the elevator about how each of them is wearing an unlicensed proton accelerator on their back and that they've never actually had a successful test of the equipment? That's pretty much how I'm feeling each time I run the game. The changes are coming "fast and furious," building on a bunch of foundation code that is beginning to get old enough to gather dust, but I'm now calling functions and special behaviors that were never entirely tested.

And I am thrilled with how often they actually work more-or-less correctly. That almost makes up for the times I spend revamping or debugging months-old code that seems completely alient to me.

For example, I spent a half-hour tracking down the reason that a character can wear TWO suits of chain mail at the same time IF they equip the second suit directly from the party inventory, but not if they bring it to their own inventory first. The fault turned out to be a misspelled function name (ah, the joy of typeless scripting languages) that had been sitting around in the code FOREVER, unexercised.

I finally got Drama Star effects implemented. Well, partially. We're in the middle of a massive (and long overdue) re-design of the UI. I can now mix monster types in encounters - so we can have a boss encounter with his guards (a challenge that, for now, is a little on the "too hard" side). And there have been a lot of fiddley bits I've been working on - fixed dialogs, descriptions on spell effects, UI management bugs, and so forth.

Taking Inventory
Oh, and inventory is now working much better. You can actually use activated items now - like potions - both in and out of combat. I liberally sprinkled a few potions of negligable healing throughout the dungeon, which has made an ENORMOUS difference in combat balance during the game. I expected it would, but you never know about these things until the rubber meets the road.

I also disabled access to the party inventory during combat. This is a change that I think will stick with the final version. Previously, I'd designed it so that using things directly out of the party inventory simply incurred a much larger delay between a character's actions. But the delay factor is really abstract - while it doesn't need to be understood to play the game, really big delays would cause confusion and frustrations with players who haven't yet grokked it. Disabling access to party inventory simplified and streamlined things, and also - I felt - made for more interesting decisions. Who gets that potion of healing when supplies are running low?

(I usually give it to Benjamin, who can then heal other party members with spells.)

Combat
Almost all aspects of combat are now functional. The AI aren't casting spells yet, the "defensive" stance doesn't do anything yet (I gotta fix that - it's like a ten-minute job!). And no "active" feats have been implemented yet (nor are they usable by the AI). And I'm not entirely sure weapon ranges are functioning correctly - I gotta run some tests on that this weekend.

But with spells working (and easy to add!), inventory items (both equipped and activated) functional, drama star effects... I'm kinda giddy. Combat has become much more interesting. Not that every random encounter with pus golems is a thrilling X-Com battle level of awesome (if only!), but they are much more fun and interesting than the click-click-yawn-click gameplay of too many "action" games.

That makes me giddy on a level that I suppose only an old-school D&D geek can appreciate. I still have no clue if anybody ELSE will appreciate it - but hey, that's what the pilot is for, right?

Sign up!
If you haven't signed up to be an alpha victim --- er, I mean, TESTER, and you have an unusually high tolerance for pain, don't forget to sign up on the alpha testing thread in the forum.


(Vaguely) related dorkiness:
* Frayed Knights - Bad Text Gone Wild!
* Frayed Knights - The Stupid Stuff Takes Too Long
* Frayed Knights - Please Don't Swim In Our Toilet
* Frayed Knights - Exploding Locks and Other Stories

Got questions? comments? Arguments? Suggestions? Post About 'Em In The Forum!

Labels: Frayed Knights, Game Design, Roleplaying Games

- posted by The Rampant Coyote @ 6:21 AM (Permalink) 0 comments links to this post

 
Frayed Knights - Font Wars
Okay, okay, I get the hint. Comic Sans is not well-loved, even as a placeholder font for Frayed Knights. I guess I'm a complete font idiot. So... I've been trying to find more fonts that are playful and readable for the whole game. Probably. Here are two candidates, though I'm not sure one of them is even available for a (reasonable) commercial license. Click on 'em to get the bigger version (or just go immediately to the poll thread to see 'em both in full glory).

Font Candidate #1:


Font Candidate #2:



Even if you don't like either of them, please give me some suggestions on which ones I *SHOULD* check out. Just don't point me in the direction of a font that will cost me hundreds of dollars to license, because I'm on an indie budget.

Here's a poll so I can easily track the responses:

FRAYED KNIGHTS FONT WARS #1 POLL

Thank you kindly in advance for your suggestions!

Labels: Frayed Knights, game art

- posted by The Rampant Coyote @ 12:57 AM (Permalink) 9 comments links to this post

 
Frayed Knights - Bad Text Gone Wild!
The ongoing saga of the development of Frayed Knights - the indie RPG full of fantasy and bad jokes - continues in article, all about massive progress and massive speed-bumps. And a BIG ANNOUNCEMENT at the end!

Boy. Ya get this euphoria from having accomplished a few major, intimidating tasks... and then you end up spending three days re-writing something that you THOUGHT was already working in order to fix a bug that just cropped up.

Dialog and Font
In my case, my 2D text rendering suddenly went to crap. And you know what? Nothing is sexy about font rendering. Here I was, planning on doing all kinds of uber-cool (to the geekly mind, I guess) AI stuff and some overdue game mechanics stuff, and I gotta work on text rendering.

I ended up replacing my code (which was based on a user-created module from TGB 1.1.2) with the not-so-new, improved, official code from a later version of the engine. This handled fonts completely differently. It worked fine, but everything about how it was positioned, sized, and called was different. This made my precious little dialog-balloon code, which I thought was done, require a rewrite pretty much from the ground up. And all the other TGB-based text calls, like the little floating numbers on hits, or that really groovy blue "MISS!" word that appears far too frequently.

But in addition to running to stay in place, I made a few improvements to the static dialogs. They have color-coded borders now, a suggestion I received at the Utah Indie meet a week ago. It actually works really well. I also increased the font size, so that players will be less likely to go blind from this game. Well, at least it won't be the text that makes them go blind. The graphics may still do that to 'em. Sorry 'bout that in advance.

Take That, You Fiend!
Besides the very boring font / dialog stuff, I also improved how monsters spawn, so they are less likely to end up stuck in walls or under the stairs. It's working pretty cleanly now. And that's about the extend of the path-finding for monsters. I also make them fight the player much closer (at least the random encounters do). Putting them right up in your grille like that did wonders for improving the "feel" of combat - it's visually more interesting and exciting. That's first-person perspective for you!

As I've mentioned before, I'm going old-school with monsters. Positioning is kind of on the abstract side. I actually have a table for every section of the dungeon or wilderness with what monsters appear, their frequency, and an abstract measure of quantity. As you fight the wandering monsters, their frequency of appearing drops. Eventually, this number will go back up - so if you leave the temple for a few adventures, and then come back, you may still find some priests, pus-golems, and brittlebones again. In fact, you'll never "run out" of monsters - you just may get to a very small chance of them appearing.

I also started working on music, sound effects, and spell visuals. You know, for the full version of this game, I may really go back and try once more to integrate TGE 1.5.2 and the ArcaneFX pack with TGB - this time, using an older version of TGB (1.1.3, probably), so future spell visuals can be much cooler. But for the April "Pilot Episode," I'm gonna have to keep it simple. Little particle sprays, and stuff like that. I have great plans for cool animations for spells like, "Power Word: Defenestrate." But that will come later.

Time To Go On A Diet!
One issue I discovered just prior to the Utah Indie Developer meeting was that the game's size. It has ballooned to something like 120 megabytes at maximum ZIP compression! And this is is (mostly) just assets for the pilot episode. This is too friggin' huge. Now, this might cause nobody to download it, which means the bandwidth for hosting it won't be such a big deal... but that's not really the problem I'd like to have. I really want the demo to fit in under 70 megs. Under 50, if I could swing it, but I have no idea how to pack it down that tightly.

So it's time to put the data on a diet. There were some easy savings to be had eliminating some obsolete objects from the directories, and compressing the sound effects from their monstrous .WAV format down to the much-tighter .OGG format. But that only gets us part of the way there. Then we have a few 1024 x 1024 textures hanging out that need to go down to (at least) 512 x 512, and some 512 x 512 that can probably (regretfully) be reduced to 256 x 256. And I can try and share texture usage more across multiple objects. Naturally, this is painful to do, leads to things looking pixellated and all alike, and hurts the visuals on levels that make babies cry. But - such compromises are reality.

Some stuff... man, I don't know. I have a dead skeleton which - coming through the Blender exporter - is at about 115K in size. Man, back in my day, we had entire RPGs that fit within that size, or not much more than that. I'm a little suspicious of that size, too, as the full skeleton exported from 3DS Max (which I do not have) - with rigging for animation - was a little smaller than this. But sometimes I just have to suck up the hit.

That, or put a white box on the floor, and ask the player to pretend it looks like a skeleton.

Dialog Jitters
Well, besides my font suddenly going all low-rez on me and having to be re-coded, I had one other concern about the dialogs. And that has nothing to do with coding.

What is terrifying me the most about this game is the writing. The humor. The game is gonna live or die based on that, and I'm worried it won't be up to snuff.

I can be okay the facts that the animations look like crap, that my textures are inconsistent in style, and that I'm forcing the game to run in 1024 x 768 resolution. I know this isn't gonna be Oblivion - or even Wizardry 8. But if the writing isn't good enough and entertaining enough - if the characters do not "click" with players - the whole game fails.

That's the easiest thing to correct (text is cheap), but it's surprisingly challenging to balance. Is there enough dialog? Is it too much? Are the jokes too low-key and dry? Am I finding the right "voice" for the characters in each dialog (especially tough when said character might only say two words in a dialog)? Since so much of what happens in the game is non-linear, is the player getting something resembling a "story," or is it going to be utterly confusing random-feeling jumble of vignettes?

I guess that's part of why I'm approaching the release this way - with a "pilot episode" in April. It'll be kinda like a big, public focus-group test. A chance for you to let me know just how badly I've screwed up on this thing, so I can hopefully make the corrections. Effectively, the April 1st release will be "My First RPG." People can savage it, I'll learn from it, and fix things for my "next" game... which will be "Frayed Knights - The Complete Story." Except not named as lamely as that. I hope.

Alpha Test Sign Up
I need alpha testers for the Frayed Knights pilot. Testing will begin March 1st (possibly sooner). If you are interested, please register on the community and Sign Up In This Thread! Now, I won't be dropping the first alpha on everyone all at once. I'm going to phase this into weekly releases, opening it wider and wider each time to different groups. This way, I will hopefully have people scrutinizing the fourth alpha just as carefully as the first alpha.

And that's all for this week.

I think.

Looky! Forum Discussion About This Week's Dev Diary! Cool!*

(* for very liberal definitions of "cool")

Labels: Frayed Knights, Roleplaying Games

- posted by The Rampant Coyote @ 2:50 AM (Permalink) 8 comments links to this post

 
Frayed Knights - The Stupid Stuff Takes Too Long
Tales of Frayed Knights, the comedic independent fantasy RPG coming from Rampant Games in the not-too-distant future. I hope.

It's friggin' midnight. And I just realized why my weapons are not responding properly to the armor level of the characters. Inside the character class file, I have a function that gets their armor level.

It looks something like this:

function Character::GetArmor(%this)
{
// Gets the total armor level, including current magical effects on the character.
// To Do: Everything. This is a stub.

return 0;
}

Great. Oh, well, I'm already in the middle working on equipped effects (things that happen to you while an item is equipped), so this isn't such a big deal. But it does explain a few things.

Writing Dialog. This is my favorite part of working on the game, but it isn't easy. And it is surprisingly time-consuming. Some of it works, some of it doesn't, and every single bit of it needs a major editing pass to make sure all the plot points are being hit, and that the appropriate dialogs have at least a subtle shade of humor and are speaking with the correct "voice."

Then there's allowing a "freelook" mode, but I want it to snap back to a particular pitch you are done looking around at the environment. Unfortunately, Torque doesn't give you any control over this with the Player or ShapeBase class, so I have to make a minor engine change. No big... but it takes time.

Then I spend about an hour and a half working with James to get the mount point working on his models so that the weapons aren't growing out of the back of their knuckles. James lives about 850 miles away, so much of the delay involves sending files back and forth. But part of this is just nailing down a process for us both for future content.

A crash when traveling between the dungeon and the village has me baffled. I try and trace it down in the debugger, and find it's something to do with player movement - before the level is fully loaded? It stumps me for a day. Realize that for me, a day means spending nine hours at the day job, plus a slow, snow-covered, slippy-slidey commute each way, plus an evening scheduled with other stuff that comes with having a life, not to mention a blog post, so we're really only talking about two or three hours of actual time spend working on the problem - between 2:00 AM one morning when I call it quits for the night, and 9:30 PM the following night when I get cracking again. But after a day, I realize a (possible) solution, having worked with Torque a little too long. I schedule the level load rather than calling it directly. Bam! The bad crash goes bye-bye, and everything suddenly works.

There are buttons that don't work anymore because they are properly calling the new UI manager, but I'd neglected to upgrade the call their container dialog, so it's still manually being brought into existance. The UI manager doesn't know anything about it, so the buttons aren't working. And then there are inexplicable slow-downs when certain dialogs are up. But it's bad! I need to find the problem and fix 'em.

Grumble.

While the entire first chapter is, as of last night, playable from beginning to end, there are a couple of major issues still outstanding. Like, oh, saved games. And trading. A new and improved inn. But for the most part, we're down t0 "stupid stuff," which takes almost as long as the big tasks. All those little details that might fall through the cracks. And there's a LOT of it. It's those stupid, little things that take so much time, paralyze apparent progress, and drive me crazy.

I hate this part. And it's not even in the serious bug-fixing stages yet. This is the point in the project where keeping an updated "to do" list is critical, and where you have to take satisfaction from seeing lots of little, stupid things marked off as "complete." Because it doesn't make great screenshots, and the players won't notice it at all unless it's not done right.


Forum Discussion, Because Misery Loves Company

Labels: Frayed Knights, productivity, programming

- posted by The Rampant Coyote @ 1:08 AM (Permalink) 4 comments links to this post

 
Utah Indie Night - Winter 2008
Whew! I got in just ahead of the snow storm. That's the part that sucks about January in Utah. Actually, pretty much everything sucks about January in Utah. I guess the Wasatch Mountains are pretty, all covered with snow and stuff. On the days when you can see them. I don't ski, but I guess that's pretty awesome in January. So there are some things to look forward to.

The quarterly Utah Indie Game night is another thing to look forward to, which falls in January. This month it was once again at the Taylorsville ITT Institute. We had a pretty good turn-out, though a lot of the people - like last time - were ITT students of game design and development. They brought in some excellent Mexican food this time - a nice change of pace from pizza.

As to the night itself, it pretty much went the opposite of how Greg Squire, the founder, had planned. That was unfortunate. His initial plan was to have the formal presentations take only a half hour, and then have the rest of the time taken up by various discussions and little mini-presentations throughout the room.

This time, though, there were no other computers (I'd even neglected to bring my laptop this time), and the main presentation was stymied due to technical difficulties. The main presentation was LinkRealms, a great upcoming indie MMORPG. It seems they use the same ports as World of Warcraft, and ITT has all of those permanently blocked to prevent students from playing WoW on campus. D'oh! They made due - at the end of the evening - with some videos of gameplay. And Herb talked at great length about the game, their technology, their business plan, and what the indie MMO space looks like.

Prior to that, we had impromptu presentations by Greg Squire, who showed his "inner space" inside-the-blood-vessel shooter, and he also took several minutes to show a non-Utah-made game, the very-very cool Crayon Physics game by Kloonigames (which unfortunately looks to have exceeded its bandwidth for the month, so the link today no worky...) I also delivered an impromptu update on Frayed Knights. Since I hadn't actually prepared to give a demo, I wasn't entirely certain what to show, but I spend a bit of time wandering around, using a cheat code to clear out combats (one of the guys in the back would play the Final Fantasy victory fanfare music on his cell phone every time I did that), and clicking on various boxes and dialogs.

But I was pleased to be able to show the game to Mike Nielsen, who is going to be composing some custom music for the game. Steve Taylor was also there. And I got some feedback about the dialog system that I'm not entirely certain how to handle (yet). It needs some help. It can get confusing. Suggestions included getting rid of the comic-book style presentation altogether in favor of a different presentation (but I also had suggestions NOT to get get rid of it), to use face icons next to all the lines of dialog, and to color-code the boxes based on who is speaking.

Stuff to consider.

I also had some opportunity to talk to Herb about LinkRealms in a bit more detail, and had an awesome discussion with Mike Rubin about indie games in general, and Vespers 3D in particular.

My suggestions for the future:

* Limit all presentations to 10-15 minutes, max. And have somebody there to help the presenter keep track of time. I honestly have no idea how long I took. Though I think half the time was taken up by trying to get the game to work on the ITT machines (we'll call that an "alpha" bug...)

* Make sure there are computers (or desk space for laptops) in the room, and help people get stuff set up. Make sure everyone who needs to use laptops and an Internet connection has a WEP key or a network cable. I think there were a few games that would have been presented if they weren't done in front of EVERYBODY.

* Red Iguana food - definitely worth doing again.

* Instead of just presenting the whole game to a bunch of game developers, we may want to consider instead having presentations about certain aspects of game development. Like - for example - JUST the particle editor of LinkRealms, or JUST the dialog system in Frayed Knights. Short presentations on other subjects - like marketing, building communities, making deals with portals, the "state of the industry," console development for indies - stuff like that.

* We definitely need a better way to form the informal discussions. I noticed a few discussions ended up taking place in the hall outside the classroom we'd had allocated to us.

Next report in April. Hopefully with some new, fresh games to talk about!

UPDATE: Here's the poster advertising the event, done by one of the ITT students. Very cool. Now I wanna go... again...

Labels: Frayed Knights, Indie Evangelism

- posted by The Rampant Coyote @ 2:43 AM (Permalink) 11 comments links to this post

 
Frayed Knights: Please Don't Swim In Our Toilet
More words from the development diary of the fantasy/comedy indie RPG Frayed Knights - coming sooner than I'm comfortable with to a hard drive near you, if you are crazy enough to volunteer for the alpha test of Chapter 1.

A Deadline Approaches!
I realized earlier this week that I was down to "40 days and 40 nights" remaining before our contest entry - Chapter 1 of Frayed Knights - is due. Bearing that in mind, we've had to make some difficult scoping decisions. The wilderness land between the temple of Pokmor Xang is likely gone (for now). It's not that it's hard to throw in an extra zone into the game... we could whip out a big empty wilderness full of random encounters in a day. But --- that's not what we're going for.

I mean, we can't do state-of-the-art graphics, elaborate animation, or voice-overs by name actors. But we think we can approach the vicinity of "fun" and "interesting" and "exciting." A big empty wilderness area isn't any of the three, IMO. Our plan is to have the wilderness areas packed with a high density of "mini-adventures." Some will involve smaller interior locations of a handful of rooms (much smaller than Pokmor Xang's temple). Others may be location-based - a buried treasure you find from a map / clue somewhere else in the game, a little micro-story / mystery, or whatnot. Some will tie in to other parts of the game, others will be stand-alone.

We Don't Swim In Your Toilet, So Please Don't Pee In Our Pool
And so there I go talking about what's NOT gonna be in Chapter 1. Unless it gets added later due to feedback on the alpha demo. So let's talk about what we are currently working on...

I spent a little too much time this week ruining a perfectly good dungeon by creating the Pokmor Xang meditation-room pool. I include a render here. It still needs some tweaking - there's a texture anomaly on the metal decoration (based on the Pokmor Xang symbol James McEwan came up with, sans the full "biohazard" symbology). Yes, it is a pool! A strangely shaped pool. I know, my skillz as a 3D modeler are truly 133t. And you may say it resembles some other device known for holding liquid, but I assure you - it is NOT, and such devices did not exist in medieval society.

But it makes it all the funnier when Dirk has to swim in it.

Not that he has to, actually. That's an optional part of the dungeon adventure. You may, in fact, save yourself some amount of grief if you don't. But with great grief comes some mediocre jokes and a little bit o' loot, so... your call.

Here's a screenshot looking upon it from the balcony above, so you can see what it looks like in-game. Yeah, not as cool as the Pokmor Xang statue, I guess. But that comes later. Maybe I should have some discarded magazines scattered about the benches.

Playing Through
I did a play-through of the Pokmor Xang dungeon, which is still lacking some content (and lacking some equipment, some spells, and all drama star effects, and the ability to drink healing potions). I skipped about half of the combat encounters with a cheat code, explored - VERY quickly - all of the rooms, clicked on everything that could be clicked (but didn't really read the descriptions). Total time for play-through: Approximately 40 minutes. This means, once everything is in place and someone doesn't cheat their way through half the fights, I think a first-time play through should actually be about an hour for the dungeon. This sounds about right for me.

I already talked earlier this week about the secret doors. There's only one in this dungeon, but I hope there will be plenty more in others. I'm pleased to have those in place - those were on the list for potentially being scrapped (at least for the contest).

I started work on the buying / selling interface this week as well. It doesn't actually work, yet, but the prototype UI is there, based heavily upon the inventory UI.

Random Yet Predictable
Frayed Knights is consuming my waking hours, and I've found it has turned me into a horrible conversationalists. What else do I tak about? People ask me how was my weekend, and I all I can do is tell them how many hours I spent in the Temple of Pokmor Xang balancing out combat encounter difficulty, affixing torches to the walls, and building locks.

It really makes dinners with relatives extremely entertaining - from my perspective, at least. I love seeing their deer-in-the-headlights expressions as I can practically hear them thinking, "how to I politely excuse myself from the crazy man?"

One thing I've noticed, while balancing combat, is the tug-of-war between randomness and predictability. (See, this is the sort of thing I bring up during dinner discussions. I can practically hear what you are thinking right now.)

Players want predictability. Predictability gives the player control. Randomness reduces that control. But it also keeps things interesting. My probability model follows (perhaps a bit too closely) standard dice-rolling loveliness of tabletop gaming, and while it yields fairly predictable results over the long term, in the short term it leads to very erratic fights. Nothing torques off a magic user in D&D (for example) more than having their awesome uber-spell completely negated due to spell resistance or a good saving throw. Likewise, players hate times when they have an 85% chance of completely ignoring a save-or-die effect, and they blow their save.

However, players (at least secretly or subconsciously) love the CHANCE of having the spectacular failures. The risk that the next die roll could be your last... well, until you get a resurrection. But they want to be on the "lucky" side of that risk. Every time. They want to be the person who takes the long shots - and pulls it off. The risk and randomness is all very exciting - but you want it to pay off more often than probability says it should.

So I'm re-looking at how combat works (again) in Frayed Knights. Should I normalize the results a bit more? Skew everything even more tightly towards the middle? Part of that would include making "hits" far more frequent than misses. The original rules called for a slightly better than 50% chance of hitting against an equally matched opponent - which is actually, IMO as a former fencer and medievalist, really too high (at least for the kinds of melee combat I'm familiar with). But missing is boring. And makes combats too random.

I've skewed attacks now so they occur a little more frequently, but now I'm trying to make decisions about damage. Should they be more normalized? It feels weird when, during a round of combat, Arianna lands a pathetic 2-point hit, followed by Chloe who - in spite of being much weaker than Arianna and a less skilled combatant - does five times that damage on her own hit. Granted, if you graph the hits over the long term, you'll find that Arianna hits far more often, and averages about 2 points of damage per hit more than Chloe in melee. But - that random spread makes things feel too random.

So I may be doing more tinkering.

"To Do: Slap Together a Game"
The "to do" list is truly staggering, even without the wilderness. I spent time this week making sure we'd have music and all the remaining artwork that will be required for the game. Characters / character models are the principle area we're struggling with right now. Aside from that, from a content perspective, I'm looking forward to (and working towards) the stuff we're going to be doing after the contest. But the contest is going to take precedence for the next two months.

Upcoming for this week - more of the same:

• Make sure there are more things to click on and do in the dungeon
  
• Get the writhroots and blurry form spells working.
• Travel between the temple and the village.
• All dungeon loot / items.
• Get dungeon dialog 100% completed, self-edited, and then send off to my editor friends who promised to take a look at it and still remain friends with me later.
• Get spellcasting working out-of-combat.
• Get activated items working both in and out of combat.
• Finish the merchant trade system
• Fix encounter spawning
• Get Freelook working
  

Man. I am getting tired just looking at that list. But I think we're down to about 36 days as of today, so... I'd best get cracking. But if I could actually manage to knock out the majority of what's on the list, we'll be in AWESOME shape.

'Till next week!


(Vaguely) related delves into metaphorical dungeons:
* Wandering Monsters and Random Encounters
* Disappointment In the Demonweb Pits
* Frayed Knights: Twisty Paths and Flickering Torchlight
* Waiter! Why Is My Dungeon Stale?
* What's the Difference Between Adventure, Puzzle, and Role-Playing Games?

Discuss Dungeon Plumbing On The Forum Thread!

Labels: Frayed Knights, Game Design, Roleplaying Games

- posted by The Rampant Coyote @ 8:24 AM (Permalink) 4 comments links to this post

 
Frayed Knights: Secret Doors
Just a little tidbit from the ongoing development of Frayed Knights:


That is not a graphics anomaly. That little area where it looks like the texture doesn't line up quite right is actually a secret door. There will be an automatic search that takes place near it to let you - the player - recognize that something is not quite right (assuming the search succeeds). Or you may recognize it visually.

It's minor, it's silly, but it gives me warm feelings inside. Some days, I look at how much work the game needs, and I think, "Oh, man, this thing will NEVER come together." Other days - like today - I get a minor little victory like this, and it's so cool that I think to myself, "This is gonna be the coolest game EVAR!!1!1!" It's nice to have one of those latter kinds of days once in a while.

I've had a couple of them this last week. This is a good thing. Maybe it's a sign. Or maybe its denial. I dunno which, but it makes me happy. And makes the crazy hours I'm putting in on this thing seem worthwhile.

I was just thinking back a little, and trying to recall how many non-indie RPGs (or indie RPGs, for that matter) of the last five or six years actually include secret doors like this. Not very many that I can think of. D&D Online is one of the few mainstream games to include them. I don't know if the concern is that the players will miss them entirely - and thus miss some of the laboriously-created content the developers have put in the game. Or if they were just too hard to implement in art (one reason NWN didn't have them until a later expansion).

And for your entertainment - another great use of secret doors.

Labels: Frayed Knights, Roleplaying Games

- posted by The Rampant Coyote @ 7:57 AM (Permalink) 6 comments links to this post

 
Frayed Knights: Of Priests and Pus
Continuing the weekly report of the development of Frayed Knights, the comedy-based fantasy RPG...

A Ray of Sunshine
Every once in a while, the universe decides to quit kicking you when you are down, and give you a ray of hope. Maybe that's just so it'll hurt more when it kicks you again and dashes those hopes. But regardless of its purposes, it's great when it happens.

Earlier this week I bemoaned the state of content. Frayed Knights has been running behind, and I have been desperately trying to find ways to get it back on schedule. And I've been frantically trying to figure out how to get things done quickly -- and the "build or buy" decisions get complicated by the difficulties of adapting off-the-shelf content to match (insofar as possible on an indie budget).

Not 24 hours after I posted it, art resources from the other team members (who hadn't seen the blog post) began rolling in. Kevin delivered the Pokmor Xang dungeon "release candidate." And James had the pus golem rigged with some animations done, and was working on the Pokmor Xang priests.

Worshipping Pokmor Xang
We went the rounds on the priest, and while it's still a work-in-progress, I am very pleased with how it's shaping up. "Tickled" might be the operative word here. It took us a few iterations. The idea here was to make them at once comical but menacing. I mean, these guys worship a pus-god. The god of boils, blisters, and pimples. They are obviously very disturbed individuals. How do you explain that particular conversion to your friends and family. "Well, one morning I popped a zit, and the spray on the mirror was in the image of Happy Pokmor Xang. I knew at that moment it was a sign..."

In spite of the Happy P-X image, however, he's not a nice god. His clerics are not nice people. Maybe not quite as nasty as the goddess of disease, Neutoxis - these guys are kinda second-string nasty. Bush league evil. But they have aspirations and a need to overcompensate.

One idea I hit on was to give them wooden masks. Something between a big wooden tribal mask and a Michael Myers freaky psychotic killer look. For one thing, that allows us to keep using the same model over and over without there being a problem that the villains all look alike. And then, when I was actually having my daughter do some sketches for me, she asked, "Should they have pot-bellies?"

Perfect.

After a couple of failed attempts at modeling them on my own (I should stick with crates and doors), I handed them off to James, and he came up with something really pretty awesome. A few changes later, and we've got the awesome work-in-progress picture you can see here. At least, I think he's awesome. I especially like the holy symbol on the apron (which looks suspiciously like a bib - something else I love!) that James came up with. It's sort of a combination of a biohazard symbol (purely a coincidence, OF COURSE... just like the fountain that resembles a toilet), and a symbolic image of a bursting blister in a cup.

Yummy.

You can click on that picture to get more of an extreme close-up, if you can stomach the sight. He's not 100% complete, again, but except for his hands, most of his texturing is pretty close to complete. He mainly needs rigging and animation.

The Pus Golem
Speaking of yummy, we also have... the pus golem.

The pus golem isn't 100% complete either, but he's getting there. He's a shot of him outside his natural habitat, but since I was working on stuff in the town when I got him, it was just easier to put him there for his close-up. There's still some UV work that needs to be done before he's final, but we've got the rigging in and some of the animations.

Here's part of his idle animation, when he's silently roaring. Well, probably silently. He doesn't really breathe, but I guess he could possibly make some kind of slobbering, gurgling noise. Maybe we could record someone sucking the last of a milkshake out of a 32-ounce plastic cup or something. Or - since I have a cold right now - I could just record myself breathing. That might work...

I've already talked a bit about his creative process. Poor James had to spend too much time looking at pictures of pus while working on this guy.

The Dungeon Nears Completion
Kevin has done a pretty outstanding job on the Pokmor Xang dungeon. He's done a lot to break up the monotony of a couple dozen rooms. I have to say that - as much as I wanted Frayed Knights to shine - I wasn't really expecting it to look this good. So thank you, Kevin, for raising the bar and making us all have to do so much more work to make the rest of the game match...

In fact, it's so nice that I've had to make some storyline changes. See, the place wasn't originally created by the priests of Pokmor Xang. They are squatters. And there are some secrets to the dungeon that even THEY do not know about. And... if I have time to put it in... at least one secret that they do know about. And fear.

I have been working on fixing up the doors in the dungeon, including some nice double-doors (with animations) for several areas. At least *I* think they are nice. Considering my artistic ability has mainly progressed from "sucks" to "sucks less" (which I'm very proud of, BTW), it might not be that spectacular, but it works. And I love simple animations. They look sharp, and they are pretty trivial to do.

And More In The Village
And as far as the village people - I've been writing dialog. I love writing dialog at this time of year. Why? Well, it's fun, it's different, and I can do it in a notebook. The notebook thing is important, because it can be done sitting by the fire on a snowy night in my family room, instead of in my cold basement office huddled next to the space heater.

Due to my dependence upon text in this game, the dialog is a special challenge, one I'm not sure I'm entirely up to. The trick is making it (usually) funny, but also informative and moving the plot / story along. And there are moments (not many, but they are there) where the game actually approaches seriousness. In fact, Chapter 1 ends on a pretty tense note.

So I keep editing and iterating, and hope that what I end up with falls in the same zip code as funny. We'll see.

Managing
During the development of Void War - about three quarters of the way through - I noticed that my role kinda shifted from "some guy programming a game" to more of a management position. I found I spent half of my time on the phone or in emails with people. It was frustrating at the time, but the game made a ton of progress while I was doing that. I've begun to feel that way now. I hope that's a good sign.

'Cuz as of right about now we have approximately 70 days to get the Chapter 1 done. Or at least demo-able.

What I HOPE I manage to do this week is to put some more quality time in on the dungeon of Pokmor Xang. In a perfect world, I'd finish both it and Ardin Village in two weeks. I don't think I'm gonna make it, but I'm seeing that ray of hope.


(Vaguely) related revealing of too much information:
* On Making 3D
* The "Red Line" in Game Demos
* Frayed Knights: The Exploding Lock and Other Stories
* The Secret of Success? It's All In Your Mind(set)!

A Forum Thread! All About Priests and Pus! You Know You Wanna Look!

Labels: Frayed Knights, Roleplaying Games

- posted by The Rampant Coyote @ 4:33 AM (Permalink) 0 comments links to this post

 
On Making 3D
I have come to the realization that, after Gutenberg's little gizmo put them out of work copying and illuminating documents, the medieval European monks might have found 3D texture art to have been a perfect match for their skills. Assuming 3D modeling was in line with their religious beliefs. And assuming they had 21st century computers at their disposal in the 15th.

In elementary school, I learned about why the different projections of a 2D map of the world were flawed, and how Greenland really wasn't as big as all of North America. But aside from that, I thought it was largely an academic exercise. Then I tried to keep straight lines straight on a (simulated) curvy object. Suddenly that third-grade geography lesson takes on a whole new meaning.

Two things I have discovered (repeatedly) is that:

#1 - Creating 3D content (or good 2D art, for that matter) is not easy.

#2 - The stylistic differences in off-the-shelf content packs render them almost totally incompatible. In case you haven't seen what I meant from the Frayed Knights screen shots, here's what I mean:


These guys look great on their own, but just cannot dwell on the same screen together. Unless it's Roger Rabbit World. This yields the inevitable conclusion:

#3 - If you are making a 3D game with a lot of content requirements, you are pretty much hosed.

Which is where I sit. I keep spending time trying to massage content instead of coding, trying to tweak textures, lighting, and models enough to make things not quite so eye-searingly bad.

And I continue to bump into my own limitations as a game developer. Yes, I've got 'em. Not just in content creation, but in coding too. This weekend I spent several hours in a forced education about Torque's animation system. All this just to get a character to cross a room and say something to the player. I tell myself it's black triangle work. Even this far into the project, there are black triangles to be drawn.

The bottom line is that creating a game is hard work, and if anybody goes into it already knowing everything there is to know, for which it is all a piece of cake, I've not met them. I've been at this for years, now, and some days I still feel like I am fighting for every five minutes of gameplay.

Incidentally - getting any of the above models and then spending some time on them in the modeling package of your choice, learning how really skilled artists built it, laid out the textures, and rigged the thing is a fascinating and extremely educational exercise. I recommend it if you have the slightest interest.

Labels: Frayed Knights, game art, productivity

- posted by The Rampant Coyote @ 6:13 AM (Permalink) 14 comments links to this post

 
Frayed Knights - To Raise a Village...
Another installment of the best-selling*, critically-acclaimed** weekly development series on the creation of the 3D comedy-based fantasy RPG, Frayed Knights. This week... it takes a dev team to raise a village. And a single dragon to raze a village, I guess, but we're getting ahead of ourselves, aren't we?

The Temple of Pokmor Xang isn't yet completed, as I mentioned last week. But the principle path through the dungeon is working. Events fire as they should, and you can complete the quest. But there's not a lot of loot, the combat is still way too hard and not very fun yet, and certain things aren't working yet (like using a potion in combat). Work is still progressing, but I've decided to make it a secondary priority.

January is the month to get the Village of Ardin completed. In an effort to kinda-sorta stick to the original schedule and not fall too far behind (or at least gauge how far behind we really are), I've been putting effort into that. Worst-case scenario, the wilderness area can be cut or abbreviated next month (which is a short month, anyway). If I can somehow manage to get both Pokmor Xang and Ardin done this month, I'm golden, right?

Yeah. And while I'm at it, maybe I can model some 3D monsters in my sleep, too. It could happen. I've managed to model some monstrosities while sleepy, which is close, right?

What I'm On The Hook For
For the purpose of the April public milestone ("Chapter 1"), I've got to get the following pieces done:
* The village itself - buildings, terrain, passage between zones, various props and vegetation
* Story-based events that occur when you arrive in the village
* Characters and certain plotlines that are supposed to be introduced in chapter 1, even though they don't really become part of the story until later.
* Trading / sales. For right now, there'll be a general store that may have some limits to what can be bought and sold (limiting my hypocrisy). I'm still up in the air about other trading options (like with the other adventurers in town).
* A certain change in party membership occurs.
* Miscellaneous interactives, like working doors and stuff like that.

You arrive in the town in the evening (yes, linear, on-rails crap... I'm a terrible, terrible game designer), so most of the shops are closed. Chapter 1 ends after a dramatic event happens (yes, more terrible on-rails stuff) and you return to your inn room to sleep off the horrors of your last adventure.


What I've Been Working On
This week, I've mostly felt like I've been spending money. I've been using a lot of off-the-shelf content packs - some free, some cheap-but-still-costing-me-hundreds-all-together - to at least get the gameplay in place. I'm hoping there'll be time to go through and replace or clean up the worst stand-in stuff later once we've got stuff nailed down.

I'm using content packs from GarageGames, DexSoft, Cubix Studio, 3DRT, FruitBatInShades, Adam DeGrandis, MMOWorkshop, and BlattSalat. Kudos to all of these vendors for their stuff. I'm also not entirely pleased with one vendor who is apparently still active (and reputable - I know of others who have used their stuff), but has a broken shopping cart that isn't properly integrated with PayPal and aren't responding on their support emails. I guess the next step is to escalate things through PayPal. Vendors - please be responsive, and check your email at least once every couple of days.

I had a nice chance to play with the terrain, construct a waterfall (which I'm still not happy with), get the sunset's reflection on the water (partly obscured by the mist rolling in), place buildings and walls, and otherwise do nifty level-designer things, which makes my programmer-brain happy, as it gets to take the night off when I do that.

One problem I did run into was misjudging the scale. Working with the camera and a bird's-eye view, I accidentally made the village too large. By about double. As you can partly see in the screenshot. So I'm working on tightening things up and putting more buildings on the east side of the river. While in real life I enjoy walking just for the exercise, my general rule of thumb is not to force the player to walk too far without having something interesting to do. A minute-long trip between buildings isn't my idea of fun, even if it would be more realistic.

About the Village of Ardin
The village of Ardin was - until recently - a sleepy little farming community on the river nestled in a comfortable dale. A few former adventurers and veterans of the military helped keep the village prepared for monster attacks, and kept the pesky weed-goblins from getting too aggressive. It was a quiet, comfortable land of mild seasons, good harvests, tasty fishing, and humble pleasures.

Then some adventurers found gold in one of the nearby dungeons, and everything went to pot.

Now the village has been transformed into the equivalent of an American 1800's "Gold Rush" community, with adventurers filling the hastily-expanded local inn. The villagers resented the intrusion and the drain on their resources at first, but adventurers bring good coin, so after inflating their prices they've reached some kind of equilibrium. They have also learned the disturbing truth not to get too attached to these visitors - too many never return from their expeditions.

And so it is for the Frayed Knights.


(Vaguely) related stories of dread and woe
* The Exploding Lock and Other Stories
* Cartographic Incompetence and Dirk's Interview
* Save Me, You Jerks!

Hey! A Forum Thread On This!

* Hard to determine exactly, since division by zero (free) is technically not a legal mathematical operation.
** It's true. Somebody critical said something nice about us, I think.

Labels: Frayed Knights, Roleplaying Games

- posted by The Rampant Coyote @ 10:39 AM (Permalink) 1 comments links to this post

 
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) 5 comments links to this post

 
Frayed Knights - Poor Spelling
Of all updates on the comedic fantasy RPG Frayed Knights, as of today this one is by far the latest.

And I can't talk now, must code...

But I'll talk anyway, because talking to the computer is giving me grief.

It's the holidays. Which means time off. Which means I'm spending time coding when I'm not playing games or visiting / helping relatives. The latter took up WAY WAY WAY WAY too much of my time this week, but I gotta be nice to them. Because they are relatives. And they'll be expected to support me when Frayed Knights fails miserably and I find myself bankrupt. Gotta have that backup plan.

Combat remains imbalanced. I'm working on spells. Among other things. Because melee combat seems to be working okay. Negligable Healing is - unfortunately - a little too negligable. 4 points of healing doesn't do much when the cultists are critting for 13 points of damage. And the Hotfoot spell... what a joke. I think Chloe could do better damage - and use up less endurance - with her fist. If she could actually hit monsters with her fist from the back rank.

(Note to self: Make sure she can't hit monsters with her fist from the back rank.)

And then there's balancing these with duration-based spells... the debilitating or buffing variety of spells which screws up my carefully balanced and - as I mentioned - currently functional melee combat system.

I've been trying to fix sequencing of chained events. The UI is still garbage... but I'm trying to make it functional before making it pretty. I've added a "status" page to see what kinds of spell effects are currently in effect, and what that effect really is. I'm exercising code that hasn't been looked at in four months, and so I'm finding a few logical gaps. Joy.

And I'm supposed to be done WHEN?

Anybody know where I can find an animated, robed wizard / priest looking low-polygon 3D model? Ideally clocking in under 1500 polygons, and able to be warped and modified by yours truly to become the loathsome cultists they need to be. I'm using Cubix's male NPC character right now as a stand-in model (still trying to remain Kork-the-Torque-Orc free), and while they definitely have the scary "Hi, we're the clone brothers" creepiness about them, they are definitely NOT what I had in mind, nor close enough for easy modification, and my modeler has a lot on his plate right now. I attempted this one on my own - more as practice than anything else - and the result was rather humbling. I guess I need to stick with torches and treasure chests.

And as you can probably guess from my discussion on magic items this week, I'm dealing with equipment. Which again, screws up my somewhat-balanced-and-working melee system.

So except for broken code, bad framerates due to lighting, unfinished content, crazy-poor game balance and combats that are clobbering me mercilessly, no music yet, stand-in art, a dungeon that's still not fully textured, and missing features, how am I doing for having the first dungeon 'complete' on Tuesday?

Umm... great? Yeah. Fine. Nothing to see here.

Labels: Frayed Knights

- posted by The Rampant Coyote @ 6:45 PM (Permalink) 4 comments links to this post

 
Frayed Knights - Frantic Dungeoneering
And here's my weekly status report on Frayed Knights - the comedic fantasy role-playing game in development!

External Pressures
Crunch mode at Ye Olde Day Job ended more than a week later than expected. Not fun. However, I think I can say that the other game, The Game That Shall Not (Yet) Be Named, is coming along pretty well. Three weeks ago I was pretty worried. But in the last week or so, it's been looking pretty sharp.

But onto Frayed Knights, the game that will one day sell a million copies and spawn a host of imitators! Well, okay, I can dream, can't I? So what if it's hard enough to get people to download and play games for free...

Stocking the Dungeon
Ten days remaining to finish the dungeon.

A zillion things on my plate, most of them not particularly exciting.

I'm in trouble.

The entry hall is very large and, without any combat encounters, kinda boring. I'm working on trying to remedy this. My philosophy - where the necessities of budget and time allow - for Frayed Knights is that the player should never have to walk in a straight line for a long time without encountering something interesting. And that doesn't mean just lots of meaningless combat encounters.

I've spent some time scouring old Dungeons & Dragons modules, and walkthroughs of adventure games for additional ideas. Even if the combat system is brilliant, tactical joy for players, I don't want to rely upon that as a crutch. I want things for the player to explore and to do. Due to budget constraints, I can't do a gigantic world. I've talked about scope before. So instead of giving players a larger area to explore, I have to provide - insofar as is possible - more detail. More things to click on. And more activities for the player to do.

Some nifty things I've implemented this week is the ability to run custom scripts as part of an event (leveraging Torque's "eval" command), and some fixes in static dialog priority. And I worked on the lesser priest barracks area, so it's more-or-less complete. I'm going to have to get about a room per day completed at this rate, besides other coding.

Continued Development
Unfortunately, this is pretty much the "mid-development doldrums." A lot of the stuff I'm working on now is not strictly new code, but improvements, enhancements, and bug-fixes. We've been iterating on dungeon stuff --- it's getting some cool trim and a texturing overhaul, but except for two early guard rooms, not anything new. In other words, this is the (long) period in game development where an awful lot of work goes in without a ton to show for it.

My (non-spoiler-esque) tasks for the week include:

• Duration spells aren't expiring. Fix.
• Add duration spell icons on character portraits
• Interactive objects: XP gain command
  
• Interactive objects: Drama Star command
  
• Interactive Objects: Trigger portal command
  
• Get keys working for doors
• Wandering Monster Post-Trap / Lock (double chance)
• Message scroll should be visible during navigation mode
• And about seven dungeon rooms need to be fully fleshed out.

A Note On Developing Dungeons In Torque
Note to self: For future dungeons, do all lighting LAST. Adding a few lights to "check things out" early on resulted in a lengthy lighting pass every time I run the game after modifying the level in any way. This is very frustrating.

On Arianna's Cultural Heritage
And a snippet of dialog that might not make it into the demo:

Arianna: I'm only half-elf.
Chloe: On which side?
Arianna: My mother's. My father was a man from Willowshire.
Dirk: A Willowshire guy got to it on with an elf? That sounds kind of kinky.
Arianna: Dirk, if you ever use the word "kinky" in reference to my parents again, I'll be forced to gut you like a fish.

TTFN!


(Vaguely) related fun key ness:
* Frayed Knights: The Scoping Saw
* Big World, Small Dungeon: Does Size Matter In RPGs?
* Wandering Monsters and Random Encounters

Read Comments, Make Comments, Insult My Heritage On the Forum Thread!

Labels: Frayed Knights, Game Design, Roleplaying Games

- posted by The Rampant Coyote @ 9:45 AM (Permalink) 3 comments links to this post

 
Frayed Knights - What's the Big Idea?
Okay. This week has been a little slow on the development front for Frayed Knights because it's been a little psycho on the development front of Some Mainstream Game That I Can't Talk About Yet at the job that actually pays the bills around here. Crunch mode got extended a week, which means much weeping, wailing, gnashing of teeth, and 12+ hour days without even taking a break for lunch (or even to think). Evenings have consisted of playing snatches of games (particularly Eschalon: Book 1, Aveyond 2, and the very dangerous Galactic Civilizations II), and trying to fit in some development here and there.

A lot of time was spent hunting down stock content that could be modified to fit some of the miscellaneous content needs of the game. The sad answer is, very little will. But I'm happily spending my dwindling supply of cash on those stock model / interior / texture packs that show promise of being usable with some modification for Frayed Knights. But weighing price, formats, and really annoying EULA restrictions that protect the content so much I feel frustrated trying to use 'em, not to mention style differences, it can be pretty hard to locate appropriate stuff. So far, I'm happiest with 3drt.com for their low poly counts, high quality, similar style to what I'm needing, very non-restrictive EULA, attractive price, number of formats (though still no native Blender format, dang it!), and variety of textures and animations. Unfortunately, they don't have LOD on the models I purchased, which would ordinarily be a pain. But for Frayed Knights' purposes, I can work with it.

Fortunately, we've got some talented guys handling content-created on the Frayed Knights team who are handling the (still extensive) custom content requirements. Here are some early WIP examples of the Pus Golem.

When is Frayed Knights going to be released?
So I thought I'd take this chance to answer some questions about how Frayed Knights is going to be released to you, the discerning, good-looking, intelligent, and too-clever-to-be-flattered RPG enthusiast.

There is going to be a limited beta "demo release" in April for Windows. That's part of the contest that we're participating in, and it's going to be a way for me to get feedback on the direction of the game. The demo is going to consist of the Temple of Pokmor Xang, the western wilderness, and the village of Ardin. This is going to be as complete and polished as we can make it. A full-on commercial-grade RPG, code-complete (except for some bugs we need your help to discover), content-complete, but a smaller scope: dealing with a single chapter in the Frayed Knights saga.

This is pretty much what the final demo version will be, but in beta (with beta bugs) and subject to change based on feedback. Instead of upselling you on the full version, it'll instead direct you to some online feedback forms that will try and get you to tell us everything you can about how Frayed Knights changed your life, made you more attractive to the opposite sex, and increased your earning potential by 50%. Oh, and how we can make it better.

Why the Beta Demo?
While I am an RPG fan, I have never actually made a full-fledged RPG before (Hackenslash SO does not count!), so this will give me the chance to make my mistakes before I've committed them all to a big commercial release. So this is a tried-and-true practice of making you guys my guinea pigs. And if the demo doesn't suck, you guys get to try it out 6+ months before the full release of the game. And get to brag to all the non-cognizati about how much influence you had over the development of this masterpiece. Well, assuming you want to admit to playing it.

Based upon that feedback (besides the "Release the Mac / Linux Version, You Cretin!" comments), we're going to make some modifications to the game. Take it back to the dungeon workshop, hammer out the kinks, and fix what you felt was broken. The rest of the content (which I currently estimate to be about 5x larger than the demo) should still be early enough that significant changes to the game system shouldn't be a humongous impact.

The Full Version
Now, I cannot promise your characters and saved game from the beta demo will carry over to the final release. In fact, I can almost promise the opposite. Sorry 'bout that, but that's beta for you. While I foolishly hope that the first chapter of the game will be so perfect it won't need to be revisited at all, I honestly do expect it to change a bit. Abilities will need to be tweaked and rebalanced, monsters and treasures may need to be changed, some more story development may need to be done, etc.

The full version of the game will lead out with a PC / Windows version. I plan to follow it up with a Mac version. I mean, after all, I chose the game engine specifically because of Mac compatibility, so you'd better believe I plan to take advantage of it. But I haven't done any Mac development in 15 years, so it's gonna be a learning experience for me. A Linux version is still up in the air, dependent upon the reception of the game, as is future expansions and sequels. We've been getting TONS of ideas for future development of the Frayed Knights universe, and I'm trying not to get too excited about follow-ups while I'm still in the middle of development for the original game. Which, as far as I know, might flop.

But hey, that's why I'm taking this approach. Hopefully you guys will help make sure I'm not going in the "flop" direction, right? How does this plan sound to you? Whadayathink?

Discussion on the Frayed Knights Forum! Be There, or Be Somewhere Else!

Labels: Biz, Frayed Knights, Roleplaying Games

- posted by The Rampant Coyote @ 11:09 AM (Permalink) 9 comments links to this post

 
Frayed Knights: Save Me, You Jerks!
Problem: You and your adventuring party find a hottie chained up in the awful evil dungeon filled with nasty monsters, probably awaiting some horrible fate. What do you do?

Solution: If your answer was to rescue her, you may have fallen pray to one of the oldest tricks in the book. If you are an old-school pen & paper RPGer, that is.

And if you happen to be one of the Frayed Knights, you get into an argument over whether or not to rescue her. Because everyone except the new guy in the party (Benjamin) realizes there's a better-than-even chance that she's going to stab you in the back on the way back out of the dungeon. With a snipe or two from the ladies about how this kind of trap is designed for typical parties of all-male adventurers, who think with something other than their brains in these situations. Now, this sort of communication and discussion of conflicting opinions isn't necessarily a bad thing - except when the subject of your argument happens to be standing RIGHT THERE behind a cell door (something she keeps pointedly reminding her potential rescuers...)

So what will you do? And what will SHE do if you rescue her? Well, only you can answer the first question (both options are acceptable), and I ain't gonna tell ya the second. You are gonna have to figure that one out by yourself. I just brought it up as an example of some of the clichés that I am trying to not avoid, but rather highlight, in the games' design. If it is a cliché, the Frayed Knights will often recognize it as such. And I'm trying to build the world so that those clichés (or conventions if you will) are explained.

And it's just too funny to see the Frayed Knights argue about whether or not to rescue a girl. Kinda tosses heroic fantasy on its ear. Okay, yeah, so they kinda did it in Raiders of the Lost Ark... but not quite like this. Oh, and you'll see that the Torque Elf is happily filling in for the Potentially Evil Traitor Girl Who Claims To Be In Need of Rescue in the picture. That's the beauty of stand-in art. At least she resembles a girl. Somehow Kork the Torque Orc just wouldn't have been the same...

On Long Hours
Well, I spent a lot of time at the day job this week, which has turned into a day-and-night job. Ugh. But it pays the bills. I'd love for that to change, and who knows? Maybe Frayed Knights might go on to sell tens of thousands of copies in just a few short months! And those monkeys might start flying out of my butt any moment now...

And then there was the matter of playing Aveyond 2 and Eschalon: Book 1 (and a li'l bit of Galactic Civilizations II + Dark Avatar). Which helped me keep my sanity amidst 12-hour workdays. All three are great games, BTW... go indie! Maybe they were so good because I was hallucinating half the time - and man, that Cyclops was, like, RIGHT THERE, man!

But work I did, and sleep I did not... well, not very much, anyway, even for me. It's hard for the brain to do heavy lifting late at night when you didn't get enough sleep the night before, so I largely kept things simple. Stuff like just getting the lighting right in levels can be surprisingly time consuming, by the way.

Pokmor Xang Revisited
James got the "real" statue of Pokmor Xang done (well, the first version at least) this week. After getting him placed and lit correctly, I think he looks more twisted than I had hoped. We added some corrosion to the brass (you didn't think those cheapskate cultists would actually have made him out of GOLD, do you?), which really helped make him look ... ickier. James also decided to spend polygons on making the jeweled pimples & blisters actual 3D objects rather than textures. Seeing those things... er... pop out at you... really makes a difference!

So here is happy Pokmor Xang, ominously lit from below and in front... Now, would YOU accept a donut from this guy?

What's funny (again, possibly caused by too little sleep) is that I feel like I have been LIVING in this dungeon lately. I hope the other ones will go much faster than this (since I'm learning as I go, and developing code as I need it). It's like back when I was playing too much EverQuest, and got to know Cazic Thule and Howling Stones like the back of my hand.

Technical Stuff
And it was a voyage of discovery for me. Some fun things I learned about Torque this week:

#1: Torque translates a negative translation about an axis into a positive translation around a negative axis. Something to bear in mind when you have to move collision volumes around because Torque Doesn't Animate Collision Volumes! Grrr! Okay, I understand there are good (well, not good, but reasonable) technical reasons for that, but it's still annoying.

#2: Torque translates a rotation of zero (or even "close to zero") around any axis to a rotation about the X axis (pitch). So if your object suddenly changes axis when you are monkeying with it algorithmically (for the reason above) - well, now you know. Surprise!

#3: Torque Constructor's export to legacy dif format was obviously not carefully tested with the last release. Since I'm still running on the 1.4x code base (it's seriously Frankencoded, so upgrading to 1.5x may not be a reasonable option), I have to do this, and Constructor pretty much chews it up and spits out an ugly mess that resembles a transporter accident aboard the starship Enterprise. Fortunately, the command-line tool map2dif_plus.exe is my friend. I just skip using the internal exporter (that sounds like an oxymoron, doesn't it?) and run it in another window.

I also spent some time this week working on level initialization and re-entry. Not that you can leave the dungeon and come back yet (or even save the game and re-load it yet). If a door has been unlocked, a trap set off, a treasure chest looted, and a boss slain, you don't want those to reset every time you come back to the dungeon. Well, okay, maybe for some games you do, but not for this one. This part is still not "done," but the framework is there.

What's Next?
I don't know yet what next week will look like. Our goal is to have the Temple of Pokmor Xang wrapped up and "alpha ready" by the end of the month. That's still a lot of work to do in just over three weeks (particularly with the holidays and ... well, crunch-mode).


(Vaguely) related half-conscious musings:
* RPG Design: Quest Abuse
* Frayed Knights: Prologue - Background and High Concept
* Wandering Monsters and Random Encounters
* To Sleep, Perchance To Dream...

Got Something To Recommend? Here's a Forum Thread On This Article!

Labels: Frayed Knights, Roleplaying Games

- posted by The Rampant Coyote @ 2:42 AM (Permalink) 3 comments links to this post

 
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 i