Frayed Knights: Resting, Sleeping, Fatigue, and Exhaustion
It's time for another of those updates on Frayed Knights, the upcoming indie role-playing game that refuses to take itself too seriously. This week we're gonna talk nuts & bolts of the game some more. If the topic sounds tiring, it's because that's what it's about --- getting tired.

Adventurers lead strenuous lives. When they are slinging spells and swinging swords in life-or-death conflicts, or traversing treacherous trap-filled, uh, territories.... they are traveling great distances, hunting quest threads, and performing conversational acrobatics. All while lugging around more equipment and loot than any human could really be expected to carry. It's an exhausting career choice!

So unlike certain other, newer RPGs, the heroes of Frayed Knights are not going to be able to go all day without taking a breather or getting some well-deserved shut-eye. Well, probably not. Unless you blow all your silver on Liquid Nap potions. But that's another story.


So here we have a screenshot of a situation you'll find yourself in frequently in Frayed Knights - turning in for the evening. In this instance, it's at an inn, and you'll have to pay to rent the bed for the night. Or day. Or ... well, generic sleep-period. Whatever.

Those who have played the pilot episode (man, is that thing still around?) will note that there's a little campfire icon in both the standard and combat control amulet in the lower right. That's to "Rest" ("R") - which is something pretty different. Ah, now I should probably explain the difference. I'll have Chloe demonstrate.

Here's Chloe. Above her icon, she's got two colored bars. The top, red bar is her health. Running out of health is bad. It doesn't kill the character in Frayed Knights (or we'd run into all kinds of problems with characters having conversations with dead people). But it does incapacitate them. Which means they can still talk, but are not really good for anything else until they are restored. That takes a good night's sleep. So there's one reason for spending your hard-earned silver in the local inn.

But wait, that's not all!

The blue bar below that is the character's endurance bar. Endurance is what allows the character to act. There's no "mana" or other spell-casting limits in Frayed Knights... it's all endurance. It's used to swing swords, cast spells, whatever. When the endurance drops to zero, a lot of things happen, depending upon whether or not the party is in combat. But the basic problem is that the character immediately gets a penalty to pretty much anything he is doing that caused endurance to drop to nothing. On top of that, any roll the character is forced to make - like defending against an attack - is going to be made at a fairly steep penalty. While not exactly a sitting duck, a fatigued character just lacks the energy to dodge well. Finally, if the party is in combat, the fatigued character automatically takes a "rest" action as their next move, to get the endurance bar back into positive territory. This means a character running on low endurance is going to be a lot slower on all of their actions - because they will have to waste precious combat cycles resting.

What exactly does resting do? In combat, rest restores a certain number of points of endurance - reducing temporary fatigue. And it takes up time - time where the monsters may use to do horrible things to your health bar. But it should really be thought of as "taking a breather" or pausing to catch one's breath. The player may voluntarily choose to have the character rest at any time as the character's action - mainly to avoid having endurance drop to zero and taking those penalties.

Outside of combat, resting is always voluntary and effects the entire party at once. The entire party rests however long it takes for everyone's temporary fatigue to be eliminated. Probably. It's almost instantaneous for the player, but time passes in the game exactly as if it were combat - a number of turns pass for everyone to rest up to maximum endurance. This means spell effects can expire, and there are multiple chances for monsters to show up and ruin everyone's break-time.

So that's how resting works.

While catching quick breathers and short rests may be enough to take you over the next hump, there's only so far it can sustain you. A marathon runner is going to need more than a five minute break after one race to be ready to run competitively in another. Sooner or later, characters will become exhausted and a quick breather won't carry them very far anymore.

You'll note that Chloe has a little gold marker - a ring - around her endurance bar. This represents long-term exhaustion. As the character builds up temporary fatigue, they also build up long-term exhaustion (at a much slower rate). Exhaustion acts to limit the character's maximum stamina. The little gold ring starts all the way to the right - the character can tap their entire reservoir of endurance - and then very slowly slides over to the left.

It eventually stops, so the maximum endurance will never be completely reduced to nothing. But at max exhaustion, characters only have about a third of their maximum stamina to work with. That means that "zero stamina" danger level comes much, much faster.

Exhaustion can only be cured by sleeping. That means finding a place to sleep. Or, alternately, pumping down a potion of Liquid Nap, which isn't quite as good (and won't restore an incapacitated character), but works better than Red Bull.

So the overall gameplay effect is that there is some level of long-term resource management that you will need to pay attention to in Frayed Knights, but you never have to worry about completely "running out" of spells or whatnot.

A side-effect of the way I did this - with endurance being the limiting factor to spell-casting - is that I must be very careful about providing any spells that restore endurance. If that's even possible (and I'm still uncommitted either way), I have to make certain that the laws of thermodynamics apply to magic. Specifically, entropy must rule - casting a spell to restore endurance must always cost more than restores.

Labels: Frayed Knights, Game Design

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

 
Frayed Knights - Talk Ain't Cheap. Apparently.
So it's about time for another update on the development of Frayed Knights, the upcoming tongue-in-cheek indie RPG coming from Rampant Games.

I knew when I signed up for it that making an RPG would be a pretty significant undertaking. I had expectations of a lot of work. Even though I had elevated my expectations of the amount of work I had to do, there were a couple of areas where I woefully underestimated the amount of labor involved.

And dialog is one of those areas. I mean, it's just text, right? Sounds easy! I'm not even doing voice-overs for this game!

If my quests were just of the "bring me six rat tails" variety, and my dialogs were of the one-or-two-line variety, I wouldn't have so much work to do. Now I know why other games do that. I'd have three things for an NPC to say: "Hi there, get me six rat tails!", "Hi! Do you have my six rat tails yet?", and "I see you brought me six rat tails! Here's your reward!" No other NPC (Non-Player Character... anyone not controlled by the player) in the world would care or be involved in that quest in any way.

Easy. Simple. Straightforward. And of course, not what I chose to do.

Somehow I imagined my "slightly" more complicated questing would only be slightly more involved in developing. Hah! No, I have to had to make quests that involve multiple NPCs who respond contextually to the changing situations and are sometimes involved in multiple quest-lines. So I have to deal with how the event in one subplot might effect their responses to the other quest. Oh, and my dialogs aren't little two-line monologues, but complete conversation scripts with the party (which means I can't just mechanically string them together).

Just for an example (and I know I've done this before), here's a single set of quest-related dialogs that would need to be implemented for a single NPC involved in a single quest with three non-linear subgoals:

Introduction - first-time meeting
Not on quest
On quest, no objectives met
On quest, objective A but not B and C met
On quest, objective B but not A and C met
On quest, objective C but not A and B met
On quest, objectives A and B met
On quest, objectives A and C met
On quest, objectove B and C met
On quest, all objectives met (give reward & finish quest)

Oh, and while I'm at it, I should try and come up with something vaguely humorous with each variation. And I need to test these dialogs and quests - repeatedly - by doing things out of order, and testing the robustness of the scripting and just how many punctuation errors slipped through my dialogs.

Seriously, if I skipped the "testing" phase, this thing would go about 10x faster.

Now, I have chosen to take a slightly rougher path than your average indie RPG developer with respect to quests and NPC dialog. But I don't suspect Frayed Knights is totally unusual in this respect. I'm compensating by having fewer NPCs. I can't really imagine right now having the number of towns and NPCs of Aveyond 2. I just really, seriously underestimated the task.

So I'm just ... pushing on through, and trying to simplify where I can. And looking for ways of streamlining the process.

But mainly I'm just suggesting to other would-be RPG makers that if you expect character dialog to play a significant role in your game... be prepared for lots and lots of writing. My appreciation for how much writing goes into something like a Bioware game has gone up considerably.

In other news - content continues to be developed. We've got the lizardman lair from the Caverns of Anarchy just about wrapped up, and I've got the second village (Roark's Folly) about 80% built (sans NPCs and all that dialog-writing). Kevin had to re-do a lot of the Gloomspire Castle a few weeks ago from Act 3. It is quite the major construction, as you can see here:


So we've made some more excursions from Act 1, which felt pretty good. I think the later acts are going to be a bit "tighter" than the first one - mainly because each month I feel we have a better handle on what it takes and how we could do it "better."

But now I'm back to focusing on getting Act 1 100% playable. It's important. Many days, I'm not really sure what to make of all this. At times, it's simply stunning to stand back and take a look at all we've accomplished so far. And then, it's even more stunning to look at how much more needs to be done. I think getting the first act fully playable (if not "finished") from end-to-end will really help in that respect.

Labels: Frayed Knights, game development

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

 
Frayed Knights: Act 1 Not Quite Ready For Prime Time
Of all the updates on the development of the indie RPG with a decidedly goofy mood, Frayed Knights, I have no doubt that this one will prove the latest one to date!

I have discovered that my old and creaky laptop is no longer quite up to snuff for full-on development of Frayed Knights. I think it may barely be able to play the game, but as the game chews up over 300 megs of RAM when the largest level is loaded, it doesn't leave much on an old 512-meg laptop overwhelmed by numerous OS updates, a virus scanner, and development tools. You know performance is gonna suck when, the third time you are transitioning between major areas, you get a warning that you are running low on paging room in virtual memory.

Guess I shouldn't have been running Pandora and checking my stocks in the background too, huh?

The loss of the desktop - and the unexpected business trip to Puerto Rico - definitely slowed development of Frayed Knights a bit this month, but we still made progress. My new desktop should arrive soonishly maybe (it's already a week late, but has apparently been built and is in QC), so that will help give development a kick in the pants. In the meantime, I have been working where I can, and decided last night to give the entire first act a "run-through." At least starting from the "morning after" the events of the pilot. I knew there were some gaping holes remaining in the first act, but it was past time to experience it as a whole - as a player. Some parts haven't been touched since July, so I'd forgotten a lot of what was done and what was still incomplete.

So I jumped in, starting with Benjamin trying to make up with the other Knights. It's a short little dialog - pretty much a transition from the the more restrictive action of the Pokmor Xang pseudo-tutorial to the main storyline and more open-ended gameplay of the full game. He rejoins the party, after a couple of wince-inducing typos, and the adventure is afoot! Woot!

Oh boy!

Oh, crap.

It was kind of a painful experience. Really. Testers keep asking when they get to test the next version - trust me, you don't WANT to test this one. The list of broken NPCs, broken quests, visual problems, missing text, and otherwise not-working things was pretty frickin' long. Act 1 is not "fully playable" at this point. Dang it. And I was already rolling right along to Act 2... (and Kevin is still working on content for Act 3).

Besides what isn't working or what's missing, there's the stand-in content. Stuff that technically works but is kinda butt-ugly (see above screenshot), and generic off-the-shelf creatures filling in for different kinds of monsters, and just plain ol' empty, boring rooms. Lots of work left to do there. I also realized that there is really not enough direction given to a player who might not be sure what to do next. I need to add significantly more dialog and explanatory text.

So that's the bad news. Is there good news?

Well, yeah. Kinda. If you squint hard, you can see a game playing out on the screen. Most of the pieces are in place for Act 1 now, finally. While not "fully playable," I was able to play for over an hour (and that's cheating to breeze through combats quickly) before a bug left the game kinda--- done (and missing Chloe). With a couple of glaring exception, the questions have mostly now gone from being "What needs to be created?" and "What needs to go here?", to "What do I need to fix?", "What do I need to replace with final content" and "How can I improve this part?" Oh, and the occasional, "WTF?" and "I coulda sworn I fixed this! How can it be broken again?!?!?!"

This means lists. I can work lists. It is long, tedious work, but measurable. We're also steaming ahead on Act 2. And Kevin, as mentioned before, is working on Act 3. Assuming my new desktop arrives soon (and in good condition), progress should be resuming previous speed (or faster, please) in short order.

But for now, to reduce my terror I am going to squint really hard...

Labels: Frayed Knights, game development

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

 
Formula, Innovation, and Compromised Ideals
One part of my desire to create indie RPGs (and indie games in general) has been to do something different. To break the mold, make games that push the comfort zone, do something different, cross arbitrary category boundaries imposed by marketers and journalists, shatter preconceived notions, and really expand the horizons of what games can be.

And then I find myself - and other indies - doing the same ol', same ol'.

This is not really an indictment. But it was bugging me a little a few weeks ago as I was implementing one of those "find the n-part key" quests. In this case, the key is a spell broken into three parts that must be joined together to form an arcane password that... well, you get the idea. What it really amounts to is, "Make sure the player has explored these three locations before letting them move on to the next part of the game."

It's lame. It's trite. It's overused. It may not be completely creatively bankrupt, but it's definitely in need of overdraft protection. But it works, dagnabbit! It's been disguised in many forms, but it comes down to a simple mechanic that's not too far removed from hunting the down the colored keys in Wolfenstein 3D to get to the exit.

A lot of folks (myself included) evangelize the indie game movement as this incredible revolution of innovation and ground-breaking ideas. And this has definitely been the case. Just this last year, there have been some amazing, innovative (and sometimes downright STRANGE) indie titles released that have even questioned the very definition of the term "game." The Path comes to mind.

But that doesn't mean indie games must be constantly running on the ragged edge of innovation. How much "new" does a game have to provide? And what constitutes "new"?

Ultimately - if a game is in any way commercially oriented - it has to be geared to appeal to the audience. That is what must drive innovation, not the other way around. And that is not a simple equation. Sure, players and critics alike claim they desire innovation - something new - but at what cost are they willing to obtain it?

Brian "Psychochild" Green recently wrote about the problems of innovation, and refers to it as a paradox - innovation comes at the expense of other things gamers value, such as high production values, polish, and "perfection" of core game mechanics. And innovation is risk. Almost by definition. If it ain't broke and you try and fix it, somebody's not going to be happy about it.

I don't know if that excuses me from falling back on tried-and-true formula. Or anybody else. It behooves any game designer to question their design choices. But I don't think that picking one's innovation battles and otherwise sticking with a foundation of familiarity for players is necessarily a compromise of one's ideals.

At least that's my story and I'm sticking to it.

Labels: Frayed Knights

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

 
Frayed Knights and 3D Worlds - More Trouble Than They Are Worth?
I keep ranting about the same subject, I guess. I keep re-discovering how painfully slow even fairly simple level / interior creation can be. Even for a simple, low-detail RPG like Frayed Knights. I get really jealous of those tile-based games where an entire map can be put together in hours.

I've gained some speed and, I think, quality as I keep working on things (I'm kinda embarrassed about the Tower of Almost Certain Death now...). But it's still astonishing to have worked on a relatively small part of the map - wall piece by wall piece, basically - and then look at the clock and realize that over TWO HOURS have passed by, On a map I thought I could "whip out" in only six or eight hours, total. Yeah. Time to multiply my estimate by at least four.

And that's not including going back later to make that sucker look GOOD. For flexible definitions of good.

You think I'd learn.

I'm trying to imagine how, in my wildest dreams (which maybe aren't wild enough), this game could possibly turn enough of a profit to even earn minimum wage (and we'll go by minimum wage a couple years ago, not even the new minimum wage now) on the time I've put into it. Let alone the time my fellow team members have put into it. I would love to be surprised and have my world rocked, but in all likelihood - it ain't gonna happen.

We've tried a few things to speed things up - like creating more pre-made pieces - but so far it's just not given us the time and effort savings we hoped for.

There's a reason indie game development is a labor of love. And I really do have a lot of fun doing it. I just wish I could figure out how to get it done... faster.

Labels: Frayed Knights, game art

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

 
Frayed Knights - The Adventurer's Guild
Welcome to another installment of dev diary / commentary on Frayed Knights - the unabashedly tongue-in-cheek indie RPG forthcoming from Rampant Games.

This time, I want to talk about the Adventurer's Guild.

Those of you who played the pilot may recognize the Adventurer's Guild as the reason our non-traditional heroes are seeking the Eyes of Pokmor Xang in this "test" adventure. The Adventurer's Guild plays a role in the storyline of the full game. But what is the Adventurer's Guild?

The Adventurer's Guild was started over ten years ago by Argus Stormhammer, a veteran and highly successful treasure hunter / adventurer. His fame came not only from his successes, but also by his tracts which he created to try and help other adventurers. In these pamphlets, Stormhammer noted that he had seen many a fellow adventurer suffer not only loss of life and limb, but failure and insolvency. His writings not only aided fellow adventurers, but inspired many people to take up the the life of an adventurer.

Argus sold the pamphlets through various merchants, but as demand for his writings grew, so did the number of people who came to him requesting personal assistance and training. He had become the guru of fortune-hunting. As the demand for his services and writing threatened to overwhelm him (and left no time for actual adventuring), he decided to delegate.

He created the Adventurer's Guild to be a network of service providers for fortune-hunters all over Kaldera. Not only would they distribute his growing number of tracts and other treasure-hunting self-help books, but they would provide critical services and training to guild members:

1. A clearinghouse for rumors, reports, and opportunities
2. A meetingplace for hiring / partnering with other adventures
3. Contracts (bounties) for rescue should an adventurer or group not return by a certain time. Basically, you pre-pay a reward for people coming to rescue or recover your remains.
4. An adjudication system for conflicts between adventurers
5. Legal assistance for adventurers (who often run afoul of the law or need to have a will drawn up)
6. Appraisal services for rare items of collectible or magical value.
7. Training, training, and more training
8. Sponsored missions
9. Rapid communication between guild houses
10. Member discounts on adventuring equipment (usually used)

Due to some unfortunate circumstances early in the creation of the Adventurer's Guild, membership is no longer open to anybody who calls themselves an adventurer and is willing to pay the dues. A prospective member of the guild must prove themselves with accredited action prior to acceptance in the guild. While some services are available (at a fee) to non-members, the most valuable services are strictly for members only.

Would-be members complain that this Adventurer's Guild members an overwhelming advantage and a jump on any possible opportunities, leaving slim possibilities for the non-guild member to "prove" themselves.

The Adventurer's Guild has responded to this complain in the last year by offering some sponsored "quests" to non-members only, with success resulting in automatic accreditation. Again, this solution is imperfect. Several non-guild adventurers claim that these missions are excessively dangerous without guild training, and many adventuring groups do not survive their "audition." They also complain that these quests are exploitative, paying only a tiny fraction of the value of recovered artifacts that the guild, with its connections throughout Kaldera, can obtain. And finally, while completion of these quests do tend to provide a "fast-track" into guild membership, it is by no means guaranteed. Many contend that this is an unfair policy that exploits non-members that the Guild has no intention of recruiting.

These issues notwithstanding, membership in the Adventurer's Guild seems to make a tremendous difference in the success and survival rates of adventurers throughout the kingdom, so nearly every fortune-hunter aspires to join its ranks.

Labels: Frayed Knights

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

 
Frayed Knights: 2:30 AM Ambushes
As usual, I started losing productivity after about 1:30 AM. And after 2:00 AM, I should have called it quits. But I didn't. Because I was ... almost done. I am just testing now, see?

Yeah, right. So now it's almost 2:30 and I find myself walking into an ambush, not remembering how I got here.

When I open my eyes (after just blinking for a moment... I'm sure), I find myself in the hobgoblin bunker. I realize I was in the middle of testing something, but for the life of me I cannot remember going through the entrance, fighting through two waves of attackers (I have a cheat key installed that auto-kills all enemies... it makes testing a bit faster) to get to the landing where I am now subjected to scripted arrow fire.

Vaguely I remember what I'm supposed to be doing. I've bypassed two guardrooms to get to the split-level chamber. At least I think I have. Since I've apparently been sleepwalking through the dungeon, I can't be certain. So what is supposed to happen is that two waves of reinforcements should arrive after this battle - not exactly an ambush, but a rough situation. Then, going back, I have to make sure that the rooms they vacated to reinforce / replace the archers are truly vacated.

I'm not entirely certain if this is going to play out to my liking. There is definitely an optimal path to try and ambush-the-ambushers, coming around from behind (after emptying out the guardrooms) to avoid the arrow fire and kill the archers. But aside from trial-and-error, I'm not sure how to telegraph this strategy to the player. It's not a make-or-break strategy - it's definitely a winnable combat regardless - but it does make things a bit easier.

Not that this occurs to me much at 2:30 - make that 2:35 - AM. This is about my sixth or seventh run-through tonight, and I'm more concerned about the fact that in the first guardroom - the one that rushes out to attack you instead of waiting for you to open their door - is still rushing to attack even though I killed them all in the previous room. not that a player would necessarily realize it's the same group... except I need to leave their door open. Yes. The guards need to open their doors when rushing out to reinforce the archers.

One more thing to put on the long, long list of Things To Do.

I make some changes to the script. Save. Run. Select start, which is currently hard-coded to load the Caverns of Anarchy. Wait through loading. You think load times suck as a player? Try being a developer and having to reload every single time you want to test a change. You folks who have scripted up Neverwinter Nights modules know exactly what I'm talking about.

Uh... where was I? I zoned out again. What time is it? 2:40 AM. Crap. I have to get up in less than five hours for work. Using the insta-victory cheat key I run through battle one, battle two, battle three with two sets of reinforcements... and then test the guardrooms (with doors still closed) - HAH! They are as dead as they should be. Nothing left to do but loot the empty rooms.

2:44 AM. Enough time to hopefully get four-and-a-half hours of sleep. Of course, when my head hits the pillow at 2:52, I still have visions of hobgoblin ambushes and gameplay concerns about the fairness of allowing hobgoblins to shoot at long range with impunity while the player must charge into melee range. Fortunately, sleep comes fast.

And the alarm clock goes off almost as fast, in subjective time. The day job beckons. Or, rather, demands. It's paying for this lifestyle, after all.

This is the life of a part-time indie game developer. Of this one, at least.

Labels: Frayed Knights, Geek Life, Indie Evangelism

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

 
Frayed Knights - How I Build A Dungeon
It's been a little while since I have posted an honest-to-goodness update on Frayed Knights - the comedy-based indie RPG from Rampant Games. So I guess we're due.

Today, I'm going to talk about how I build a dungeon. I do not pretend that this is the correct - or even a competent - way to do it. It's just how I do it. Members of the development team who are also working on dungeons for the game (Kevin and Brian) may do stuff differently - and much better than me, I should add.

But it's still me who ends up populating and scripting them.

First of all - my design document (when I update it) doesn't have much by way of specific information about each dungeon (or "adventuring area", if it's an outdoor location). Really, I don't have much more than some basic themes and objectives for the location. Maybe some specific events that need to happen here (like, "a prisoner has a hint as to the identity of Moonshadow.") And then some key "signature" locations that serve those encounters.

For the guys working on levels for me, I have to provide a bit more up-front work. Or a lot more. But for myself, I start out without much more than just that. From there, I sketch up a very rough map. And start planning encounters / events. More on planning encounters later.

From there, I build a walkable floor plan. I've recently gotten to the point where I just build the floor plan first and export the entire area to the game engine - floating in the air in a test area. And I use it for a walk-through as the level evolves. This helps me get a sense of scale, what's working, and what doesn't. I like to use vertical elements in my levels, and helps to find out early that I don't have enough headroom in one part of the dungeon and I need to kick things out a bit. These days, I'm doing all my interior-building with Torque Constructor. It's ugly and old-school, but it works well for this engine.

After I'm satisfied with the floor plan, I build the rest of the location around it. This can be pretty time consuming, especially with making sure textures line up correctly, adding some detailing (I'm saving the really careful detailing and "prettyfication" for the end). Changes do take place at this stage (really, at any changes), and large swaths of my construction may be changed, deleted, or expanded. The floors may get shifted and broken into smaller pieces as I try to vary the geometry to make things look more interesting, etc. In fact, the whole process is very iterative - at any stage I may get new ideas that I want to try, I may go back and change something to make an encounter work better, or I may get a new idea for an encounter / event by working on a particular spot. It's not exactly free-form, but it's not a strict assembly line (or "waterfall model," for programmers) either.

Now, the big trick here is planning encounters / events. This is also very iterative. Some get planned out (in rough detail) before anything else starts. The dungeon design may center around them. Others don't get planned out until the very end. I find myself with a relatively boring area without anything else happening, and I think, "What would be cool to have happen here?"

I thought this would be a lot easier to create these encounters than it is, given the amount of time I've spent planning pen & paper adventures or making Neverwinter Nights modules, scripting MUDs, and so forth. But it gets very, very easy to run into a game designer's version of "writer's block." Maybe it's all the pressure of making something intended for a much wider audience than my usual circle of friends. I don't know.

What I do know is that I don't just want endless encounters of monsters that just hang out in their rooms waiting to fight adventurers who happen to kick the door open in a straightforward brute-force slugfest. Sure, we've got that too - but I don't want that to be the meat of the game. I want puzzles. Tactical challenges. Memorable encounters. Unfortunately, that requires me to "be creative" - not to mention spending a lot of time scripting / programming.

What I recently discovered was that one of the things causing the block was that I kept thinking in terms of the existing code and capabilities, and what I could do with it. My real breakthroughs came when I just thought through the dungeons in a lot more free-form fashion, and then later started figuring out how I might implement it with existing (or new) code. Sometimes, by attempting to frame the idea in terms of existing limitations, I find myself with an even better idea.

The problem is that these "out-of-the-box" ideas often require a lot more scripting, code, and / or content support. But I think the final results will be worthwhile.

Now, to answer a couple of questions I've been been asked. Answers subject to change without notice.

#1 - When's the next "alpha test" of Frayed Knights?
The pilot was an early experiment to help gauge where we were going with the game early on and make course corrections where things just weren't working out. Right now, we're going full-out to make the game fully playable, but not necessarily pretty or ready for human consumption. I don't want to take the time out (yet) to make a new playable demo. So probably not until we're literally alpha and switching gears from pure building.

The next one may not be quite as "open" the first one was. But I will desperately need testers.

#2 - When do you expect the game to ship?
I'm hoping 2010. But I was originally hoping 2009, so apparently my ability to estimate this project is for crap. I keep expecting to hit this magical zone where development accelerates speed because it all becomes "old hat" to us, but that's not happened.

#3 - How Big Is This Game?
Too Big.

In an interview at RPGWatch, I said I expected the full game to be "six to ten times larger than the pilot." As it turns out, that's just the first act. Of three. Feature Creep Strikes Again.

But dang it, I do love this game. Warts and all.

#4 - Have you considered breaking the full game into three parts and selling them individually?
Um... Considered, yeah. Made a decision? No, not yet. It wasn't in the original plan, so I haven't worked out how I'd try to break it up that way yet. But if we do go that route, I'd want to be a lot closer to completion, so there wouldn't be a long wait between installments.

If you have particular opinions on that subject, let me know.

Labels: Frayed Knights, Game Design

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

 
Frayed Knights: Some More WIP Screens
For those who don't frequent the forums:

Screenshots from the Hobgoblin Bunker

These are still very much work-in-progress, and pretty raw, but I warned you that would be the case, didn't I? I'm still a beginner level-designer, so these won't be set-piece levels or anything. But there are some pretty basic levels where I figured even my n00b skills wouldn't do too much damage.

What I did notice is that this was far easier to create than the Tower - partly because it's a much simpler design, but also because I think I'm sucking a little less. Go, me!

Labels: Frayed Knights

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

 
Frayed Knights; Wait, Wait, Let Me Explain...
The world of Frayed Knights, the indie computer RPG under development at Rampant Games, could perhaps be described as an apologist's rendition of an old-school fantasy RPG campaign.

In the early days of the hobby, very few game masters (or game designers) thought too hard about the rhyme, reason, or ecology of their adventures and worlds. Why are the monsters segregated by difficulty level in this dungeon? What's with the weird, bizarre artifacts in the dungeon that nobody but the players actually try to use? How come these traps aren't set of by the gazillions of giant rats that seem to infest the dungeon? How do the lower levels of the dungeon stay ventilated? What do these monsters eat (besides adventurers and giant rats)? Why are there all these devices that serve no practical purpose to anybody but to vex the occasional treasure-hunting adventurer?

The creativity caught up with itself as players smartened up, and game masters were forced to evolve. After all, if you have an illusory dragon in one room - the hint to the deception being that the exits are all too small to accommodate the dragon's bulk - then you can't get away with sticking a real dragon in a similar room without some really good explanation. If you start using logic and some vague appeals to reason against the players, you need to be pretty consistent with its usage yourself.

So which is it going to be - no dragon, or jumping through hoops to justify its existence?

In many cases, Frayed Knights takes the latter approach. I think the wild contortions of logic and rationalization are part of the fun of the world. It's not necessarily that the world itself is over the top bizarre and comedic, but that the off-beat answers to the questions of "why" have a cumulative effect that keeps getting weirder and weirder. And then we have a group of explorers in this world for whom this is all pretty run-of-the-mill stuff.

And so what you end up with is a group that can get into an argument over whether or not it is wise to rescue an apparent damsel-in-distress... because it is one of the oldest tricks in the book to sucker-punch adventurers in this world. And bizarre relationships between groups of monsters to justify their not killing each other.

But as amusing as the "Why" answers get, it's the "why not?" that tends to drive the silliness. If you postulate a world where there's weirdness X and Y, why not ... weirdness Z?

That's where I got temples dedicated to a god of pimples. And an automaton constructed out of pus.

And, as it turns out, getting the answer to the "why" questions is what drives the entire plot. It's one thing to know that an Ancient Evil™ is on the rise. The natural response for your typical red-blooded adventurer upon discovering this news is to put a stop to the Ancient Evil™ once and for all (at least until the sequel).

But our heroes, the Frayed Knights, are anything but typical. And - quite by accident - they end up asking "Why?" Why is the Ancient Evil™ rising? What does he really want? Is there something more going on here?

And, as usual, the answers get more convoluted as they go.

Labels: Frayed Knights

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

 
Frayed Knights: Why Is This Game Taking So Long?
And here are a few words of update on the making of Frayed Knights, the comedic indie RPG in development by Rampant Games.

If there's a single common thread linking several of these updates together, it is, "Things are taking longer than I expected." I've yet to hear of a game getting done significantly faster than expected. Making games is hard. You'd think that after fifteen years of doing it, I'd know this by now.

You know, when I was working on the pilot episode of Frayed Knights, I had a couple of ideas. Really silly ideas, in retrospect. I should have known better. While I've never made a full-fledged RPG before, I've made plenty of games. So I don't have an excuse. Maybe it's some kind of suppression of bad memories taking place that made me believe these things.

But here were my beliefs: That when I finished the pilot, I'd have "most" (75%+) of the code for the game finished, and that my job from there on out would just be cranking out content, which would be easier and faster than code.

Wrong on BOTH counts. But I'm just gonna talk about the code part today.

My existing code, in many cases hastily thrown together just to get the pilot out the door, was woefully inadequate for the true rigors that would be demanded of it. Or the demands of players. In some cases (like the inventory UI), I've completely replaced the earlier code. In other cases, I've had to augment the code to something like quadruple its original size.

And then all the little "bits and pieces" that were ignored / shoved under the rug? That was a lot more than 25%.

Then we have something that programmers jokingly call "bit-rot." It's how we describe our code seemingly "wearing out" and developing bugs as it gets older and remains unmaintained. Naturally, code doesn't rot or change at all with age. But it doesn't exist in a vacuum. As its environment and dependencies change, it may fail. Or we may expose bugs that were always there but never visible. Or we call functionality that was never 100% done in the first place. Or... something.

So what happens is that code that was "working perfectly" (hah!) before suddenly, inexplicably, begins failing. New bugs crop up in old code that hasn't been touched in MONTHS. In several places. And as you fix the code in one place, something else breaks elsewhere.

"Bit-rot."

So I've been spending a lot of time stitching things back together again. And integrating "proof of concept" code into actual working code that functions as it should in a real game.

Of course, there are other explanations, like my playing the Three Musketeers RPG or Knights of the Chalice instead of coding. I guess that's how those guys take care of their competition.

But hey, enough grousing. Here's what's new:

I've taken the visible "wandering monster" thing and made them actually part of the game instead of a tech-demo. So now you can dodge enemy patrols that you can actually see. But their respawn rates are dependent upon how well you've cleared the local area. There are still a bunch of issues to be ironed out there, but it's functioning.

I keep enhancing my dialog scripts to provide greater functionality within conversations. Now talking with people can give you XP or drama stars, give or take away items, set or modify game flags, or call an internal game function.

The area surrounding the Caverns of Anarchy is --- well, not done, but the principle geography is laid out. With a stagnant lake and everything. It's kind of a dismal place. But then goblins and lizard-men were never known for being brilliant landscapers. We've got two of the caverns "done," but they don't look much like caverns. That's kind of an issue when using the kind of CSG geometry we're using for interiors - organic-looking spaces are VERY VERY HARD to do. It's much better at representing regular, man-made locations.

Our explanation is that these caverns began as smaller, natural locations, and were later further excavated and built upon by their residents - who ended up living there for generations.

In spite of bug-fixes, all quests involving the Tower of Almost Certain Death should be completed this weekend (they should have been completed LAST weekend, but I kept getting distracted by other tasks), and I'll be working on some of the other quests and locations in the eastern wilderness and the "follow-up" scripting back in Ardin. The party gets (temporary) access to a major artifact and clues to a major mystery in the tower, and thus sets off the main storyline (although it was hinted at in the earlier parts of the game). This opens up the Caverns of Anarchy area, and Fishy Stuff Starts Happening.

Labels: Frayed Knights, programming

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

 
Frayed Knights: Skull-Drudgery
Some weeks, it feels like my progress on Frayed Knights is inexcusably slow. This was one of those weeks. Much of this last week has been devoted to a skull.

One. Frickin'. Skull.

And poetry.

Kinda.

See, I've been working on a little bit of "black triangle" stuff again. While I'd hoped to just start populating dungeons with all kinds of stuff, I've found myself having to go back and support a lot of new functionality. This is because I'm not satisfied just throwing a bunch of combat encounters in my dungeons and calling it done. I figure if that's all somebody wanted to do, they'll be playing Diablo III or something like that.

I want my dungeons in Frayed Knights to have a lot of things going on in them besides combat. Not that combat will (usually) take a second seat. But I want to have things to tinker with - little "micro-quests" going on - things to discover, things to talk to, things to experiment with. I want to be able to populate an area with lots of interesting stuff to do and tinker with and talk to and quest for instead of just fighting all the time.

I'd like each area to be a little mini-adventure game in its own right - but with some options rather than a single solution to every puzzle. Though at the same time, I worry if the environment is beginning to sound a little too "adventury." Did I just make up a new term? But if somebody wants to play an adventure game - well, thanks to the indies, there are a lot of new indie adventure games out there now, too.

Frayed Knights is written for - well, ultimately, for ME. While I loved adventure games back in the day, I haven't completed many of them. I'm kind of the dumb jock of the adventure game world. I enjoy a good smattering of puzzles. But I'm mainly there for the scenery, and when things get too difficult, I get frustrated and just want to KICK OPEN THE DAMN DOOR ALREADY. So I try to be careful to allow alternative, more "brute force" options where possible, and not to stray too far on the adventure game puzzle side of things.

And so the skull (there are a few skulls in the Tower of Almost Certain Death) was one of those things. It's got a playful and silly mini-quest associated with it, which didn't seem like it needed as much coding support as it did. I'm not really sure where the hours all went, except it seemed like I was constantly re-starting the game, testing, and finding out that something else wasn't working right, stopping, going back, hunting down the bug, and then doing it all over again. For HOURS.

My hope is that once I get some more functionality in place (and fully debugged), it'll be as easy to throw these kinds of quests together as it was when I was doing Neverwinter Nights scripting. That's not likely, but that's my ideal.

But as I've been doing this, I've found holes in my code that needed fillin'. I've had to write new code to support some of these activities. Some of 'em are pretty basic - like determining if anybody in the party has a particular item (and then supporting the expenditure of said item as part of a quest). But the real pain (and drudgery) comes from dealing with the expansion of all the combinations of the things the player may be doing, and making sure that not only the code and interface support it all, but that there is an appropriate conversation dialog for all of these situations (if talking is involved).

So there was a bunch of additional groundwork I had to lay recently that I hadn't counted on. Ah, well. Thus the apparently slower progress. But it's not been from lack of effort. As I said before - we're "white boxing" as much as possible to get things to a fully playable state more quickly, so screenshots aren't the prettiest. They won't be for a while, yet. But I do feel like we're making progress.

Brian has been working on the lizard man tunnels - which are also for this first chapter. While not fully textured (and looking a little too modern right now because of this), I like 'em enough that lizard men may have to have more appearances in this game (with similar dungeons).

So at this point, where are we in terms of content?

We have six indoor / "dungeon" environments that are functionally complete (but not all are detailed or populated yet). And we have two more indoor playing environments currently under construction. We have one town more-or-less complete (but not fully populated with all quest NPCs and so forth) - the expanded version of Ardin from the pilot. We have four outdoor environments currently playable (but incomplete), a whole bunch of small buildings, over a dozen functioning monster types.

I'm not gonna guess as to the hours of gameplay yet. But if you figure the Temple of Pokmor Xang was about average for the size of these dungeon crawls, that might give you some idea. And that's only about half of what's needed for the first act of the game.

So we're getting there. Just not as fast as I'd like.

Labels: Frayed Knights, Game Design, Torque

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

 
Frayed Knights - Dungeons &... Ferrets?
One of my favorite aspects of roleplaying games is the feeling of exploration. Discovering what's around the next corner, behind that door, below the stairs --- with the hope that it is something cool --- that's the kind of thing that thrills me. It's that promise of discovering the green dragon on the Persian rug or something, I guess.

Making an RPG - being the guy in the sausage factory - doesn't usually carry that thrill. Though I do get to indulge my own imagination a bit. But it is nice working with a couple other level designers. While they may start with a 2D graphed-out map and some descriptions from me, they invariably inject their own ideas (something I encourage!) and creativity into these levels.

And then they send me roughed-out maps. Which I then get to explore. I try to start with a walk-through of the dungeon via the game engine, experiencing as closely as I can as a player first. Besides inspecting it for issues (of which there are invariably several), I also try to explore and let my imagination run wild. While I may have my original notes for what sort of encounters go where, I don't consult these notes when I'm doing the walk-through. I'm just poking around, trying to get a feel for the environment, and seeing what direction my imagination takes me. One day I'll get better at actually recording those notes.

Brian decided to go a little nuts on the sense of scale with the goblin dungeon he decided to call "Vertigo."

I'm not really complaining. Though I don't have a clue how I'm gonna make the 2D, top-down map work on this one...

But this is really one of those times when making a game is more fun than playing it. Later, when I'm knee-deep in scripting and bug-fixing and have played through the same corridor a hundred times, I'll be good and sick of it.

But for now, it's exciting and fun, and I'm trying to capture the "cool" and sense of discovery and expectation in my mind for reference when one day... a few days from now... I'm feeling all weary and jaded.

One issue Kevin ran into with the castle was that - being modeled somewhat after a couple of real-world castles - it was actually pretty dang cramped and hard to navigate. This was a design feature in the real world - castles were defensive structures, and you wanted an invading force to be stuck in bottlenecks. And while a human being can duck, contort, and whatever to navigate these confines, this doesn't work so well in a computer game. Simple is king where navigating and collision detection is concerned.

We've opened things up a bit, but Kevin found that "realistic" staircases just couldn't fit very well.

We needed ladders.

So now we have ladders. I had fun getting the code to work. I tested it out on Shiela's ferret. Training a ferret to climb a ladder turned out to be exactly like training player characters to do the same. This also means, technically, that I could have non-player characters climbing up and down ladders. I don't know if I really want to try and take advantage of that.

Speaking of non-player characters (and monsters) - I've now added some "stand-in" versions of monsters that are visible prior to combat. They don't necessarily represent the exact types or quantities of enemies that you'll encounter. It's more of an abstract representation. Abstract works well in 2D, but people have a tough time with it in 3D. I'm worried that players will have problems with seeing a single goblin prior to combat, and then fight a half-dozen of them a few second later. I think it is preferable to having encounters appear out of nowhere (which will still happen, in the case of surprise encounters or ambushes).

Personally - the transition wasn't as bad as I feared it would be, and I think that while it may be a little jarring initially, it's easy to get used to.

But we shall see.

Labels: Frayed Knights, Game Design, Roleplaying Games

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

 
Frayed Knights - Ding!
This week, in discussing Frayed Knights, I decided I'd find one of the most boring parts of the game and make a YouTube video of it. Since I'm really a YouTube n00b and didn't know what I was doing anyway, I thought I might not embarrass myself too much. Well, more than I usually do.

I attended the standing-room only session at GDC one year when Michael Abrash spoke about the development of Quake. While some of the technical details of what they had to do don't have too much relevance with today's technology, the talk had a number of anecdotes that still hold up. He said that he and John Carmack tried a number of different rendering methodologies over the course of a year before arriving at one which - surprisingly - brought them full-circle back to the BSP trees Carmack had used for Doom. After going through about eight different flawed rendering engines before getting it right, Carmack remarked to Abrash that if they'd known exactly what they were making before they started, the engine would have taken less than two months to write.

That's how I'm feeling with some aspects of Frayed Knights. Like character progression.

Character progression is a critical feature of an RPG, so it's important to get it right. Maybe not all-important - we've put up with horrible old-school D&D style leveling up for years, but it still works. And I have enjoyed games with worse. Far worse. It's much more challenging in a massively multiplayer environment, with players competing with each other, but you still want to get it right.

My own system has undergone a significant overhaul since I first started committing parts of the design document to code. The sad truth of it is that my quick-and-dirty hacks are probably superior to the painstakingly devised original system. And what I have now could probably use some more simplification. But the end result is that my whole leveling up system - which was incomplete and disabled for the pilot episode - has had to be completely re-designed and re-written. Sometimes on-the-fly.

What we've got now is surprisingly simple, and should probably be made simpler still (check back in three months when I talk about how I've changed it all AGAIN). Now, characters "level up" immediately when they receive enough experience points, receiving the bonuses to their health, endurance, and pretty much an automatic +1 to everything they do (since everything is level-based now).

But they also get a character point which they can spend at their leisure. (I may end up making this more than one, but I keep waffling on this one - which probably means it is not a good idea).

A character point can be used to increase a single attribute (Might, Brains, Reflexes, etc.) by one point - which generally means an extra bonus to any check that uses that attribute.

It can also be used to buy a feat. Feats are either significantly better enhancements to existing abilities across a narrower range of checks (for example, a bigger bonus to attacks and damage with a specific class of weaponry, reduced endurance cost for spellcasting, or reduced time cost to repeat the same spell multiple times in a "spell volley"), or give you new actions or re-actions in combat. Or - let the character cast spells, though they aren't of the caster class.

So here's my first YouTube video of the whole thrilling process. I've got Dirk leveling up with 4 character points here, though there's a bug (now fixed) since I made the video that still shows him at level 3. As you can see in the video, there are tool-tips, and all point-spending is reversible until you hit the commit button. That may be an overkill if you are generally only spending one point at a time, but hopefully it's worth the inconvenience of a confirmation button-press.



One of the issues I've been dealing with is that a single feat that allows spellcasting is pretty dang powerful as compared to one that gives you extra success with a spear. So I may have to break that one up a bit into... uh, "basic," "intermediate," "advanced," and "epic" spellcasting abilities for each field of magic (each higher-level one dependent upon the lower-level one as a prerequisite, naturally).

Speaking of spellcasting, I'm getting rid of "fizzles" entirely. This will no doubt please --- um, EVERY playtester. There are just too many other ways a spell can fail (like, not hitting the target, getting countered, etc). Instead, a botched casting roll will cost more endurance - you have to push that much harder to activate the spell.

I'm resigning myself to the realization that I'm not gonna have the entire first act playable by the end of the month. I'll call it a victory if the Western Wilderness is fully playable and the Caverns of Anarchy are at least accessible.

Labels: Frayed Knights, Game Design

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

 
Frayed Knights: Serena, Switches, and the Little Green Book
In today's installment of the development updates on Frayed Knights, the obnoxiously tongue-in-cheek indie RPG in development here at Rampant Games (which basically means: "my basement"), I want to talk about Serena, switches, a little about world building, and the "Adventurer's Journal." Wow. Bored already are you? This game development stuff isn't as exciting as it sounds, sometimes.

Serena
First off, meet Serena. She is the final member of the Heroes of Bastionne. She is the party rogue. She is everything a rogue is supposed to be - silent, deadly, sneaky, and discreet. Everything that Dirk is not. Nobody - even her own adventuring group - knows much about her. She doesn't talk about her past. Serena doesn't talk much at all.

She seems to have an active animosity towards per Dirk. Maybe it's the whole pirate / ninja warfare thing. She's definitely on the ninja side of the fence, and Dirk is clearly on the flamboyant pirate side. But Dirk claims ignorance in knowing why she seems to harbor such a grudge against him.

Serena is a highly competent. While she is something of a mystery to her own fellow party members, they've learned to rely on her. She's quietly saved their bacon many times in the past.

And now you've been introduced to the rivals of the Frayed Knights. And now you know who stole the eyes in the pilot...

Switches
Switch-based puzzles are among the most uninventive, unimaginative, and potentially boring elements a designer can throw into an RPG.

Now I've got 'em in Frayed Knights.

I'm going to hell.

My excuse is that they are just too friggin' convenient and reusable. I mean, they are big and obvious (technically, I had a hidden text-only switch that opened a gate in the Temple of Pokmor Xang, but I won't count it here). What adventurer can resist pulling a big lever like that? You do it, and something happens.

Maybe they aren't inherently evil (he says, travelling the well-paved path of good intentions). They are just tools that have been poorly used. But then, I'm using them to open a freakin' magically-powered gate, which is - again - pretty uninspired. At least it doesn't make you guess the right combination or anything truly obnoxious like that.

I'll try and do better in the future. I promise...

The Adventurer's Journal
After chatting with folks in the forums a bit, I decided to go with 'simple', with the ability to add your own topics and notes to the journal. It's not exactly a "quest journal," as not everything in it is related specifically to a quest - just a topic. All notes in the journal under a topic are listed in the order in which they were received - including ones you add yourself.

Basic development is done, but there are a few loose ends (and a lot of stand-in buttons that look like crap). And I don't yet have the ability to save or load data, or to filter "resolved" topics from the list. But it's functional.

The first page is a table of contents, with a list of topics. You can select and jump to a particular topic, or you can simply flip through the topics page by page. Topics and the notes will be filled out automatically as you play, discover things, and talk with people. But you can add your own notes under any topic, and even create your own topics for keeping your own notes.

World Building
The eastern wilderness and the caverns of anarchy are coming along. My goal is to pack the world with interesting stuff to do or see (and have snarky conversations about) every few steps. It's not a small world, so that's a tall order. Even so, I'm finding there are times I really need to shrink down the explorable area. Even if I manage to cram something into every single 100' square block of terrain, eventually the player is going to resolve it all and will be left with walking along territory that has already been "cleaned out."

So I'm finding myself creating more tightly-packed environments than I originally intended - which in turn, in 3D, drives the frame rate up, because so much is on-screen at once. The next solution is to increase the player walking speed so they can cross the entire visible distance in seconds (which plays horribly), shrink the visible distance via denser fogging (which looks horrible), or to break up the environments into smaller, more bite-sized "chunks" (which involves more time spent "zoning" between environments, which is horribly tedious). Or a horrible combination of all of the above.

Decisions, decisions.

Labels: Frayed Knights, Game Design

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

 
Frayed Knights: Doors at 2 AM
This isn't much of an update so much as a development diary sorta thing talking to myself about developing Frayed Knights. Any value in this post whatsoever to anybody is purely conicidental.

I know how bad my posts get when I write them very late at night (like 2 AM or later). So I should probably be terrified of what my code 'n stuff is looking like when I am working on the game that late. Especially when I catch myself nodding off in the middle of development.

That's a pretty clear sign that I'm wasting time and effort. But I had some goals set for myself that I really wanted to achieve - even if, in the end, I only hit the abbreviated version of the list.

It can be astonishing to me just how much time gets consumed - even when I'm wide awake - doing something simple like placing doors in doorways. The allure of a tile-based engine becomes pretty clear as I'm tweaking the size, the angle, and the position of the collision volume (which, in this engine and the way I'm handling things, has to be a completely separate entity from the door). I find myself spending something like 8 minutes per door.

On a freakin' DOOR. Yeah, something that in a tile-based system would amount to, "which of the eight door styles do I choose." A 30-second job. And this is just for doors that aren't locked or trapped or blocked off...

How many of these doors am I gonna need in my game? Ye gods.... There are some things I can do to improve things, like making sure doorways are a more standard size. Uh, and always making doorways axis-aligned (nope, that ain't gonna happen). If I was reusing a lot of geometry, I could make some kind of a "hinge" entity on the interior objects that could be pulled out and used for door positioning information (or even automatically spawn the doors). But without significant reuse of interior sections, I don't see that saving much time.

But barring any breakthrough, putting in 20 generic, unadorned, pre-created doors into a location is gonna take me something like 3 hours. Much more as I add traps 'n locks 'n stuff.

Horrible? No. But the part of me that used to create modules for Neverwinter Nights and Forgotten Realms Unlimited Adventures back in the day is gritting his teeth.

Unfortunately, this sorta thing is about 90% of game development.

It ain't sexy; it ain't all that fun; it's a lot of butt-in-chair work that just needs to get done.

Labels: Frayed Knights

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

 
Frayed Knights: Edgar the Enchanter and the Endless Interlocutions
It's once again time for me to check in with the latest in development musings about Frayed Knights, the upcoming comedic indie RPG being made here at Rampant Games.

Meet Edgar

Here's the concept art for Edgar. Edgar is a magic user in the Heroes of Bastionne, rivals of the Frayed Knights. In keeping with the theme, Edgar is in many ways Chloe's equal and opposite. He's clear-headed, tactical, subtle, conservative, restrained, fabulously well-educated in the art and lore of magic but pretty badly lacking in terms of street smarts and field knowledge. He has an inflated opinion of his own skills, and how cool he looks in that blue robe. If Edgar was a player character in a dice-and-paper RPG, he'd be the guy run by a somewhat uncreative rules lawyer / power gamer.

Edgar is fun. He's just asking to be abused. I wish he had a bigger role in the game than he does, but it's still a secondary role primarily in the second act ("act" works better than "chapter" for my brain for some reason). But he's got some amusing dialogs.

Dying on Dialogs

Speaking of dialogs - Argh!!!!

Anybody who has ever made a significant module in Neverwinter Nights understands some of the challenge of creating a dialog. Let's take a simple case - an NPC whose sole purpose in life is to give the player a quest. I don't feel like making a flowchart, so here's kind of a bad pseudocodeish example of how their dialogs might fire:

[code]
IF (Is this the first time the NPC has met the PCs?)

Dialog 1: "Hi. I'm NPC X. Good to meet you. Oh, I've got this quest. Interested?"

* IF (The player accepts)

* * Dialog 2: "Awesome. Here are the quest details. See me when you are done."

* ELSE

* * Dialog 3: "Fine. I'll wait for some REAL adventurers to offer them this quest."

ELSE IF (the player refused the quest?)

* Re-offer the quest. Repeat dialog 2 or 3 based on player response.

ELSE IF (The player accepted the quest but hasn't made progress yet?)

* Dialog 4: "Good luck on your quest. And here's a reminder of how to get started, since you probably forgot"

ELSE IF (The player start the quest but hasn't finished yet?)

* Dialog 5: "Wow. I'm glad to hear you are progressing. Here's a hint to help you finish."

ELSE IF (The player finish the quest and hasn't talked to the NPC since doing so?)

* Dialog 6: "Ah, cool! You finished the quest. Here's your reward."

ELSE

* Dialog 7: "Hello again. I've got nothing more to say to you. Toodles!"

[/code]

So - seven dialogs to accomplish relatively little. Now, since this is Frayed Knights, I don't just leave it at a single sentence or two that the NPC speaks - I (usually) expand it into a two-way dialog between the NPC and the various party members. And I try to inject some lame humor where I can. This comes out to a surprisingly significant amount of writing.

BUT ... it gets worse. Far worse. Oh, so much worse.

Are You Talkin' To Me?

The above only handles a very simple case for an NPC that has only one purpose in the game. And that's currently how NPCs are behaving in-game. But that's inadequate. I'd like characters in the game to project at least a slightly deeper illusion of life than simply being a person-shaped quest dispenser.

But what happens if an NPC is part of another quest, and has some key dialog to say if the player happens to be on THAT quest. Oh, our IF / THEN / ELSE logic gets a lot more confusing doesn't it? What if the NPC has a minor role in two other quests, AND has a follow-up quest to offer after the first one? What if the player has somehow angered their NPC (perhaps by "failing" a quest), and we need multiple dialogs to deal with a honked-off and non-honked-off character?

And what if they are also a merchant?

Whatever the case, the relatively simple logic of the example falls apart pretty quickly when you end up with more complex states. That means (to me) setting up a queueing and prioritization system for NPC dialog - queueing up all the dialogs that apply to the current player / game / NPC state, and then dropping all low-priority dialogs unless they are the only dialog in the queue. (And if this made any sense to you at all, you are probably a more l33t programmer than I am, and you are also able to translate from Coyote-ese, which makes you a very dangerous person).

It also means tons more writing, much of which the player will never see on a single play-through. Considering the quality of my writing, you can probably count that as a blessing.

Labels: Frayed Knights, programming, Roleplaying Games

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

 
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