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.
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.
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.
Enjoyed this article? Subscribe to The Monk's Brew RSS feed.
Oh, so now you’re thinking in portals.
Yes, “portals” in the sense of defining rendering zones in order to reduce the amount of rendering overhead for the engine (in case you were thinking of another type of portal).
The monastery buildings have a lot of geometric detail, particularly in the interiors, so anything we can do to reduce overhead is a bonus.
Nah, it was an, apparently, failed attempt at humor.
Nonetheless, do you have any system specs for the current version?
Sorry ’bout that. I was wondering, but it was hard to tell.
As for specs, I can’t say much other than what it currently runs on. Most dev is on a G5 Mac desktop (dual 2GHz) with an ATI Radeon X800 card, and it can get a bit sluggish at times. On the other hand, it runs well on a Mac Intel laptop (2.16GHz core duo) with an ATI Radeon X1600 card, under both OS X and Win XP.