I thought I’d write a bit about our newfangled Conversation Engine, how it came about, how it works, what it’s capable of and where it’s going.

The system was born out of necessity. Well… I say necessity, we could very easily make the game in AGS alone. It just wouldn’t be exactly the way we want it (and we’re awfully stubborn like that). What I really mean is it was born out us wanting to do certain things that were either not possible with AGS scripting, or requiring quite a clart on to get going in AGS.

First off, the gesture system. In AGS you have things called “views”, which are your loops of animation for four (or eight) facing directions for characters. In AGS you can assign a specific view to a character for their talking animation, meaning it will play the loop associated with the direction they are currently facing.

This did not suffice for what we wanted to do. We wanted the characters to emote, in appropriate places, to the dialogue. We wanted them to react with shock when someone makes a startling revelation, to cross their arms when they feel threatened, or put their hands on their hips when feeling defiant. We wanted them to turn their heads to face the character they are speaking to. To do all this requires transition frames. It would also need not one talking animation, but one for each possible pose, for each possible character. This is something that AGS does not natively support, so we went about writing our own system.

Now we have this XML driven system that allows us to define “poses” for different characters. These poses detail their idle animation, as well as the transition in and out from a standard root pose. As well as this each pose defines the talking animation in that pose, i.e. the mouth opening and closing, or possibly a more involved animation.

This means instead of saying:

“do talking animation 1”
“say this”
“do talking animation 2”
“say that”

We can now say:

“cross your arms”
“say this”
“put hands on hips”
“say that”
“point aggressively”
“say something threatening”

The system will blend in and out of each pose automatically, making the changes in poses smoother, nicer and with no big jumps.

Also we have things called “gestures”, which are different single actions they can carry out when in a specific pose. For example Mia, in her normal pose, can brush her hair back, before reverting back to her original pose and carrying on. We’ve got a fair few poses and gestures for all principal characters already, and we’re hoping throughout the course of the three acts we will end up with quite a lot. Hopefully this will help to add more emotion to the dialogue text. As way of example, Dr. Carter acquired a lot of his character from a single pose that he was given a while after he was first drawn.

Once all this was in place, we set about developing our own flowchart style conversation engine, firstly to get by some limitations with the AGS conversation scripting (which seems like older legacy stuff done before full AGS script was added). We have a bunch of nodes defined in an XML file, each one in turn is processed, but any are able to reroute to any other node in the conversation file. This allows us to have different paths depending on conversation choices, or ultimately conditions such as “is the player stood here?”, or “has this bit of story exposition been revealed yet?” We added different kinds of action nodes, allowing us to tell characters to walk from A to B, say things, change poses, perform gestures, and attach objects together and all manner of other things (ultimately we’ve also added the overlay stuff mentioned in previous parts of this diary).

We’ve now realised what we have is not so much a conversation engine but also a cutscene engine, and it has now been used on pretty much every complex series of actions in our game demo.

As a happy side-effect of this system, it means that our good friend Nikolas is able to implant the music directly into any point of the game he chooses! Without a copy of AGS, he is able to direct the music himself by adding nodes straight into to the XML files. This music can be synchronized with game events–for example, changing the music to being more sinister as soon as Clancy enters the room.

Since this, we’ve started moving our focus from our implementation of the aMuse system in Forgotten Element from being used exclusively, to being used only where appropriate. We think Nikolas will bring much more to the game if he’s free to work like this, and to be honest we want Nikolas’ awesome music, unbridled and free to do what he wants, much more than we want to showcase aMuse, though we will still be releasing it once it’s done, it may be lower priority than originally thought. Another problem with using aMuse is that Nikolas owns a shitload of really expensive sample libraries, being a professional musician and all, which due to the nature of aMuse we would not be allowed to use without violating copyright. This means we would suffer a hit on music quality right off the bat having to use freely distributable sample libraries for aMuse to use… that said Nikolas has had some interesting ideas how we could add more interactive elements to the music and still retain the non-looped grandeur of his stuff. Huzzah!

Go Nikolas!

(Isn’t he lovely?)

Popularity: 4% [?]

This entry was posted on Tuesday, August 8th, 2006 at 5:33 am and is filed under forgotten element, ags, games, indie. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.