Blog for Rubes at GarageGames.com

Vespers3D: Turn-Based or Real-Time?

Rubes — 2008-07-29T03:58:44+00:00

Not long ago I started a separate blog of my own over at The Monk's Brew, which covers adventure games, indie game development, and the journey of creating Vespers3D. I'll try to cross-post when I can; here's a recent entry I thought some here would appreciate.

Vespers3D: You Got Turn-Based Chocolate In My Real-Time Peanut Butter

The whole idea behind this Vespers project thingy is to take a rich textual world created in interactive fiction and extrude it, so to speak, into three visual dimensions. As I've discovered, a whole mess of issues arise when moving from the predominantly discrete world of IF to the largely continuous world of 3D. That applies, of course, to space: in IF, space is divided into discrete locations, with little to no functional representation of spacial relationships within those locations, while in 3D, space is represented on a more familiar continuous scale. Likewise, it applies to time: rare exceptions aside, IF is turn-based with discrete time steps, while first-person 3D games are real-time and continuous.

The question is, can a game really be both at the same time?

In terms of space, that's not really a difficult stretch. Most locations in IF are just discrete representations of a location in 3D; a kitchen, a bedroom, a church can all be defined by walls and doorways in 3D to produce the same effect as in IF. Outdoor or more abstract locations can be a little trickier, but through the use of invisible, arbitrary borders one can functionally define locations such as "outside the calefactory", "base of the bell tower", or "garden", to produce the same effect. Dealing with spatial relationships within locations has its implementation challenges, but nothing that can't be addressed by a few ground rules that can be tweaked based on playtesting and feedback.

Time, however, is a bit less straightforward.

The turn-based nature of IF is something that is tightly integrated into game design and gameplay mechanics. It's probably fair to say that this is, at least in part, a reflection of the history of the genre, going to back to the command-line interface and early computational limitations. It's also probably related to the nature of the medium and interface; reading and typing text, and thinking through sometimes complex puzzles, is better suited to a more relaxed, turn-based interface. It creates a challenge for authors trying to model time-limited situations in their IF games, with the typical solution being a turn counter and forcing the player to resolve an issue within X number of turns. This can work to create a sense of urgency in players, although in some cases it can come across as an artificial limitation.

Some authors have tried using IF systems that operate in real-time; although I don't recall trying any of these myself, my sense is that the scarcity of these games is a reflection of the popularity of this approach.

Which leads, I guess, to the next question: if that's the case, why try to do something like that with Vespers?

The answer is that I'm not. Instead of being truly turn-based or truly real-time, Vespers will actually be something of a hybrid, although in practice it will play closer to a turn-based game. The player can move in real-time, but for the most part it will resemble moving about within a world where time is essentially in an idle loop, advancing predominantly (but not entirely) upon player input. That input could be the entry of a command (like in traditional IF), or it could be the result of movement (such as entry into a new location).

As an example, take the interaction with NPCs. When the player first encounters Lucca, for instance, he is on the floor in Matteo's room, scratching at a flagstone in the floor. If the player does not interact with Lucca, he will just continue to do what he is doing, maintaining his "idle" state of scratching at the stone. We've created a series of animations for Lucca during these "idle" times -- scratching at the floor, sitting up to rub his sore hands, wiping the tears in his eyes, and so on. These animations play at random intervals to give the appearance of a living, active character, even though he is essentially just waiting for either (a) the player to interact with him, or (b) some other game event to trigger his next action or task. If the player does interact with him, once the interaction is finished he simply goes back to doing what he was doing, scratching at the floor.

The result is a game world that is predominantly reactive, but it remains to be seen if this comes across as a little too passive. Note, however, that the world won't be 100% reactive in this sense; there are still some situations where we cannot always wait for the player before advancing time.

The most obvious example of this is an action sequence; in Vespers, for instance, there is the tense scene with the wolves in the garden. In the IF game, the player is given a handful of turns to work out a solution to the mess -- but how to implement this in pseudo-real-time? Forcing players to think and type fast would not be an ideal solution. Instead, the solution will be to implement a surrogate for the "turn". The surrogate will take into account all possible actions (and inactions) of the player, including the typing of commands and any movement.

There are a couple of tricky situations with this approach. For instance, with respect to player movement, how much movement should represent a "turn"? Then there is the command line entry window: should the advancement of time be suspended while waiting for the player to finish typing? Should a time limit be placed on text entry? Or should text entry be cancelled if no keys are pressed after a certain period of time? Finally, there is the issue of player inaction, and whether time should advance or loop continuously while the player sits idle.

These are all issues that need to be worked out through playtesting and then tweaked as needed. In the end, however, the result will be a game that has elements of both turn-based and real-time gameplay, although functionally it will probably be closer to the former than the latter.

The most interesting part of the experiment will be to see which parts of the system work and which do not, and then using that information to refine the mechanics once we move beyond Vespers and on to the next project.

Vespers3D: Being Indie, Being Resourceful

Rubes — 2008-06-04T20:35:42+00:00

I recently started a separate blog of my own over at The Monk's Brew, which covers adventure games, indie game development, and the journey of creating Vespers3D. I'll try to cross-post when I can; here's a recent entry I thought some here would appreciate.

Vespers3D: Being Indie, Being Resourceful

Being indie can definitely be tough sometimes. I've often said that indie game projects are kind of like fish eggs: thousands are laid but few manage to survive to adulthood. Content for a 2D or 3D game, whether it's artwork, music, voicework, or animation, can be a real problem for a small team on a shoestring budget. It's no secret that content, specifically character animation, has been the biggest challenge for Vespers.

Sometimes, it takes a little creative thinking to figure out ways to stretch those limited resources.

A while back, when I was looking for help with voiceover work, one idea I had was to try tapping into some good but inexpensive local talent: theater students at the University of Utah, where I work. The casting call I posted ended up being picked up by a local talent company, which brought in a lot of additional talent, but the end result was exactly what I needed: great people with great voices who enjoyed working on a fun project for what essentially amounted to peanuts.

Animation, however, is a different beast that requires a bit more of a commitment, so I was never very keen on trying a similar approach. Nevertheless, recently I learned that the University of Utah also has a new interdisciplinary program for undergraduates called Entertainment Arts & Engineering, which is a joint program between the School of Computing and the College of Fine Arts. It's basically a curriculum to prepare students for careers in the digital media and entertainment industry, specifically for videogames, digital animation, and computer-generated special effects. How enticing.

So I contacted one of the program directors and told him about Vespers, to see if it might be possible to work something out with a few of the animation students who might be looking for some experience and a chance to showcase their talent. He circulated it among the faculty, and before long I had an informal face-to-face with one of the teaching faculty who specializes in graphics and animation, and has worked in the computer graphics industry since 1985.

The meeting went very well. He seemed to like the idea behind Vespers, and thought it would be a good opportunity for some of his students, many of whom he thinks would really appreciate the chance to work on something like this.

What I found just amazingly generous is that he essentially volunteered to be something of a faculty representative for the students, and take on the tasks of finding interested students, teaching them the pipeline, providing help when needed, and holding them to the task. It's difficult to overstate the value of someone in this position; having a person that knows all the details about the animation, exporting, and file preparation process, and who also knows the students and is in a position to manage and organize them, is worth more than I can imagine. I'm still just astonished that he is willing to take on this effort.

It will still be some time before things get rolling, though. The biggest issue is that we've done all of our models and animations to this point in 3DS Max, and he and the students basically work only in Maya. So first there is the issue of converting our character models to Maya format, which is not nearly as simple as it should be. Then there's the task of getting him familiar with creating and exporting animations from Maya to files that work with the Torque Game Engine, which is a quirky process that anyone familiar with TGE will tell you requires some time to learn. Once we reach that point, he can then be in a position to get the students up to speed, and so far there are at least a handful who have expressed interest in working on the project.

I'm really excited about the arrangement, and if things work out it could be the real boost this project needs. I'd also like to think that it could lead to other projects down the line, since it seems to fill a need on both ends. We'll see how it goes.

For those of you who stuck around to the end...look! Shiny pictures!

Vespers3D: Adventures with NPCs, Part IV

Rubes — 2008-03-19T04:50:22+00:00

Vespers3D: Adventures with NPCs, Part IV

Recap:
Vespers3D is our attempt to bring old-school text-based adventure games (interactive fiction) into the world of real-time first-
person 3D -- a new genre we are calling 3D/if (3D interactive fiction). It is based on Vespers, Jason Devlin's excellent text IF
game that won numerous awards from the IF community, including Best Game at the IFComp'05 and the 2006 XYZZY awards.

Once again it's time to resume my efforts to bring our NPCs to life, beginning with bits and pieces of text from the IF version of Vespers and ending with a modeled, animated, and voice-acted 3D character. It's been a while since my last entry, which described Lucca, the young monk who recently joined the order at St. Cuthbert. This time I discuss the development of Ignatius, perhaps the most mysterious of the brothers at the monastery, and the one who is most distrusting of the Abbot at the start of the game.

Ignatius: From Concept to Character

Each of the characters in the game has their own challenges, and Ignatius is no exception. In addition to his bad eye, Ignatius has to have a particularly suspicious appearance, which can sometimes be difficult to model in a convincing way. Again, we didn't have a lot to go on initially from the text version of Vespers, aside from a short description:

"A fiery man, whose devotion to God is rivalled only by his devotion to protecting God's people,
Brother Ignatius was a soldier before joining Saint Cuthbert's. After losing an eye against the
Turks in Nicaea, he came back to Italy, and started fighting for God in the only way he could
now: with prayer."

Aside from a middle-aged, slender built man of above-average height, Jason Devlin (the game's author) and I didn't have a lot to give N.R. Bharathae, our lead artist, to go by. Nevertheless, N.R. did a great job capturing his appearance with his initial concept:

Figure 1. Ignatius concept sketch.

This looked like a perfect starting point. Using this, N.R. designed Ignatius's 3D model and then applied some of his amazing textures -- where he gets these from, I have no idea. As with the others, we were going for a more realistic appearance for our characters, and I think N.R. really outdid himself this time:

Figure 2. Ignatius textures.

Figure 3. The Ignatius model.

As with the other characters, while N.R. modeled we continued in our task of finding and recording a voice actor for the part. Matching a voice for a middle-aged man would not be as difficult as for some other parts, but the real challenge was finding someone who could play the part convincingly, given that Ignatius needs to be portrayed as dark and suspicious. The man we found to play the part was Bob Richardson.

Here's a shot of Bob alongside his character, as well as a short bio and a shot I took during his recording session:

Figure 4. Bob and Ignatius.

"Bob Richardson is the father of three gallant sons, one princess daughter, and two wonderful step-daughters. He has been involved in acting for about 40 years, although not in anything you've probably ever seen before. Starting in the theater at age 11 and moving to film and video productions about 10 years ago (mostly local projects), he studied Theater and Cinematic Arts at BYU for a while and now continues to dabble in entertainment as time and schedule permit. He has developed a wide variety of vocal talents; being able to speak with a variety of dialects, accents, and caricatures (He does an amazing Yoda). He has sung bass in a number of choirs and small ensembles. Bob's primary occupation is in financial services, but he also does some contract technical support on the side. His hobbies include riding his Honda Goldwing, SCUBA diving, and playing a few FRP computer games." -- B.R.

Figure 5. Bob recording the lines for Ignatius.

Ignatius also marked the debut of two new animators, James Allan and Marc Schwegler. Both of these guys generously offered their help after seeing my last blog, when I was lamenting the loss of yet another animator. Thankfully, both James and Marc are Torque pros, so we didn't have to go through the painful process of reviewing the entire exporting process, and we've been able to make some good progress on the character animations.

There was nothing particularly new for us about the process of animating Ignatius, since by this time we had covered most of the approaches with the previous characters. When the game begins, Ignatius is sitting in the church, staring intently at the candles and praying, so much so that the player surprises him when he speaks. In the text game, Jason had Ignatius sitting in the pews; later, we realized that pews didn't exist until much later in history, and we switched instead to choir stalls.

Here is a short portion taken from the beginning of the text version of Vespers, with the player's commands in bold caps:

Church (in the pews)
Cedar pews line the path from the chancel in the north to the cloister to the south, their
surfaces cold. The ceiling towers above you, its frescoes dim in the candlelight.

The Saints smile cheerfully down upon you from their colorful windows.

The font glows warmly in the candlelight, not a ripple on its water's surface.

Brother Ignatius sits in one of the pews near the front, staring intently at the candles.

>EXAMINE IGNATIUS
The scar through his left eye having left him half-blind, Ignatius makes up for it by staring
twice as hard at the candles with his good eye. The eye refuses to blink.

>TALK TO IGNATIUS
"How are you, Ignatius?" you ask, laying your hand on his shoulder. 

He startles, whirling around, his bad eye twitching and shuddering. "Oh, father. You spooked
me." He shakes his head. "I'm sorry, what did you ask."

>AGAIN
"I was just wondering how you were doing." 

"Oh, fine." He relaxes, turning back to the candles. "Just fine."

>AGAIN
"Shhh, father." He holds a finger to his lips. "I am trying to pray."

We thought to have Ignatius idle using a cyclic sequence, showing him very subtly rocking back and forth as he prayed, with a very slight movement of the fingers of one hand rubbing together. We also wanted to implement his eye twitch as a separate animation sequence, one we could call at random intervals separate from other currently playing sequences.

With the arrival of our two new animators, we also went about making some changes in the way we designed the characters. We went back to a biped skeleton for greater compatibility and simplicity, for one. In addition, James wanted to take our animations a step further by including more realistic lip sync, so Ignatius also marks the debut of this feature. At first I was a little hesitant to include this much detail in our characters, but James convinced me that it would be worth it for a game like this. Plus, with some of the software he uses to generate the lip sync animations, it actually turns out to be less work than I had imagined, and the results are really smooth and natural. The process of creating these sequences is really fascinating to me, so more on this in a future blog by James.

Here is the same portion of the game as above, as we developed it in 3D with animation and sound, along with a few other sequences mixed in afterward. Click the image below to see the Google video:

Figure 6. Click image above to see Ignatius in action.

So that's how we went through the process of developing Ignatius from a text character in an interactive fiction game into a 3D animated and speaking NPC model -- a good combination of writing, modeling, texturing, animating, and voice work. That now covers four of the six characters in game -- only two left! Next time, I'll cover the development of Drogo, one of the most difficult characters to capture for a variety of reasons.

Thanks for reading!

Vespers3D: Adventuring Onward

Rubes — 2007-12-29T01:48:59+00:00

Vespers3D: Adventuring Onward

Recap:
Vespers3D is our attempt to bring old-school text adventure games (interactive fiction) into the world of real-time first-person 3D -- a new genre we are calling 3D/if (3D interactive fiction). It is based on Vespers, Jason Devlin's excellent text IF game that won numerous awards from the IF community, including Best Game at the IFComp'05 and the 2006 XYZZY awards.

Despite my notable absence from the GG blogosphere the past few months, development on Vespers continues in typically torrid fashion. Ah, but just when you thought Vespers blogs were ready to pop out at you every few weeks back in late summer, covering the fascinating development of all six NPCs in the game, suddenly Rubes pulls the rug out from under you. Ah well, such is life, as they say.

Or, at least it would seem, such is life with character animators. Fall saw us lose our third animator on the project, abandoned yet again for promises of wealth and fame from more lucrative work elsewhere. So instead of cranking through the animations for each of our NPCs, we're instead back to the drawing board, trying to bring someone new up to speed. I swear, at this pace, I probably should just quit my job, go to animation school, learn the art, and do it all myself.

Someday, we'll pick up the series again with the next piece on Ignatius. In the meantime, here's a snapshot showing how far we got with him before progress came to a halt.

Time (and Development) Marches On

Since we've been down that road before, we knew this would be only a temporary setback, and of course with so much else left to work on we could hardly stop.

I knew I'd be attending my first IGC this year, and I wanted to show off what we had. But that meant we'd have to spend time polishing things up and making it look like, you know, a real product. And that meant annoying little details like main menus, sound, being able to quit on purpose rather than by crashing, and so on and so forth.

Because Vespers was still at an early stage, and I knew there wasn't a lot to actually do in the demo at IGC, I wanted to at least give the game a decent face. So I spent some time working with an excellent musician I found online, Daniel Godsil, to come up with some dramatic pieces to use for the intro/main menu and the in-game ambient track. Daniel ended up modifying a piece he had made for an independent film that never got released, and which fit perfectly with the mood and pace of the game, a piece he had previously called "Soul of a Man." Not bad, really, given that the game is about the battle over the soul of the Abbot, the main character.

I then pieced together an introduction for the game to go with the music, something that would lead into the main menu. Since Vespers is a decidedly cinematic game, I wanted something to match that. Originally I had wanted to do a camera path overlooking the monastery, but then I decided instead to try a different approach, more like an animated slideshow. So I put together a system that utilized multiple camera positions, camera fades (oh, what I'd give for a crossfade), and my fading transparent GuiTextCtrl resource to produce a sequence of different views of the monastery as a way of introducing it.

Not sure why, but if you want you can see a brief snippet from the intro, with some music, here. The picture quality isn't great, to say the least, but you should get the idea.

Of course, if you were at IGC you might have seen it. Then again, after I was there I realized that we didn't have the benefit of sound. Very cool, a boring demo without even any good music to distract people. Yay me!

There was also this pesky issue of crashing. I work primarily on the Mac side, but with no Macs around for demos at IGC, I had to pull out my rarely-used Windows build. Strangely (wait, it's not strange), the Windows build had an exciting tendency to crash spectacularly at random, unpredictable times. I've also discovered that TGE's animation routines differ slightly between Macs and PCs, at least as far as blending is concerned. I'm not sure why that's the case, since there shouldn't be any platform-specific code there, but it's pretty reproducible. Nothing a little hack can't overcome, though.

Ah well. There's always the Utah Indie Game Developers night!

The Bridge Between Heaven and Earth

Our attention next turned to the church. The church is an especially cool part of Vespers. The way it was originally designed in the text game, the church is almost like a living structure, and as the monastery spirals into darkness as the game progresses, the church (unlike other structures in the game) shifts and morphs to reflect this. This includes many of the items inside the church as well, including the main cross, the images on the stained glass windows, the lectern and Bible, the candles, the font and its holy water, and the frescoes painted on the walls.

The game itself takes place over five Acts, and in each subsequent Act each of these objects changes -- either significantly or subtly -- to reflect the growing evil surrounding the monastery. One nice example is the font, with its descriptions from the text game at each stage:

Act I:
"The bronze glows warmly in the candlelight, like it has at many a Mass."
Act II:
"The bronze is dim: hints of green and grey creep from the water and slide
to the base."
Act III:
"The font is cracked and tarnished. Grey-green streaks blossom from the
water and twist their way down."
Act IV:
"Flakes of rust crumble off, but they are replaced by a green mould. The
mould hugs the font, refusing to let go."
Act V:
"The tin pot is glazed with feces and urine. It is more smell than sight."

It's a pretty cool effect during the text game, and it's one I'm looking forward to reproducing. It means we'll probably need multiple models and textures for each of the objects, but it shouldn't be too much trouble. Here's how the font above was designed by our all-star modeler, N.R. Bharathae (we decided to go with a stone font rather than a bronze one):

Here are a couple of other church objects as N.R. has designed them, each with their initial (Act I) description from the text game. I think N.R. did some really fantastic work.

Lectern
"The lectern stands with more strength and confidence than you do
of late, its support of the Bible unwaivering."

Bible
"The Bible stands upon the lectern, its gold filigree glimmering in the
light of your candle."

Wooden cross
"Towering above all else is a massive wooden cross. It was finely wrought
with all the attention it deserved."

Another one of these items in the church is the body of St. Cuthbert, the patron saint of the plague and the namesake of the monastery. His body is displayed in a glass case near the chancel, his body untouched by the years that have passed. One of the interesting things in the game is that you are able to break open the glass case by smashing it, so we had to design (a) separate models, one with an intact case and one with a broken case, and (b) an explosion consisting of glass shards to mimic the shattering of the glass. Then when I create the explosion, I just switch the datablocks on the object from the intact case to the smashed case. The effect, I think, is pretty decent.

Here's N.R.'s model of Cuthbert in the smashed glass case -- another wonderful modeling and texturing job:

St. Cuthbert
"A beautiful glass case holds the body of Saint Cuthbert near the base
of the chancel. He is so calm: so serene. His body is unblemished by
the centuries that have passed. Truly, he is incorruptible. He even
smells divine, as though flowers were growing beneath him.";

Finally, there are the frescoes. That turns out to be a tough one. The main issue is that medieval Italian church frescoes represent a fairly specific style, and we would want our frescoes to be pretty convincing. So this means seeking out someone with considerable artistic experience. But since the frescoes also change as the game progresses, that means we would need an experienced artist to create multiple frescoes from scratch. That means one thing: $$$.

So right now we're in the process of evaluating some artists from all over to see who has the talent to produce these frescoes within our stated budget. I think we'll be able to find the right person, which would be great since the frescoes will really provide a great mood and setting for the game.

Facing Forward

With the church mostly done, we'll turn our attention to the kitchen next, at least until we can get the character animations going again.

One of the first kitchen items we have is the cupboard. It's not easy to know what medieval cupboards are supposed to look like, but N.R. came up with some good images to work from and he created this fantastic piece:

With four independent doors, we had to replicate what we did with our regular doors: create separate door models, each with its own open and close animation, and provide collision with an invisible collision mesh overlying each one, which I manually rotate when the door is animated open or closed. It took a little work to get it all running properly, but the result is a fine cupboard with four doors that open and close with proper collision checking.

Soon we'll tackle the mysterious hatch to the cellar, where surely the answers to the questions at the monastery lie...

Vespers3D: Adventures with NPCs, Part III

Rubes — 2007-09-03T18:46:38+00:00

Vespers3D: Adventures with NPCs, Part III

Recap:
Vespers3D is our attempt to bring old-school text-based adventure games (interactive fiction) into the world of real-time first-person 3D - a new genre we are calling 3D/if (3D interactive fiction). It is based on Vespers, Jason Devlin's fantastic text IF game that won numerous awards from the IF community, including Best Game at the IFComp'05 and the 2006 XYZZY awards. Vespers provides a compelling setting and a storyline for a game that will, in the end, be something akin to Myst but with a fully interactive 3D environment and good old-fashioned text command input and output.

Here we resume our efforts to bring our NPCs to life, beginning with bits and pieces of text from the IF version of Vespers and ending with a modeled, animated, and voice-acted 3D character. Last time I discussed the development of Constantin, the large hulking monk with a short temper. This time I relate the development of Lucca, who had some interesting and unique challenges of his own.

Lucca: From Concept to Character

Lucca was going to be a tough character to convincingly recreate. He's the youngest member of the monastery, a teenager who recently joined the order. He's very attached to Matteo, one of the monastery's father figures, and is generally an emotional character during the course of the game. Again, we didn't have a lot of text to go on initially aside from a short description:

The youngest of those who remain, Lucca joined the monastery only a few short months ago.
The son of a count, he had never seen death before the arrival of the plague. It haunts him.

After some discussion between myself and Jason Devlin (the author), we decided we wanted Lucca to have pale skin (maybe slightly paler than the rest), blue eyes, and delicate facial features; probably quite frail overall with a slight build and thin face. We presented these ideas to N.R. Bharathae, our lead artist, who came up with his concept for Lucca.

Figure 1. Lucca (with Matteo) concept sketch.

This looked like a perfect starting point. Using this, N.R. designed Lucca's 3D model and then applied some of his slick textures. As with the others, we were going for a more realistic appearance for our characters, and N.R. did a really great job with him:

Figure 2. Lucca textures.

Figure 3. The Lucca model.

During this time, we continued in our task of finding and recording a voice actor for the part. Matching a voice for a young man would not be as difficult as for some other parts, but the real challenge was finding someone who could play the part convincingly, given that Lucca expresses a great deal of tearful emotion during the game. Fortunately, we were able to find Christopher LeCluyse.

Christopher is a veteran of the stage, both acting and singing. Not only that, he also has expertise in medieval literature, and was able to help out with some little-known facts and inconsistencies in our story. For instance, Christopher pointed out to us that, during the time period of our game (ca. 1300-1400), pews did not yet exist in churches -- only choir stalls. So we were able to make that adjustment in our storyline and setting.

Figure 4. Christopher and Lucca.

"Christopher LeCluyse (Lucca) brings to Vespers twenty years of professional vocal training and performance and a doctorate in medieval language and literature. He sings regularly with a variety of choral and early music groups and has appeared on recordings with Conspirare. Chris is also a professor of English and writing center director at Westminster College in Salt Lake City." -- C.L.

Finally, there's the work of our animator, Matt Chin. Lucca presented a different kind of challenge than the previous characters, because we wanted to try something a little more complex with the way he idles. At the beginning of the game, Lucca is first seen running into Matteo's room in the dormitory, where he then scrabbles frantically at the ground, trying to unearth one of the stones in the floor:

Matteo's Room
This room is small: the same as all the others. A bed is pushed up
against one wall, opposite the door to the north.

Lucca scrabbles frantically at the ground, his blood staining the
stones.

>EXAMINE GROUND
(the flagstone)
Lucca scrabbles at the stone, trying desperately to unearth it from all
sides.

>TALK TO LUCCA
"Why do you dig, Lucca?" you ask. 

"Matteo is hiding something. I just know it's under here."


>AGAIN
"Why do you think that?" The blood pours from his fingers. 

"I just know," he sobs. "He scrapes around here at night."

>AGAIN
"Leave me alone," he blubbers through the tear-laden mucus that streams
from his nose.

>ASK LUCCA ABOUT MATTEO
"He knows something, but he won't tell me," he sobs more heavily for a
moment. "He tells me nothing anymore."

My thought was to have Lucca idle using a cyclic sequence, showing him repeatedly scraping at the stone in the floor. But playing this sequence over and over again, without any alteration, would quickly get old and not look very professional. My thought was to try and break the monotony by including a few additional idle sequences played at random points during the cyclic sequence -- one trying to pull up the stone, one showing him rubbing his bloody hands, and another showing him wiping the tears from his eyes. That means four idle sequences -- one cyclic and three non-cyclic. All need to be designed using the root position as a launching point for any speech animations called from player interaction:

Figure 5. Modifications to the usual animation flow sequence to accomodate additional idle sequences

What the hell does all that mean? Basically, only that each sequence -- whether it's an idle sequence or speech sequence -- has to start and finish in the root position to maintain consistency. The thing we need to keep in mind is that speech can be triggered during the cyclic idle sequence or during one of the other idle sequences and to account for that. Once a speech animation is finished, we always return to the cyclic idle sequence and start again. It can look a little robotic at times, but overall I think it works well.

Here is the text portion of the game given above, as we developed it in 3D with animation and sound. Click the image below to see the Google video:

Figure 6. Click image above to see Lucca in action.

So that's how we went through the process of developing Lucca from a text character in an interactive fiction game into a 3D animated and speaking NPC model -- a nice combination of writing, modeling, texturing, animating, and voice work. Next time I'll introduce Ignatius, one of the more mysterious and suspicious characters in the game.

Thanks for reading!

Vespers3D: Visibility Issues in 3D

Rubes — 2007-08-06T17:48:31+00:00

Vespers3D: Visibility Challenges

Recap:
Vespers3D is our attempt to bring old-school text-based adventure games (interactive fiction) into the world of real-time first-person 3D - a new genre we are calling 3D/if (3D interactive fiction). It is based on Vespers, Jason Devlin's fantastic text IF game that won numerous awards from the IF community, including Best Game at the IFComp'05 and the 2006 XYZZY awards.

Although I've been focusing on introducing NPCs lately, I'd also like to take a moment to describe one of the big challenges I'm having as I move from a text environment to a graphic environment, and in doing so ask for some suggestions for possible solutions.

In text-based interactive fiction games, worlds are divided into individual, explicit "rooms" or locations. Each location has within it a set of world objects which are able to be referenced by the player. These objects (which also includes whatever items are currently in the player's inventory) are referred to as being "in scope". It's a fairly simple matter to collect a list of all objects that are currently in scope in a text game, and the player can "see" each of these objects unless explicitly designated (e.g., a coin inside a closed box would be considered in scope but not visible or accessible).

In 3D graphics games, of course, we have to deal with three-dimensional space, so we now also have to consider line of sight, among other things. Take, for instance, this example of a screenshot from Vespers3D:

Figure 1. Screenshot demonstrating problems with line-of-sight detection.

In this shot, I have selected the bed in the background to try and "examine" it. The response from the engine is that "You can't find any such thing," even though it's visibly right there. As you might imagine, a ray cast from the player's eye to the bed object first intersects Constantin (either his knife or the hare), so the bed is not considered to be "visible". How to best deal with this situation?

The figure below demonstrates the normal situations with respect to visibility testing, which forms the basis of our visibility checking routines:

Figure 2. The normal visibility detection situations.

However, as in the above screenshot, there are situations where an object is technically visible to the person playing the game, but not to the engine. These are shown below in examples #4 and #5:

Figure 3. Issues with visibility detection in certain situations.

The screenshot from the game is similar to example #4 above; we can also have a situation like #5 if we step just outside the doorway to Constantin's Room. The problem is that it's hard for the engine to know the difference between a situation like #5 and one like #3. As far as I can tell, the engine doesn't necessarily know that the object is rendered in a way that is visible to the person playing the game. There may be ways to know that, but I'm not familiar with them.

But there are other situations as well. Take #6, for example. If the player tried to examine the object in #6, the engine would think that the problem is that it is blocked from view by the other object, not the wall. There needs to be a way to know the difference between situation #4 and situation #6, where the target object is partly visible in one situation but not the other.

But wait, there's more!

Figure 4. More issues with visibility detection.

Example #7 above is similar to example #4, but when the target and blocking objects are in a different room than the player. I had thought to maybe use the target/blocking objects' room (compared with the player's room) as a potential solution, but then you have situations like #7 where that doesn't work.

Finally, you have example #8, where the target object is blocked by a closed door. This situation is very similar to example #4, but here the blocking object is a door (a DTS object, not an interior) which completely obscures the target object from view. How can the engine know the difference between example #4 (where the target is blocked by a DTS but is still visible) and example #8 (where the target is blocked by a DTS but is not visible)?

A call for suggestions

I haven't yet come up with a good solution for this problem, and unfortunately it results in some awkward situations while playing -- players can't examine objects that are clearly visible, or they can't manipulate an object that is basically right in front of them. It forces players to repeat their action after shifting a little bit to one side or another, which is not a big deal, but it's still an annoyance. And that's something I'd like to avoid if possible.

I've considered various options, but no one solution seems to account for all situations. I could, for instance, perform a raycast and then repeat it if it returns a DTS object, exempting that DTS object from the second raycast. That would tell me if two DTS objects are blocking the target, or a DTS and an interior, and that might at least give me a good excuse for saying the target is "not visible enough." But then you have the situation like #8, which causes problems with that. And in the initial screenshot above, the bed is blocked by both the knife and the hare -- two DTS objects, even though the bed is still fairly visible.

The main issue is coming up with a response from the engine that takes into account whether or not the target object is visible to any extent to the person playing the game. Whether or not that can be done is a good question. But also, to what extent does the target need to be visible? How much should be visible to consider it visible enough? That's a tough question, and I'm not even sure that can be addressed.

Just some more of the pain as we evolve from text to graphics. I'd be happy to hear some thoughts or suggestions from the community on this one.

Vespers3D: Adventures with NPCs, Part II

Rubes — 2007-07-26T03:54:27+00:00

Vespers3D: Adventures with NPCs, Part II

Recap:
Vespers3D is our attempt to bring old-school text-based adventure games (interactive fiction) into the world of real-time first-person 3D - a new genre we are calling 3D/if (3D interactive fiction). It is based on Vespers, Jason Devlin's fantastic text IF game that won numerous awards from the IF community, including Best Game at the IFComp'05 and the 2006 XYZZY awards. Vespers provides a compelling setting and a powerful storyline for a game that will, in the end, be something akin to Myst but with a fully interactive 3D environment and good old-fashioned text command input and output.

We continue on with our efforts to bring our NPCs to life, beginning with bits and pieces of text from the IF version of Vespers and ending with a modeled, animated, and voice-acted 3D character. Last time I discussed the development of Matteo, the oldest monk at the monastery; the second character we tackled was Constantin, who had some interesting and unique challenges of his own.

Constantin: From Concept to Character

We started out with a very general picture of Constantin; he's middle-aged, a handyman around the monastery (he was a former blacksmith), and a notably large man with a short temper. Again, we didn't have a lot of text to go on initially aside from a short description (which was actually removed from the game prior to the final release):

An enormous, hulking man, Constantin is taking the lack of food worse than the rest of the
brothers. The former blacksmith has taken to religious life quite well and has assumed the
responsibilities of almoner and cellarer since those two brothers died.

After some discussion between myself and Jason Devlin (the author), we decided we wanted Constantin to look extremely large, but not quite like a giant; not fat, but certainly heavy and imposing. We presented these ideas to N.R. Bharathae, our lead artist, who came up with his concept for Matteo.

Figure 1. Constantin concept sketch.

Seemed just right to me. With this as his starting point, N.R. designed Constantin's 3D model and then applied some slick textures. As before, we were going for a more realistic appearance for our characters, and N.R. came through for us again.

Figure 2. Constantin textures.

Constantin starts out the game sitting on a chair in his room, skinning a hare with his knife. So to get him ready for the game, we had to outfit him with the appropriate objects.

Figure 3. The Constantin model.

While N.R. was working on this, we also had the task of finding and recording a voice actor for the part. Trying to match a voice to a character like Constantin was not easy; we needed an actor who could really fit the part of a large, short-tempered man with an appropriately deep voice. The man we found to play the part was Jason Nacey.

Jason didn't have any real experience with voice acting prior to this, but he had been exposed to it through the work of his father. It was actually his father who heard about our voice auditions, and who passed the information along to Jason. Although it seemed a little awkward at first, Jason ended up doing a great job, and I think his voice fits the part perfectly. Here's a shot of Jason alongside Constantin, followed by a short bio he wrote.

Figure 4. Jason and Constantin.

"I have always been fascinated by a voice actors' ability to create a story by the sound, inflection, and timber of their voice. I often spend time driving my wife and 5 kids around in our minivan. We ordered our latest van with a DVD player for the kids. Without the benefit of video on long drives, I am able to really tune into the actors voices, and in this way I really became a student of the professionals like Nathan Lane (Lion King), Jason Lee (The Incredibles) and John Ratzenberger (what hasn't he done?!) to name a few. I have thought for a long time that to be able to take on that challenge would be fun and exciting. It was from my father that I first heard about the auditions for the voice parts for Vespers. Having had no previous experience with any formal voice acting, I went to the audition with no thought of actually landing a part, but I was very excited to just try and maybe, afterwards, be able to get constructive criticism on how I could improve my abilities. I was extremely nervous for the audition, and almost called and canceled so that I would perhaps save myself serious embarrassment. I finally resolved that everyone there would be strangers, and if I was going to stink up the place - dammit - I was going to it LOUDLY! I was elated to find out that I was chosen for the part of Constantin. And I look forward to many more opportunities to have this much fun again." -- Jason Nacey

Finally, there's the work of our lead animator, Matt Chin. Matt and I were still familiarizing ourselves with Torque's animation system while working on Constantin, so it took us some time to work out the kinks to produce what we wanted. Unlike Matteo, we wanted Constantin to play a looping idle animation; as mentioned above, when first encountered, Constantin is sitting in his room skinning a hare with his knife. So we needed a system where we could play this looping animation continuously, while also offering us the ability to choose one of two things for his speech animations: (a) interrupt the idle sequence to play a full body sequence in response, or (b) continue the looping idle sequence while playing a mouth/head animation on top of it.

To do this, we designed it so that some speech animations are full body animations (played with setActionThread), while others are blend animations (played with playThread). Then we set up our Sequence Manager to recognize which was which, and when it needed to to stop the idle animation before playing a speech animation.

As an example, here is a short portion taken from the text version of Vespers, with the player's commands in bold caps:

Constantin's Room
Constantin is one of the few brothers with anything in his room besides a bed. A few tools lay
next to the door in the northwest; remnants of his life as a blacksmith. A smell lingers here: a
sour smell.

Brother Constantin sits on the bed, a young hare dangling from his hand. His knife moves swiftly.

>TALK TO CONSTANTIN
"What do you have there, Constantin?" you ask, leaning forward. 

"Something to eat," he grunts.

>AGAIN
"Is there no food left in the cellar?"  He flinches slightly. 

"No. There is nothing in the cellar."

>AGAIN
"Well, be sure to tell us when you are finished. We are all hungry." 

"I will."

>ASK CONSTANTIN ABOUT CELLAR
"What?" he startles. "I'll get around to taking the lock off. There's no food left down there
anyway." His eyes darken as they meet yours. "There's no reason to go down there
anymore."

And here is the same portion of the game, as we developed it in 3D with animation and sound. Click the image below to see the Google video:

Figure 5. Click image above to see Constantin in action.

Hopefully that gives you all some idea how we went through the process of developing Constantin from a character in an interactive fiction game into a 3D animated and speaking NPC model. The final result, I think, is a nice combination of writing, modeling, texturing, animating, and voice work, the combined work of a group of really dedicated and talented people. Next time I'll introduce Lucca, the youngest member of the monastery and a character with challenges of his own.

Thanks for reading!

Vespers3D: Adventures with NPCs, Part I

Rubes — 2007-07-01T04:04:17+00:00

Vespers3D: Adventures with NPCs, Part I

Recap:
Vespers3D is our attempt to bring old-school text-based adventure games (interactive fiction) into the world of real-time first-person 3D - a new genre we are calling 3D/if (3D interactive fiction). It is based on Vespers, Jason Devlin's fantastic text IF game that won numerous awards from the IF community, including Best Game at the IFComp'05 and the 2006 XYZZY awards. Vespers provides a compelling setting and a powerful storyline for a game that will, in the end, be something akin to Myst but with a fully interactive 3D environment and good old-fashioned text command input and output.

Things have been moving forward lately with our NPC development, which has been a very gratifying experience. Watching a character go from a text description to a fully animated and speaking NPC model is something else. And as we move from one character to the next, incorporating each into the game, the whole project really starts to come to life. It sure as hell beats plugging away night after night on the nuances of text parsing.

It takes a lot of steps to go from point A to point B, and a number of people to make it happen, so I thought it might be interesting to review the procedure we went through for each NPC in the game. Vespers has six NPCs: five brothers and one village girl. This way, we can introduce each character while providing a little insight into our development process.

Matteo: From Concept to Character

Matteo was the first character we tackled, mostly because he has the smallest part in the game. In the text version of the game, however, there are very few detailed descriptions of the characters, so we didn't have a lot to go on initially. The one passage in the game that gives some background on his character (which, interestingly, was later removed for the final release) went as follows:

"Ah, Matteo. He was one of the first. Although he is a few years your senior, he remains obedient and helpful. He loves Saint Cuthbert's, almost as much as you. The loss of the brothers has been especially hard for him. He was as much a father to them as any priest."

So we began with an older, gentle, fatherly figure, and after some discussion with Jason Devlin (the author), we also decided on a person who is shorter and overweight. We presented this to N.R. Bharathae, our lead artist, who came up with his concept for Matteo.

Figure 1. Matteo concept sketch.

Once we had a good starting point, N.R. set to creating and revising the 3D model, and then applying the textures. We were going for a more realistic appearance to our models and, needless to say, we were very excited with the results.

Figure 2. Matteo model.

Figure 3. Matteo textures.

While this was going on, I was also working hard on the voice recordings. After a long process of auditions last fall, I went through the difficult task of preparing the scripts, setting up and performing the recording sessions, and then splicing and editing each of the lines into separate WAV and OGG files.

Fortunately, we were able to get a really talented actor, Alan Meyer, to do the voice work for Matteo. I asked each of our voice actors for a head shot, since I thought it would be fun to see each of them beside their final in-game NPC model. Here's a shot of Alan alongside Matteo, along with a short bio he wrote.

Figure 4. Alan and Matteo.

"As a voice actor, Alan Meyer enjoyed playing a role in Vespers tremendously. During his three decade acting career Alan has appeared in dozens of plays and films. He taught theater and video production classes at Bonneville High, in Ogden, Utah, for over fifteen years. His website http://speakingpart.com features his voice acting demos and current resume."

Finally, bringing him to life was our lead animator, Matt Chin. Matt was new to the Torque system of animation (as was I, of course), so it took us a little while to work out the kinks and the best workflow process. But once we were both comfortable with it, he was able to really breathe life into the model. It's not easy to show here, but Matt did a great job with a lot of the little details, including blinking, eyebrow movement, and even some lip sync. We ended up using mostly full body animations for Matteo (unlike some of the other NPCs), since we found little need for additional blend animations.

The final result, I think, is a fantastic combination of writing, modeling, texturing, animating, and voice work, the combined work of a small group of really dedicated and talented people. Here's a link to an extended video of the initial interaction with Matteo in-game if you're interested -- and I apologize for the video and audio quality:

Figure 5. Click image above to see Matteo in action.

Hopefully that gives you all some idea how we went through the process of developing Matteo from a character in an interactive fiction game into a 3D animated and speaking NPC model. Next time I'll introduce Constantin, who presented a series of challenges of his own.

Thanks for reading!

Vespers3D: Adventures in Cinematics, Part II

Rubes — 2007-06-17T19:57:35+00:00

Vespers3D: Adventures in Cinematics, Part II

Recap:
Vespers3D is our attempt to bring old-school text-based adventure games (interactive fiction) into the world of real-time first-person 3D - a new genre we are calling 3D/if (3D interactive fiction). It is based on Vespers, Jason Devlin's fantastic text IF game that won numerous awards from the IF community, including Best Game at the IFComp'05 and the 2006 XYZZY awards. Vespers provides a compelling setting and a powerful storyline for a game that will, in the end, be something akin to Myst but with a fully interactive 3D environment and good old-fashioned text command input and output.

We continue to make gradual progress as we ease into the complicated world of animation and sound, so I thought I'd outline some of the things we're trying as we implement a system for displaying scripted animation sequences.

Vespers3D and Cinematics, Continued

As I began to discuss in my last plan, Vespers3D is a very linear game, and in the world of 3D, linear means a lot of scripted action including short animated sequences and cutscenes. When players perform certain actions -- like conversing with an NPC, for instance -- we need to be able to produce a specific series of responses. In most cases, the responses consist of simple audio recordings, animation sequences, or combinations of the two. The challenge is to carry out these tasks in a specific order, and with appropriate timing. This is the job of our Sequence Manager.

In my last plan, I gave the following example of a very short, simple interaction between the player (the Abbott) and one of the NPCs (Matteo) from the text version of Vespers:

Brother Matteo leans against the rails, staring into the wind.

>TALK TO MATTEO
"How are you Matteo?" you ask, leaning up on the rails beside him. 

He turns, a friendly smile on his face. "I don't even know anymore." He gives
an exaggerated shrug.

Although that is a relatively simple thing to accomplish with text, in 3D we need to perform all of the following to produce this exchange:

1. Play an idle animation for Matteo, looking out over the countryside.
2. When the player command is received, stop Matteo's idle animation.
3. Play the audio recording of the Abbott asking the question.
4. When that finishes, play Matteo's response (animation plus audio).
5. When that finishes, resume Matteo's idle animation.

The Sequence Manager handles this through our SM_callSequence() command. It accepts arguments including which character to use, which sequence to run, and which step of the particular sequence is next. So for the above exchange, which we call the "talkA" sequence, the Sequence Manager does the following:

case "talkA":
	switch(%index) {
		case 0:
			%npc.getDatablock().stopIdleAnimation();
			SM_initSequence(%npc, ap_abbott_MatteoTalkA, "", "audio");
			return;
		case 1:
			SM_initSequence(%npc, ap_matteo_TalkA, "talkA", "anim");
			return;
		default: SM_sequenceFinished(%npc);
	}

The first step of the sequence stops Matteo's idle animation and then starts playing the audio sequence of the Abbott asking the question (in the audio profile "ap_abbott_MatteoTalkA"). The "audio" argument in that statement tells the Sequence Manager that the audio clip should be used to detect the end of the sequence step; that is, the end of the audio clip should be the trigger to advance to the next step in the "talkA" sequence. When this trigger is received, it advances the step counter index and calls this routine again.

The second step then starts playing Matteo's response, which consists of an audio clip ("ap_Matteo_TalkA"), and an animation sequence ("talkA", which is defined in Matteo's TSShapeConstructor datablock). It also tells the Sequence Manager (via the "anim" argument) that the end of the animation sequence should be used as the trigger to move to the next sequence step.

The final step of the sequence ("default") calls the SM_sequenceFinished() routine, which cleans everything up, returns control to the player, and returns Matteo to his idle animation sequence.

Using this method, we get the following result (no, it's not embedded video, just click to see the video on Google):

Figure 1. Click image above to see Matteo in action.

So this is basically how the Sequence Manager is set up, and we need to basically define a series of sequence steps like these for every scripted action that takes place in the game. Most are very short, simple series like above, but the nice thing about this approach is that it provides a bit of flexibility in the various things we can do with each of the characters. It allows for much more complex, scripted interactions -- including longer cutscenes. Since the Sequence Manager handles scripted sequences for each individual NPC, we could set up sequences where one of the steps includes initiating a sequence for one or more other NPCs. This way, we could have one action set off a series of sequences, either simultaneously or in succession, which could produce a long series of interactions such as a conversation between multiple characters. Fun stuff!

Animation States

Setting up each individual NPC for animation like this is also a bit of a challenge. TGE was designed with some pretty decent animation functionality built in that allows for a lot of creativity, but it's also pretty persnickety and quite often grumpy. We really needed to spend some time experimenting with it to come up with a system that allows us to easily implement the sequence routines mentioned above.

In my last plan, I began to discuss some of the details of a "state machine" that we would use to track and implement the different animation states for each character. Since then, we've modified things to fit more with Torque's different animation features:

Figure 2. Basic NPC animation state chart.

Each character is basically divided into two animation threads: one for "idle" animations, the other for "speech" animations. The former consists primarily of full-body animation sequences that are used to display animations when the character is not engaged, like Matteo looking out over the countryside, as above. Since these are generally full-body animations, we use setActionThread() to play them. They can be looping or non-looping, and when we want them to stop, we just call setActionThread() with the root sequence, and the NPC smoothly transitions back to his or her root position. We then use that root position as the starting point for the latter, the speech animations.

The speech animations are usually (but not always) simple animations that involve mostly the NPC's mouth and head. Because of this, we can set them up as blend animations and play them using playThread(). Thus, we can have the NPC talking while continuing their idle animation. If, however, we want a particular speech animation to be more involved than just the mouth and head, we can set it up so that the idle animation stops first, and then the speech animation is played (as with Matteo, above). After the speech animation finishes, this thread returns to the inactive state, while the idle animation thread either continues or returns to action.

Thus, we have a system set up where animation states work in conjunction with the Sequence Manager to produce some pretty decent NPC interactions, with the flexibility to produce highly scripted, complex cutscenes when we need to. Such as the following sequence from the text game, which I mentioned last time and which is part of the first big cutscene:

Constantin strides forward and smacks Lucca across the face, sending him sprawling into the snow.
"Get away from him, murderer!"  he shouts, eyes burning. 


"Constantin!" Ignatius shouts defiantly, stepping between the two. Although Constantin towers
above him, Ignatius looks taller than you have ever seen him. "Leave the boy alone." 


Drogo giggles.

Should be fun putting that one together.

Next time, I'll start to introduce each of the six NPC's in the game one by one and discuss how we developed each one from a text description in Vespers to its concept drawing, modeling, voice recording, and animation. It's really interesting to see how each one has taken on an identity of its own, and I hope you will find it interesting as well.

Vespers3D: Adventures in Cinematics, Part I

Rubes — 2007-04-26T19:27:43+00:00

Vespers3D: Adventures in Cinematics

Recap:
Vespers3D is our attempt to bring old-school text-based adventure games (interactive fiction) into the world of real-time first-person 3D - a new genre we are calling 3D/if (3D interactive fiction). It is based on Vespers, Jason Devlin's fantastic text IF game that won numerous awards from the IF community, including Best Game at the IFComp'05 and the 2006 XYZZY awards. Vespers provides a compelling setting and a powerful storyline for a game that will, in the end, be something akin to Myst but with a fully interactive 3D environment and good old-fashioned text command input and output.

Well, another three months have passed since my last .plan. It has been a slow three months, but we continue to make gradual progress as we ease into the complicated world of animation and sound. This is a pretty long .plan, so bear with me.

Vespers3D and Cinematics

Generally speaking, interactive fiction games place primary emphasis on one of two things: story or puzzles. It's rare for an IF game to do both really well. Games that focus on puzzles seem to have a harder time putting together a flowing narrative; in contrast, those that emphasize story become quite linear to avoid having puzzles interrupt the flow too much. The text version of Vespers is one of the latter -- there are many puzzles, but they are essentially secondary to plot and character development, making the game a very linear experience. But in the 3D world, "linear" means a lot of action that is scripted, whether that means short animated sequences or actual cutscenes. Vespers3D will thus be a very cinematic game, and implementing that is a big challenge.

Sequences and State Machines

Although it's probably more theoretical and maybe not entirely necessary, I decided to approach the handling of non-player objects (typically NPCs, but potentially other objects as well) in terms of state machines. Torque already does this with mounted images like weapons, but I need something a little different. In our project, most objects will have the following basic state chart to begin with:

Figure 1. Basic state chart.

Following object initialization, the object will enter an "idle" state, where it basically sits happily doing nothing. Once in a while, perhaps at random, it can be told to play some basic "idle" animation or sound. An example from our game is one of the windows in the refectory (dining hall); it sits there until, at some random interval, it plays an animation and sound to make it appear to blow in the wind, slapping shut and opening again. It then returns to the idle state, waiting for the next random animation call.

More complex objects, like doors or NPCs, require an additional, "non-idle" state, as such:

Figure 2. Expanded state chart.

Here, objects receive some sort of trigger to tell it to transition to the "active" state to perform some function (e.g., animation or sound) -- a door will play its "open" animation/sound, or an NPC will respond to a question with an animation/sound clip. Afterward, it transitions back to its idle state.

What happens during the "active" state is really more complicated than that, though, as shown in the next figure:

Figure 3. The problems with performing sequences.

When an object is told to become "active", it needs to know what sequence to play: that can consist of an animation sequence alone, an audio sequence alone, or both together. Once that happens, the game needs to know when that sequence has finished playing, in order to proceed to the next state (represented by the lower ?). Once it figures that out, then it needs to know what to do next -- if it should return to the idle state, or if it should stay "active" to play another sequence right away (represented by the upper ?).

What this means, then, is that for every "active" sequence an object plays, three key pieces of information are needed, as shown below:

Figure 4. The final state chart.

The three components are: (1) which sequence to play (animation and/or audio); (2) what trigger should be used to signal the end of the sequence (animation or audio); and (3) what to do when the sequence is done. Also note that step (3) might additionally include a trigger to start a sequence for some other object as well.

So this brings me to the two important features of the state machine: end triggers and script sequences.

End Triggers

Cinematic sequences can be tough because they require fairly precise timing for each component in order to convincingly pull it off. That means being able to direct particular animations and/or sounds to start at specific times. The problem, though, is that some sequences need to start right when another sequence ends. Take this simple sequence from the text version of Vespers:

Brother Matteo leans against the rails, staring into the wind.

>TALK TO MATTEO
"How are you Matteo?" you ask, leaning up on the rails beside him. 

He turns, a friendly smile on his face. "I don't even know anymore."
He gives an exaggerated shrug.

Pretty straightforward exchange, at least from a text standpoint. But in 3D, the following actions all need to take place:

1. Play the audio recording of the player/abbott asking the question
2. When that is finished, transition Matteo to the "active" state
3. Play Matteo's animation sequence (turning, smiling, shrugging)
4. Also play Matteo's audio response simultaneously
5. When finished, return Matteo to the "idle" state

But how do you know when the abbott's audio recording is finished and to proceed to step 2? How do you know when Matteo's animation sequence is finished and to proceed to step 5?

It turns out animation sequences are pretty easy; when DSQ's are played, there is actually a callback already in the engine for ShapeBase objects called "onEndSequence". That makes it simple, at least for animations. For sounds, it's a little more difficult. I've looked into some kind of similar code so that the engine can know when a particular audio clip has finished playing, but there doesn't appear to be an easy solution. For now, I've gone ahead and used a simple (but laborious) workaround: know the duration of each audio clip and schedule a custom "onAudioDone" call to occur in that many milliseconds. It's not perfect, given the fact that game time is a bit slower than real time, but for anything except the longest audio clips it works well enough. It's also important to note that it is relatively uncommon to have just an audio clip playing by itself; typically, it will be a combination of animation and audio, and for that we can just stick with the more accurate animation "onEndSequence".

Script Sequences

Highly scripted scenes require us to know what sequence to play now, and what sequence(s) to play when finished. That's basically what script sequences are for. Without going into too much detail, each object (typically NPCs) keeps track of what state it is in, what sequence should be played when a particular trigger is received, and what state and sequence (either idle or active) should follow it.

To handle most of this, I've created a set of script functions I call the SequenceManager. While each object keeps its own script sequence, the SequenceManager is what handles all of the dirty business: initiating an object's sequence, handling actions when an object's sequence is finished, and doing all other necessary housekeeping. It makes for a relatively straightforward implementation, although it's still in the developmental stage and there will undoubtedly be kinks that need to be worked out.

Problem Areas

A few issues have come up as I try to implement this system, most of which are related to the transition from a turn-based text game to a real-time 3D game. The turn-based nature of text IF makes it relatively easy to control what happens as a result of the player's actions and what actions can be performed next -- or, more specifically when the player can act next. In real time, however, there are some potentially complicated situations.

Going back to the simple interaction between the player and Matteo above, the player asks a question and Matteo responds with audio and animation. In the text game, the player sees the full interaction before he can then enter a new command. But in 3D, as soon as the audio and animation start playing, nothing is limiting the player from entering a new command -- asking another question right away, talking to someone else, or even just walking away. This would be bad.

In response, I've implemented a sort of "pause" feature that prevents most player input while certain sequences are being played. So, when the player asks Matteo a question, he is prevented from typing or entering any commands until the response sequence is finished. That means no typed commands, no mouse commands, and even no moving around -- all you're allowed to do is pan the camera and click on objects. I chose to indicate this "pause" state with an hourglass image in the bottom corner of the screen, as such:

Figure 5. The hourglass in the corner indicating no player input.

It may not be the most elegant solution right now, but it allows a certain level of control over things to keep the action moving forward as it should.

It becomes even more complicated, however, when you start thinking about the 3D nature of some really complex action sequences. Take, for instance, one of the main dramatic scenes in the text game. Below is the first part of it, which spans several player turns (in bold):

Base of the Bell Tower

The smooth patch of snow at the base of the tower, formerly cut only by a single line
of footsteps, is now a mash of dirt and blood. Steps lead northeast and up to the tower,
and to the southwest is the cloister. 

Brother Matteo lies upon the ground, blood trickling from the side of his head. Lucca
kneels by his side.

The remaining brothers are gathered around the body, shouting.

Drogo jumps up and down, rubbing his hands with glee. "It begins," he squeals to you
through a wide grin.

>EXAMINE MATTEO

He looks so calm. Tiny snowflakes trace the creases in his face, lingering longer and
longer as time passes. His mouth fills with snow.

Constantin strides forward and smacks Lucca across the face, sending him sprawling
into the snow. "Get away from him, murderer!"  He shouts, eyes burning. 

"Constantin!" Ignatius shouts defiantly, stepping between the two. Although Constantin
towers above him, Ignatius looks taller than you have ever seen him. "Leave the boy alone." 

Drogo giggles.

There is so much to consider here it can be pretty intimidating. That's a lot of highly coordinated animation and sound taking place, and I have to consider things like: What happens if the player is standing in the way of the scripted action? How to handle player input during this extended sequence? It's allowed in the text game, although it's difficult to actually alter the action sequence. But do players really want to be silent "observers" to all of this action, especially when you consider they are playing one of the key characters at the monastery? Should this just be done as one long cutscene?

Some tough questions yet to be answered. Until next time, I'll leave you with one last screenie for sticking with this .plan to the end.

Figure 6. The Entrance Hall, doors open.