Frayed Knights Dev Diary: The Frayed Knights Get A Makeover
Did you ever wonder what a pus golem should look like? Shawn Boyles is the man to give form to the vision. He whipped out some concept art this last week that - as usual - blew me away. The man is talented. To the right is the very first monster to be encountered in Frayed Knights.

This is not to be confused with a "snot golem," which bears more of a greenish tinge. They are also generally more robust, though they become hard and brittle in drier climates. But I digress...

Faces
There's a bit more concept art that I'll share over the next couple of weeks. Shawn has also been working on facial expressions for each of the four main player characters. Whenever they get involved in static dialogs, things can get kind of ... intense. So their facial expressions will reflect - to some degree - what's going on in the dialog.

In addition to that, we got a bit of a coloring makeover going on, as you can see with the revised version of Dirk, here. I guess that's what he looks like in the hands of someone who actually knows how to do things like "shading" and "texturing" and "painting without numbers" and stuff.

The Fountain
As for my own lazy self, I continued working on Interactive Objects. Specifically, the fountain mentioned in the Five Minute Walk-Through. In retrospect, if I'd known what I was getting into, I'd have allocated more than a week to trying to get such a complex, data-driven, scripted game element done. Then again, if I knew what I was doing, I wouldn't have even attempted this project in the first place, so I should be used to it.

The fountain is really just a test case for the generic "Interactive Object" object class. These constructs were kinda-sorta modeled after the conversation dialogs in games like Neverwinter Nights. An Interactive Object consists (mainly) of flags, pages, and options. Options consist of conditionals, descriptions, and results. Conditionals are any kind of test to determine whether or not the option is available. Results are likewise large and varies --- any sort of game effect that takes place, including things like triggering static dialogs, damaging a character, changing flags, or causing a spell to go off. Pages consist of the text description at the top of the dialog, and a collection of options available.

It all combines to form a somewhat less exotic menu screen like the one you see to the right.

Step 1: Logic
My first step (not quite done by the time I wrote the dev diary last week) was to hard-code all the values for a sample interactive object (specifically, the fountain), and then to write the code to handle all the logic when the player pushes the buttons. Right now, certain things still don't work, because there are parts of the game that these should affect that aren't in yet (like inventory).

Here's a sample of the hard-coded interactive object script code (with the formatting all screwed up):

// ------------------ OPTION 0: Try to discover the depth ----------------------------------
$InteractiveObjectScript::Option[0].numConditions = 1;
$InteractiveObjectScript::Option[0].condition[0] = new ScriptObject() {
type = 0; // Check local flag
comparison = 0; // equal
param1 = 0; // flag 0
param2 = 0; // comparison value
};

$InteractiveObjectScript::Option[0].text = "Try to discover the depth of the fountain";
$InteractiveObjectScript::Option[0].numResults = 2;
$InteractiveObjectScript::Option[0].results[0] = new ScriptObject() {
type = 7;
param1 = "The party members take turns sticking various items in their inventory into the fountain (except Chloe, who stubbornly refuses to let anything in her possession touch the \"icky water\". Eventually they determine that the water is at least eight feet deep, but they are unable to establish exactly how deep it is.";
};
// Set flag 0
$InteractiveObjectScript::Option[0].results[1] = new ScriptObject() {
type = 8;
param1 = 0;
param2 = 1;
};

Yuck. And that's not even the code that runs the logic, decides what pages and options to display, and processes the results when the player hits a button. But it gave me a starting point, and I kept hammering on the game logic until the whole thing worked. And after much butt-in-chair work, it did. Even to the point of launching static dialogs or pop-up story windows. Fun stuff.

Step 2: Text Files
Since I want more things in the world than fountains, I needed a more data-driven way of handling interactive objects. I didn't relish the opportunity to create a hundred of these files all hard-coded in TorqueScript. Instead, I created a text file to be parsed into the game at the appropriate time.

The same thing above, in the text file format, looks like this:

;------- OPTION 1: Depth Check ----------
[Option 1]
[text]Try to discover the depth of the fountain
[numResults] 2
[numConditions]1
[condition 1]
[type] 0
[comparison] 0
[param 1]0
[param 2]0
[result 1]
[type]7
[param 1]The party members take turns sticking various items in their inventory into the fountain (except Chloe, who stubbornly refuses to let anything in her possession touch the "icky water". Eventually they determine that the water is at least eight feet deep, but they are unable to establish exactly how deep it is.
[result 2]
[type] 8
[param 1] 0
[param 2] 1

So it is a little easier to read (and, more importantly, maintain). Of course, now I needed to write some code to read this file in and parse it. So I hammered away on more code, not stopping until tonight, when the functionality of the parsed-file version of the fountain matched that of the hard-coded version exactly.

Step 3: A Tool To Make Life Easier?
The natural third step would be to create a tool that would allow me to create these data files automatically, doing all the error checking for me. I'm all for it. But I don't have time right now. I see a C# program (since I need more practice with C#) with all kinds of cool UI widgets to choose comparison operators and result types. This would eliminate more human error from the process of scripting interactive objects.

It'd be cool. But not for this week.

And moving forward....
So what's up this week? Getting the character sheet fully operational (sans inventory and leveling up)! This oughta be a piece of cake after I've simplified the whole rules system, right? And if I have more time... doors!


(Vaguely) related fraying:
* Frayed Knights: First Five Minutes Walkthrough
* Rules of Game Design, Part 1
* Frayed Knights: Design Doc Fun!

Forum discussion at this link!

Labels: Frayed Knights, Roleplaying Games

- posted by The Rampant Coyote @ 2:15 AM (Permalink)