Game Development Community

Vespers3D: Adventures with NPCs, Part III

by Rubes · 09/03/2007 (11:46 am) · 9 comments

homepage.mac.com/rubes/plan12/Title.jpg
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.

homepage.mac.com/rubes/plan12/Matteo_Lucca.jpgFigure 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:

homepage.mac.com/rubes/plan12/LuccaSample.jpgFigure 2. Lucca textures.

homepage.mac.com/rubes/plan12/LuccaModel.jpgFigure 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.

homepage.mac.com/rubes/plan12/Combo.jpgFigure 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:

[b]Matteo's Room[/b]
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.

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

>[b]TALK TO LUCCA[/b]
"Why do you dig, Lucca?" you ask. 

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


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

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

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

>[b]ASK LUCCA ABOUT MATTEO[/b]
"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:

homepage.mac.com/rubes/plan12/Flow.jpg
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:

homepage.mac.com/rubes/plan12/Video.jpg
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!

#1
09/03/2007 (1:32 pm)
Very cool Rubes! Your .plans are awesome.

You coming here to show it off at IGC?
#2
09/03/2007 (1:51 pm)
You bet, Andy. Looking forward to it!
#3
09/03/2007 (4:16 pm)
Cool stuff Rubes! Very interesting.
#4
09/03/2007 (9:17 pm)
Another great plan! Always looking forward to more!
#5
09/04/2007 (5:28 am)
Nice job.
I myself thought it would be good to have at least 2 sequences for any given movement or action, that would randomly be selected, to give a game a more natural feeling.

Just one thing - I feel lazy enough to don't browse your previous blogs to find the answer... ;) - so, why are you using text entry for actions, instead of a conceptual menus linked to objects?
For example, clicking on Lucca to talk to him.

I've been of course be playing text based adventures
#6
09/04/2007 (9:26 am)
@Stephan: Thanks for the comments. I chose text entry mainly because of its open-endedness. I never really liked the idea that contextual menus basically present you with all of the possible options -- it would be like telling the player all of the possible verbs in a text game. Sometimes that's part of the puzzle. And there's also the problem of verbs that are not linked to specific objects -- how are those selected?

It gets back to the long (and long-standing) argument about the best method for command input in an adventure game (text or otherwise). Providing menus (text or icon-based) can make things easier on the player, but I think it also stifles creativity -- both in the developer and the player. It restricts the different verbs you can use in the game, and it takes something away from the player's task of trying to figure out for himself what he's supposed to do next. On the other hand, that opens things up for "guess the verb" problems. I think it's a trade-off either way.
#7
09/04/2007 (10:07 am)
Fantastic work! I always enjoy reading your blog posts.

The video BTW looks really really good -- I love the way he talks so convincingly while he's digging and going through his other animations -- you did an absolutely fabulous job with blending those.

My wife and I are definite fans of text-entry adventure games. We still play through the old Sierra Hero's Quest (Quest for Glory) from time to time, and we never play the menu-based remake -- always the text version. It's just so much better that way. :)
#8
09/04/2007 (2:56 pm)
Agreed with Clint.

@Rubes: I still remember a game I needed almost 1 hour to figure command "Raw boat" was the good one.
Anyway, typing is good for fingers I presume. ;)
I got your point and I agree, but I'm an "old" player, and I grew up without computers and then with computers without graphics. :)
#9
09/04/2007 (5:29 pm)
Thanks guys, I appreciate the comments.

I agree with Clint, I just prefer text-based entry better. The problem you describe, Stephen, is the classic "guess the verb" problem that's prevalent in a lot of text adventure games. I think you can overcome that, for the most part, through good game design, but not entirely. That's one of the drawbacks of text parsing, but I do think there's a tradeoff no matter what entry system you decide upon.

I'm probably considered an "old" player myself. I got my start on my dad's giant Northstar computer running CP/M and typing in BASIC code from this classic book.