The End of January Vespers Thing

January was a very busy month for the game, and I feel like we've made some great progress on a number of fronts. I think part of the reason is that we had set a goal for ourselves: try as hard as we could to get most of the work for Act I finished by January 29th, the date of the first Utah Indie Gamers night of 2009, so we could show it off in public. Setting goals can be useful for getting people focused on particular tasks, and it's probably a good way to work even when those goals aren't met.

Which is a good thing, because we didn't meet that goal.

Which itself is probably a good thing, because I wouldn't have been able to show it off at the Utah Indie Gamers night anyway. This past Tuesday morning, I recall having a slight wispy cough as I left for work; by late Tuesday night, I was begging for mercy. The microbes have barely let up on their stranglehold since. I was pretty sure this was influenza (despite getting my flu shot), although some of my colleagues tell me a similar bug called parainfluenza is making the rounds here these days, and the symptoms are similar. It matters little, they both suck. There are few things more humbling than sleeping on the bathroom floor (because the bedroom garbage can was already full of my heaving) or shaking with chills on the couch despite layer upon layer of clothing and blankets. The Utah Indie Gamers night was Thursday. By then I was only feverish. Now I'm finally not feverish, but I've been reduced to little more than a cough, mucus, and virus factory.

But enough of that. The Vespers engine code is up to version 04k with the addition of a few lines to detect animation triggers. The Torque animation exporter allows you to set keyframes within animation sequences that act as triggers for whatever response you want, which you can specify in the object's onAnimationTrigger method. Like most things that involve the Torque model and animation exporter, it takes a bit of time to figure out precisely how to set this up, but I believe I have it working now with Constantin. I'm now using triggers to specify when to play the scraping sound of the knife skinning the hare, which is nicely timed with the motion of the knife. I'm also using it to more smoothly transition between his idle animations. That should prove to be a very useful tool in the future.

Constantin video. Best viewed in High Quality (bottom right corner).
(Might need to turn up the volume to hear it.)

A lot of the progress in January has been with the animations. Shawn has been working his tail off, and we're now basically finished with the Act I animations for Ignatius, Constantin, and Matteo. The latter two were already animated by our previous guy, but we needed to re-do them for a couple of reasons: first, the animations weren't so great and we wanted to improve them while adding lip sync; and second, we would need re-rigged characters for the first cutscene anyway. Constantin looks tremendously better now than he did before (even my wife noted this), with much smoother and more interesting motions. The same goes for Matteo.

Lem continues to work on Lucca, although it's going slow for him. But that just leaves Drogo and Cecilia, and once those two are finished, we should have ourselves an actual, complete Act I. Add a cutscene on top of that, and we might just have ourselves a working demo. Soon.

Despite having some family issues that demanded his attention for a while, N.R. made some nice progress in January mostly on the 2D front. Most of his efforts were directed at spiffing up the GUI and HUD elements for the game, and I'm very happy with the results. In addition to updated window frames, he designed really nice Options and Help window GUIs, incorporating some of the elements from the church fresco designed by Régis.

Options dialog.
He also incorporated a sweet ribbon design with a medieval image he obtained and utilized in the Main Menu GUI.

Main menu screen.
(Click for larger version)

He's also been working on additional visual goodies such as a more realistic and bloody stone for Lucca to scrape at, and a more interesting and natural appearance to the top of the belltower, exposing the floor boards while mounding snow around the outsides.

The new bloody flagstone.
(Click for larger version)

The updated top of the belltower.
(Click for larger version)

N.R. also spent a crazy amount of time working on a new Orange River Studio logo design for me during January, and I think we're getting close. By next month's update we should have a design finalized. N.R. has been dealing with a lot this month and I'm amazed that he's been able to get as much done as he has, and he continues to do some pretty amazing work. I am a very lucky person.

Despite my bitching about fonts earlier this month, I'm still in negotiations with the P22 foundry for a much more reasonable licensing fee for the Cezanne typeface, which is good news. I really like the font and I appreciate it for what it offers, and it's nice to know the P22 guys are very much open to creative solutions for this and are willing to work with small developers like me. I'm pretty confident it will work out well, and I'm really looking forward to settling on that font once and for all.

Finally, as I reported last month, we decided to try a little something different and utlize Pieter Bruegel's famous painting, The Triumph of Death, as the main background for our opening splash screen. I tried a couple of new things with the splash screen, including some nice closeups and crossfades, and I'm very satisfied with how it turned out. I'd like to go over some of the Torque-specific techniques I used to create it in another blog, hopefully during February.

So despite the bloody, protracted battle with the microbes, January turned out to be a very productive month for Vespers, and I'm looking forward to a good February as well.

Write from the Start

So pretty much one of the most challenging parts of making games for the small indie or hobbyist developer is getting the extra help you need. The developer who can do it all on his or her own -- programming, artwork, writing, modeling, animation, web design, yada yada -- is a rare breed with far too much talent and disposable time. When I made Missions of the Reliant way back when, in (gulp) 1994, I could handle most of it myself because things were just...simpler. I didn't have to worry about modeling or animation, and web design meant little more than plain text and a few animated GIFs (mostly I just focused on BBS's and AOL -- and, sadly enough, eWorld). Life, as they say, was so much easier when we were young.

Unless you start from the beginning with a set of partners, it's tough to find people who are willing to put the necessary time and effort into your project, particularly if they're not being paid. But once you start paying people to provide the services you need, the expenses can start piling up fast. That's especially true for modelers, animators, and 2D artists, where the good stuff usually doesn't come cheap. And since the majority of small indie and hobbyist developers who initiate new game projects are programmers, not artists, you end up with a lot of projects that die on the vine because they just can't obtain or afford the artwork that is needed. As one person I knew said, it's cheaper to program than to create art.

A while back, as these thoughts were bouncing around inside my head, I began to wonder how different it might be if a game project was started by a visual artist rather than a programmer. I started a thread on the GarageGames forums to see if people were familiar with any such projects, and it turned out to be a pretty long thread. Some good thoughts there, but not a lot of games that started with the artist and lasted through to completion and release.

That was a couple of years ago, though, and I know of (or suspect) a few examples since. One that came up recently, as reflected upon by Chris over at The Artful Gamer, is the Quest for Glory II remake by AGDInteractive through the efforts of artist Eriq Chang. As Chris notes:

"I call this a 'renaissance' of computer game re-makes because the creative torch has finally been returned to artists. Instead of designing and conceiving games from scratch without any attention to their expressive qualities (as we see in most commercial games), AGDInteractive (has) put artists behind the wheel and allowed them to drive the creative process."

But I'm not really here to discuss how visual artists can drive creative game development. The reason I bring this up is because I was reminded of this topic during a recent web chat about a similar concept.

Back at the Austin GDC last year, I found myself most interested in the discussions and talks on game writing, and through those interactions I was introduced to the Game Writers SIG, a "community of game writers whose goal is to improve the quality of games writing by increasing overall awareness of the craft of games writing and how it fits into the game development process." Although it's not exactly my specialty, I enjoy following the e-mail list discussions from a distance. Anyone else interested in signing up for the mailing list can check out their sign-up page.

One of the topics that often comes up on the list is how to better promote the idea that writers should be involved in the videogame development process much earlier than they typically are. What often seems to be the case, as I understand it, is that writers are engaged well after a game has been designed, such that the writers are frequently asked to fill in gaps or otherwise work within a well-established framework that has little chance of being altered much. As such, there is little opportunity to shape the project from the beginning, or to impact game design and gameplay mechanics through the writing process.

Something like this was brought up again on the SIG's monthly (roughly) chat meeting, which I checked out for the first time this past week. The discussion turned to the creation of a list of arguments the group could use to convince game companies of the benefit of hiring and involving writers. One member, Reid, posed the following question:

"Here's an idea. What if the SIG made a small game to showcase the value of writers when they have more creative control and are brought in early?"

In response, Corvus brought up the idea of using Inform to create a piece of interactive fiction. Nice idea, I would have to say. But then again, there are already plenty of excellent IF games already out there that have been written by, you know, writers. Is the problem that game companies aren't familiar enough with good IF games, and they just need someone to make them take a closer look? Or is it perhaps because companies that make graphical games might not be terribly interested in what text-only IF games might have to offer?

I don't know the answer to that, and maybe I'm missing the mark, but I do know how I feel about the whole idea -- it forms the basis for the Vespers project. When I started this thing, the goal was to create a 3D first-person adventure game that was based on an established interactive fiction game. The main reason was to see how a typical text-based interactive fiction game would mesh with a visual 3D interface, but just as importantly, the idea was to start with a game that was fully designed and written by a writer. That's one of the big advantages to having started with Jason's Vespers game -- the plot, dialogue, characters, setting, puzzles, all of it was already written, tested, played, and critiqued. We knew what worked well, and what didn't. Characters and setting were already nicely fleshed out. All we needed to do (easy for me to say) was to take that entire game design and translate it from text to graphics, while still keeping most of the text.

In the end, Vespers might not necessarily be the best example to show game development companies to convince them of the value of starting with a game writer, but I certainly hope it will encompass this idea and at least help move the field in this general direction. That's the goal, at least.

A secondary but related goal is to use this game as an example of what, specifically, interactive fiction has to offer to the mainstream videogame industry. While I wouldn't necessarily describe IF as a "mature" medium, it has been around considerably longer than most other types of videogames and, as such, I believe it has a maturity that perhaps other genres lack. This extends to some of the more interesting areas of game design (at least to me) -- puzzle design, narrative design, character development, and conversation dynamics, to name a few. I think there is a lot that mainstream game designers can learn from some of the better or more advanced IF games. It's an overlooked genre and community, and it's something I plan on submitting to an upcoming GDC for a lecture and/or group discussion. We'll see if anyone's listening.

An Interview With SPA*

Earlier this year, Spanish IF author and aficionado Urbatain asked to do an interview with me on Vespers. Over about three months, we exchanged a number of e-mails and covered a variety of topics, mostly on different aspects of the 3D adaptation of interactive fiction. It turned out to be a really long interview in the end, but it probably could have gone on much longer. He asked a lot of challenging questions, and I think his enthusiasm for the project really shows, which made for an enjoyable interaction.

Urbatain's intention was to publish the interview in the Spanish-language web-zine SPAC (Sociedad para la Promoción de Aventuras Conversacionales), and also to share it with Jimmy Maher and SPAC's English inspiration, SPAG (Society for the Promotion of Adventure Games). I lost track and didn't realize the interview was put up on SPAC's web site last week, translated into Spanish.

The fun part about the interview is using a web page translator, like Yahoo's Babel Fish, to translate it back into English. So I get to see my responses go from English, to Spanish, and back into English. So something that started like this:

Urbatain: When did you first decide to develop a "graphical IF" game?

Rubes: Well, as I mentioned a couple of years ago I got the itch again to make a game. I really didn't anticipate being able to make a 3D game, though, since I had no interest in the complexity of those engines and the steep art requirements, but I somehow stumbled across the Torque Game Engine from GarageGames and suddenly it seemed like a 3D game was a possibility.

...gets translated there and back to look like this:

Urbatain: You throw the presentations, we go to the grain. When the idea came to you to realise an Interactive Fiction game (3D or 2D) with graphs?

Rubes: Good, since I have mentioned, it does a few of years again gave gusanillo me to match. It really did not anticipate to match in 3D, I create, because it did not have interest in the complexity of the graphical motors in 3D and the pronounce graphical requirements, but somehow encountered the motor “Torque Game Engine” of GarageGames, and it seemed suddenly to me that to match in 3D it was a possibility.

Fun times, man.

Anyway, now, with the release of the latest issue of SPAG, the interview is now available in its original English. The direct link to the interview is here, although I encourage reading the whole issue. There is an interesting editorial by Maher, who wonders, as many of us have:

Lost Pig probably was the best game of 2007. But why was it the best game? Where are the IF games that, to paraphrase a famous old Electronic Arts ad, make us cry?

There is also a good continuation of this discussion on RAIF, as well as a good rebuttal and discussion on Emily Short's blog.

Plus much more.

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.

Vespers: The Power of the Bool

One of the things that has always been nagging at me since starting development on Vespers is game performance. We haven't really been developing with frame rate in mind, our thought being that we would leave optimization until we had most of the content plugged in. Most of that optimization would come from the graphics end -- LOD, portals and zones, textures, things like that -- but that's a lot of work for the artist to do, and it's not terribly exciting work at that.

Still, after trying out the game on a number of different systems, I was not very happy with performance even at this unoptimized stage. Frame rates on the better systems would rarely get to 30fps, even at lower screen resolutions. And in far too many areas, rates were commonly in the teens. In some places with a lot of objects in the field of view, rates would bottom out at 10 or less. Rates in the teens give a pretty choppy performance; rates around 10 are just unacceptable. And on one system, with a lower end graphics card, the game was completely unplayable with rates unable to get above 5.

So recently we started addressing optimization, first by adding some LOD to objects and buildings, and then tackling portals. Unfortunately, portals turned out to be an unwieldy beast that we just could not master. Setting up portals and getting them to work in the Torque Engine can be very tricky, especially for complex models like our monastery buildings -- any tiny little misalignment, visible or not, and you're out of luck. At this point, finding those misalignments would be like trying to find an unknown number of needles in a series of very large haystacks.

So I turned my attention elsewhere, and implemented code to replicate (for the most part) the function of portals and zones. It works well, producing nice frame rate boosts on most systems. Whereas before I was sludging along with rates in the teens and twenties, now I'm getting rates in the thirties and forties, and often more than that. I'm very happy with that.

But there was still one thing bugging me: these performance improvements were seen on my desktop (a PowerPC Mac G5) and on my laptop (an Intel Mac), but only on the laptop when running under WindowsXP. If I ran the game on the laptop under Mac OS X, I was still getting the same crappy frame rates as before. How could that be? Same laptop, same hardware, but under one operating system it runs fine, while under the other it runs crappy.

The desktop also runs Mac OS X, and both the desktop and the laptop have graphics cards with 256MB of VRAM. So I didn't think it could be the operating system itself, or a lack of VRAM on the laptop. I thought it had something to do with the Torque Game Engine code, something specific to the graphics rendering on different platforms and CPUs, probably related to the rendering of buildings like the monastery. I went through round after round of testing, using various tools to analyze the code to see where the slowdowns occurred. Long, boring, frustrating work.

The only conclusion I came to is that the laptop was probably tricking the Mac OS into thinking the video card had run out of VRAM, even though it probably hadn't. And this was likely related to Apple's ATI graphics driver on the laptop, which is different than the ATI driver I use on the desktop (and different, of course, from the one used by XP on the laptop). A driver issue like that is a bummer, since there's not a lot I can do about that. I was not very happy with that.

The only other thing I thought of trying was to mess with some of the global preference variables in the Torque Engine, to see if I could somehow improve performance on the laptop without sacrificing too much on the graphics end. There are a huge number of preference variables available -- stuff related to interiors, lighting and shadows, terrain rendering, and OpenGL performance. The latter struck me as potentially useful, as it would probably be related to the driver. So I started looking at those more carefully, and I saw this one:


$pref::openGL::allowCompression = 0


That seemed interesting. Allow compression...likely related to texture compression. Textures can take up a lot of VRAM, especially if you use lots of them, and lots of large ones -- like my artist enjoys doing. It makes for prettier graphics, but it rapidly eats up memory on the graphics card. And even though I didn't seem to be running out of VRAM, on the laptop it seemed like the system was being tricked into thinking so, which would certainly cause these types of slowdowns. But what could this one little boolean variable do? I set it to 1, and gave it a try.

Amazingly, frame rates in general tripled, and often more than that. Whereas before I was getting annoying, choppy gameplay with rates in the low teens, now I was seeing smoothness with rates in the thirties and forties, sometimes more. And, as far as I can tell, no discernable change in the appearance of the graphics.

Even better, the game now runs on the older system with the lower-end card -- and runs well, with rates in the twenties and thirties, even at larger screen resolutions. I never thought I'd see it running on that machine at all, much less running well.

It's not a solution to the overall problem, which is likely related to Apple's ATI drivers. But still, it's an amazing improvement that appears to come at little to no cost.

And all due to one little boolean. A completely undocumented boolean, I might add.

Vespers: Adventures with NPCs, Part IV

This is the fourth installment of my blog series introducing the six NPCs in Vespers, detailing the development process from text to functioning 3D characters. The three previous installments can be found at Part I, Part II, and Part III.

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 youngest monk at St. Cuthbert's. This time I discuss the development of Ignatius, perhaps the most mysterious of the brothers at the monastery, and the one 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:

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...

Ignatius textures.

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 with his character, as well as a short bio and a shot I took during his recording session:

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.

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 Game Engine 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.

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.

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...

Vespers Update 2/18

Time for another update, the first since starting this blog. There has been some progress in a few areas, although perhaps not enough to warrant one of my more extensive blogs like on GarageGames.

Characters and Animation

Happily, we've finally replaced our previous animator, who left us for more prosperous opportunities. In his place we now have two individuals helping with the character animations, James and Matt, which I hardly have to say is a real gift. Progress on the new characters has been slow so far as we get those two up to speed and comfortable with the art flow. We've also made a few adjustments to what we were doing previously; in addition to entirely new character rigs, we've also been experimenting with a system to provide some pretty nifty lip syncing to go with the voices.

The lip sync process uses a software program called Magpie Pro, which takes the rigged model from 3ds Max and an audio file, analyzes the audio, and generates a text data file that contains all of the keyframe information for setting the model to the accompanying audio. That data file can then be read into 3ds Max, which creates and sets all of the necessary keyframes. It takes a lot of up-front work to rig the model's mouth so that you can create each of the necessary phonemes, but once that's done it's a relatively easy process to generate the data files and import them into Max.

This level of lip syncing may end up being more work than it's worth, but the results so far are pretty impressive and I think it will add to the immersiveness of the game. I'm really looking forward to seeing it in action.

So right now we have Marc working on Ignatius, and James working on Drogo, which should keep me pretty busy in the coming weeks. Both characters are fully rigged, including the facial rigs, and the Ignatius data from Magpie is all ready to go. I'm hoping to see some big progress very soon.

Models

N.R. has been slaving away for us recently, with some pretty awesome results. He's been finishing up the last batch of primary objects to populate the monastery, focusing mostly on the kitchen and dormitory.

Some of his latest work has been a new version of the bed, complete with straw mattress, as well as Constantin's tools and keys. In the text game, the tools actually consisted only of a hammer and some nails, but we decided to expand them a bit to a hammer, tongs, and punch.

The punch can functionally take the place of the nails in the game. We decided to implement all three of the tools as one object to simplify things, although the player can refer to them individually, if desired.


We have a few more objects to create for the kitchen to make it more recognizable -- some pots and pans, some plates to place on the shelves, and some empty hooks for the ceiling. Once these objects are done, that would finish most of the important scenery objects in the game, which would be a nice accomplishment. We'll still need a few more environmental additions to give the place more atmosphere, but the majority of the object work will be done.


In the meantime, N.R. is focusing his attention on the monastery, and trying to portalize the interiors to help optimize performance. Portal construction, as it turns out, is one of the more cruel practical jokes the world of Torque plays on its artists. It's a very complicated and time-consuming process, not to mention fussy and hypersensitive. Breath incorrectly while you're creating portals, and either the exporter will throw up on you or the game engine will laugh in your face. I think it's definitely testing N.R.'s patience. It's unfortunate that it's such a critical part of our model, but if we can get it working I think it will really boost our framerates. I'm keeping my fingers crossed.

Code

Not a whole lot new on the code front. I've mostly been installing more verbs lately, verbs like EAT, DRINK, LOCK, and UNLOCK. New verbs are fairly easy to implement, although the code for performing the actions on specific objects can get a little complicated when they involve playing animations (like for LOCK and UNLOCK) or switching models (like for EAT).

The other significant piece of code that I implemented recently is the "implied take" process. It's commonplace in IF games to allow the player to perform actions on objects without first possessing the object -- in such cases, the engine performs an "implied take". Basically, if the player tries to perform an act that requires possession of the object, the engine will insert a "TAKE" command prior to performing the action. So for instance, if the player tries to UNLOCK HATCH WITH KEYS while the keys are sitting on the floor next to him, the typical IF engine will first perform a TAKE KEYS command before performing the UNLOCK action (if the TAKE action is successful). Most engines will respond with a line such as "(first taking the keys)" or some such message, so this is how I implemented it.

It turns out to be a fairly complicated process. In most cases like this, I would just generate a "TAKE OBJECT" command and run it through the parser, but because of issues that deal with text output (for delivering the appropriate message) and remembering the previous command entered, this would cause problems with my parser. So instead I had to create a separate "implied take" function, and shoehorn it into the existing code.

It wasn't pretty, but on the bright side it did allow me to discover and fix a few previously unknown bugs in the parser. It's working now, but I haven't tested it extensively. Hopefully I didn't end up breaking something else.

There's also the issue of other "implied" verbs, which I haven't tackled yet. I know that opening doors can also trigger an "implied unlock" command, as is done in the game "All Things Devours" (which I highly recommend), for example. I'm not sure how many other implied verbs there are, so it will probably take a bit of searching around.

That's about all for now. Hopefully soon I'll be able to give a more extensive update on our character development, and with any luck perhaps a report on our successful implementation of portals.

Implementing an IF interface in 3D

Most of today's graphical adventure games eschew text input and output for more streamlined, symbolic interfaces and visual feedback. The typical IF game is somewhat unique these days in that it relies entirely on text for both purposes. There are advantages and disadvantages to each interface type, but what I want to know is, could a hybrid IF-like interface work in a 3D graphical game?

Rather than going into the why, I thought I'd discuss the what, so at least you'll have an idea what I'm talking about and how it might work. Cue the screen shot.



This is a shot of the kitchen, which is still a work in progress. The cupboard is to the left, a table is straight ahead, and a locked hatch in the floor is in the back to the right. At the bottom of the screen is the text output window. Here's a close-up:



The box above the text output window is the command entry window. It pops up when you hit the SPACE bar. You can still move the camera around and click on objects while it's open, although all keypresses are sent to the entry window while it's open.

I wanted to design the interface so that people comfortable with IF could play the game almost entirely with text entry, if they so prefer, even though I don't expect that to be the case. The main exception is movement; there are no text commands directly related to movement, such as compass directions, IN/OUT, UP/DOWN, and so on. These are all performed via the typical FPS-style W-A-S-D setup, with the mouse used for camera panning. But aside from that, most other commands can be entered through the command entry window.

The parser was designed to be comparable to other common parsers, like those from Inform or TADS. It can handle things like actions on multiple objects ("Take the food and the keys"), disambiguation ("Which door did you mean, the bedroom door or the locutory door?"), and completion ("What do you want to unlock the hatch with?"), although I suspect the ability to select objects visually will eliminate much of the need for these. Common abbreviations are supported, such as X for examine, G for again, I for inventory, and so on, although these actions can also be performed by pressing the appropriate key, without having to bring up the command entry window. So "I" will bring up the inventory window, without having to hit SPACE-"I"-ENTER.

Speaking of the inventory, it is implemented graphically as well as through text. The common text presentation is preserved for those comfortable with it, but it is also presented as a separate window:



The items in the inventory are selectable with the mouse, which will then allow you to perform actions on them. So, if you click on the keys to select them (as above), and then hit the "X" key, that would be the equivalent of bringing up the command entry window and typing EXAMINE KEYS.

Despite the inclusion of (and emphasis on) a text input interface, point-and-click is provided and is very useful. Clicking on objects to select them results in the object becoming highlighted visually, as with the cupboard door below:



Once an object is selected, it can then be acted upon either through single-key commands (such as X for EXAMINE, or O for OPEN) or through the command entry window. In the case of the latter, the act of selecting an object allows the player to exclude the object from the text command -- it is automatically assumed to be the object acted upon. So in the example above, with the cupboard door selected, the player could just bring up the command window and enter OPEN, which would be interpreted as OPEN CUPBOARD DOOR.

The same applies for commands requiring two objects, such as unlocking the kitchen hatch:



By selecting the lock, the command can be abbreviated to just UNLOCK WITH KEY, and the parser will interpret the command as UNLOCK LOCK WITH KEY. Likewise, if the inventory screen was open and the key was selected, the player could type UNLOCK LOCK, and the parser would interpret that the same way.

As alluded to in the image above, there are other ways to simplify the performance of actions. The middle mouse button (usually a clickable mouse wheel) can be set to perform one of a list of common actions. Scrolling the mouse wheel flips between the different options, which right now are LOOK, TAKE, EXAMINE, and INVENTORY. Each rotation of the wheel is the equivalent of entering the command "SET MIDDLE MOUSE BUTTON TO < action >" in the entry window, so this could also be done directly via text. Then clicking the middle mouse button performs the action. I typically have it set to TAKE, so I just need to click on an object with the left mouse button to select it, followed by the middle mouse button to TAKE it.

The other customizable key is the TAB key. By default this is set to INVENTORY, but it can also be set to one of the commands above as well using the "SET TAB TO < action >" command.

Aside from the middle mouse button mentioned above, the mouse is reserved for selecting objects (left mouse button) and camera panning (right mouse button click and drag).

It's a lot to remember, no question. I think it will be perceived as a barrier by many people, particularly newcomers. But I do think the basics are fairly straightforward. Most of the shortcuts will probably take some time for players to remember and become comfortable with them, but once they do I think players will be surprised how streamlined most commands are, while still allowing for more advanced command input with the entry window -- which itself can be faster than in traditional IF.

Of course, this is still very much a work in progress, so it will undoubtedly change over time. I thought it would be useful to show how I've approached incorporating an IF-like interface into a 3D world, for future discussions as well as to solicit opinions and suggestions. Both are welcome and appreciated.

Catching up with Vespers

Although The Monk's Brew is a new blog, I've been blogging for some time on my progress with Vespers over at GarageGames.com, the makers of the 3D engine I am using (Torque Game Engine). I thought the beginning of this blog would be a good place to collect those initial reports, in case anyone would ever care to go back and review my development process and progress. All new blogs from this point will be posted here on TMB. Here are the links to the blogs, in chronological order:

Chasing Windmills?
11/8/05
In which I first discuss my decision to pursue a hybrid of interactive fiction and a first-person 3D engine.

"Vespers3D"
12/30/05
In which I discuss my initial attempts at creating a text parser within the Torque Game Engine, and my enlistment of Jason Devlin and "Vespers" as the experimental game.

Vespers3D: The Adventure of Text Parsing
3/9/06
I which I discuss some of the challenges of implementing a text parser within a 3D world, partcularly how to deal with objects that don't have physical representation in the 3D environment.

Vespers3D: The Adventure Continues
5/31/06
In which I discuss the implementation of the visual inventory, visual object higlighting, and the horrors of text parsing such as disambiguation and multiple objects.

Vespers3D: Living the Adventure
10/16/06
In which I discuss our choice of company name (Orange River Studio), customizing command inputs, a new opening intro sequence, and the implementation of purely informational verbs such as LOOK, LISTEN, and EXAMINE within a 3D environment.

Vespers3D: Adventuring Along
1/22/07
In which I discuss implementing command completion within the text parser, the introduction of our first NPC (Matteo), and the auditions for our voiceovers.

Vespers3D: Adventures in Cinematics, Part I
4/26/07
In which I discuss how I implemented the cinematic animations in the game using a sequence manager and triggers.

Vespers3D: Adventures in Cinematics, Part II
6/17/07
In which I continue to discuss the implementation of the sequence manager and animation states.

Vespers3D: Adventures with NPCs, Part I
6/30/07
In which I discuss the development of our first NPC, Matteo, from text to concept to animated and voice-acted 3D model.

Vespers3D: Adventures with NPCs, Part II
7/25/07
In which I discuss the development of our second NPC, Constantin, from text to concept to animated and voice-acted 3D model.

Vespers3D: Visibility Issues in 3D
8/6/07
In which I discuss some of the real problems with referencing objects in a 3D world due to complex collisions and collision checking.

Vespers3D: Adventures with NPCs, Part III
9/3/07
In which I discuss the development of our third NPC, Lucca, from text to concept to animated and voice-acted 3D model.

Vespers3D: Adventuring Onward
12/28/07
In which I discuss ongoing issues with animation, the new opening intro sequence and music, and the implementation of the objects in the church.