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)