How Iggy Got His Groove Back

(or, The End of November Vespers Thing)

Good grief, another month come and gone already? November was a crazy month, I have to say. A lot of business travel, including a trip to Atlanta and not one, but two trips to D.C. -- at one point, I was having trouble remembering what city I was in and what day it was. But while you might think that Vespers development would slow as a result, in fact this past month turned out to be incredibly productive. One of the most productive in a long time, actually. We're finally beginning to see the fruits of our transition to new animators and a new animation system, and I'm expecting that this will be the start of a series of very productive months on that front.

In the last update, I expressed hope that during November we would start to have some new animations to plug into the game. We met that goal early on, and by the end of the month I found myself with more animations than I could process. Shawn, our animation lead, has really come through for us, and all of the work he put into the body and facial rigs over the past couple of months has started to pay off in spades.


It's difficult to express just how great it feels to have new animation work to incorporate into the game. I honestly can't remember the last time I had a new character animation sequence ready for importing. The last character we had worked on with respect to animation, prior to turning the work over to students and graduates from our local university, was Ignatius -- and according to the files on my system, that was back in the Fall of 2007. At that time, we had his model rigged and about a half dozen animation sequences created, but that was as far as we got before falling once again into the animation abyss.

The transition from 3ds Max to Maya when the students and graduates came on board was (and continues to be) somewhat painful. Unless you're working with an artist or animator who is already familiar with the eccentricities of the Torque art pipeline, it can take a good chunk of time to get to where each of your models and animations can be exported with some consistency -- and actually work when loaded into the game, as intended. At times, it feels like you're fabricating an intricate house of cards that requires everyting to be balanced just so to produce what you want.

But if you stick with it, and learn a little bit more about the system each time you work with it, you find that you can sometimes hit that sweet spot. That point when your models export, your animation sequences export, they load into the engine and work as planned, and suddenly you find you can just start cranking things out. It's a good feeling, one that I haven't had in over a year now, I guess.

Although I'm sure he's been ready to pull his hair out at times, Shawn has really stuck with it, and I think we've reached the point where we're starting to put a serious dent in the animation to-do list.

Shawn started his work with Ignatius, but since we're also trying to add better lip sync animations to all of the characters, he's had a hand in rigging a number of them, including Matteo, Constantin, Drogo, and Cecilia. In fact, Lucca is the only character model he has not rigged, which I think will be good for consistency. Each of our models now has a similar body and facial rig setup, which should speed up the transition from one character to the next.


By the end of November, Shawn had finished up all of the animation work for Ignatius for Act I of the game, which to me is just a phenomenal achievement. But in addition to that, he also has gone back and reworked all of the animations for Constantin as well, aside from a handful of sequences he has left to finish. I understand he has also started to rework the animations for Matteo as well, and once he is finished with that he will start work on Cecilia. I honestly didn't know if we'd ever get started on Cecilia, but there I was last week putting together her animation list and preparing her audio files. Now we're only a couple weeks away from seeing her in action, too. I hope you sense my excitement.

In the meantime, Lem is continuing his work on Lucca, and now that Drogo is rigged, Josh can finally start work on those animations. I can't wait to see how Drogo will turn out. I'm hoping I'll find out soon.

Probably the best part about this is that the quality of Shawn's work is a nice upgrade from what we had previously. He has really paid considerable attention to the details of body and facial movement, so we're seeing less robotic motion and much more convincing expressions, not to mention some nice lip sync. Some of the gestures and facial expressions he has made are far more engaging than what we saw before, and it really adds considerably to the experience of the game, I think.


My sense is that facial expressions and lip sync are things that are not done with great frequency with the Torque Game Engine, so over the next little while I plan on documenting how we went about doing this in Maya, using Shawn's work with Ignatius as an example. I'll also highlight some of the work he has done on Constantin, which I think is going to look great once I get it all imported into the game. I think it will help show some of the cool things that are possible with Torque's animation system which, while quirky, is quite powerful and flexible.

Meanwhile, I've got a crapload of Ignatius and Constantin animations I have to get to work on. And to think, I thought I might never have that problem again.

Tale of Tales Goodies

Tale of Tales is the Belgian group led by Auriea Harvey and Michaël Samyn that brought us the thought-provoking poetic "art game" (for lack of a better term, I suppose) The Graveyard. It was an intriguing piece that generated a lot of discussion around the tubes, much of which was unfortunately negative because many people didn't quite get that it doesn't fit the traditional definition of "game". It was also created with the Unity engine, a very cool 3D game engine/development tool that runs primarily on Macs, and which I came very close to using for Vespers. In any case, I thought it was a worthwhile experiment and I have a lot of respect for what these folks are trying to do.

Of note, Gamasutra has just posted their postmortem on The Graveyard, which I think is a great read. They posted it on their web site a while back, but it's great to see a site like Gamasutra picking it up. There's a lot of good information in it, including the tools they used, their funding sources, sales figures, and their responses to the crtiques. This was the postmortem that achieved some recognition for noting that their sales conversion rate was a "disastrous" 0.34% -- and also that a large percentage of their sales were to Mac users, which was somewhat unexpected. They also include some good information about their character animator (don't get me started), music composer, and sound designer, which is very cool and something that I have been trying to do as well for my project.

ToT also produced a hybrid multiplayer online game/screensave called "The Endless Forest", although I haven't tried it myself since it's Windows-only. They had another fascinating project under development a while back called "8", but development was halted a couple of years ago due to funding issues and it's not clear from their forums if they will pick it up again. My guess is that they will if their current project succeeds and they can generate some financial interest in it. I hope so, because it looks really fascinating.


Speaking of which, their current project, for those of you who haven't heard, is called "The Path". It's billed as a single-player horror game with a unique form of gameplay, where "every interaction in the game expresses an aspect of the narrative." Now that's something I can get into. It looks to have some basis in The Little Red Riding Hood tale, but seems to feature multiple characters, such as Scarlet, Rose, and Carmen. It has a very dark tone and looks to be a fascinating piece, although it looks like it will be Windows-only again. Disappointing, since that means they're not using Unity again -- I believe, from their postmortem above, that they are using Quest3D instead. I'll figure something out.

The Tale of Tales folks are taking a very open approach to their development, and their web site features a lot of goodies including galleries, wallpapers, and their development blog, which has a load of information on their production process. They're in the alpha testing phase right now, and they include short snippets about each of the testers and their experience with the game, which is a nice touch. I'll probably follow their example in this respect.

Recently, they came out with some new screenshots, which look fantastic. The artwork for this piece is really outstanding, dark and stylish which reminds me a bit of American McGee's Alice to some extent. I don't know much about the gameplay or how the interactions will relate to the narrative, but it looks very promising and I'm really looking forward to checking it out when it's available. I'll just need to find me a Windows machine.

IFComp08: The Results Are In

The voting ended yesterday, and the results have been tallied. The winner of this year's IFComp is Violet, by Jeremy Freese - an excellent piece which I thought was well-constructed, well-written, and entertaining. The top ten finishers in the Comp are as follows:

1. Violet


2. Nightfall


3. Everybody Dies


4. Afflicted


5. Piracy 2.0


6. Snack Time!


7. Opening Night


8. April in Paris


9. A Date With Death


10. Berrost's Challenge

Overall, I thought the competition had some good entries -- some really creative ones like Violet and Buried in Shoes, and some traditional ones with good puzzles and engaging writing like Nightfall, Piracy 2.0, and April in Paris. I also enjoyed some of the more lighthearted entries such as Recess At Last and Snack Time! I think there were a reasonable number of solid entries -- I would say somewhere around a quarter to a third of all entries, which is generally not bad for a Comp, I think.

In case anyone is interested, I thought I'd post some final results and thoughts about the Capture Scores I posted this year.

Here is the overall breakdown of this year's entries by score, where 1 is the best (a game I would definitely go on to play) and 4 is the worst (a game that did not seem to be worth the effort):


Note that 4 of the 35 games were Windows-only, and were not included in the tally. I was expecting that most games would be either a 2 or 3, but I wasn't expecting more games to score a 1 than a 2. In fact, more than half of the 31 games scored 2 or better. I did end up playing the nine top-scoring games, but only a handful of those that scored 2. Was it a worthwhile strategy? Interesting question.

Of the 9 games with a capture score of 1, 6 finished in the top 9 in the official scoring (Violet, Nightfall, Afflicted, Snack Time!, April in Paris, and A Date With Death). The other three finished 13th, 15th, and 17th.

There were 7 games with a capture score of 2, making a total of 16 games with a score of 1 or 2. Of those 16 games, 4 did not finish in the top 16 in official scoring. So a capture score of 1 or 2 essentially picked out 12 of the top 16 games, which I guess is not a bad system for quickly identifying some of the better games to focus on for the Comp, at least if you're like me and don't have enough time to play all of them.

My top five rankings in the competition were:

1. Violet


2. Nightfall


3. April in Paris


4. Piracy 2.0


5. Buried in Shoes

...which are the games that finished 1st, 2nd, 8th, 5th, and 13th in the official scoring. Everybody Dies (3rd in the official scoring) was one of the games that I gave a capture score of 2, but which I never got around to playing again, so I'll probably go back and give that one some more attention.

A few other capture score notes: Opening Night (7th) and Berrost's Challenge (10th) finished in the top 10, but both had a capture score of 3, so I may go back and give those another try...I gave Dracula's Underground Crypt a capture score of 4 (not good) but it managed to finish a respectable 20th...there were four Windows-only games in the Comp that I did not play because of the platform restriction; needless to say, not much was missed, as the four games finished 26th, 28th, 29th, and 32nd.

Congratulations again to Jeremy Freese and Violet, and thanks to all of the authors who submitted entries this year.

IFComp: Final Capture

With the IFComp voting period about to end, I'll now finish up with the last batch of entries. Here once again I present my initial impressions of each game's opening (introduction, "About" screens, and the first location or moves), summarized by the Capture Score from 1 (intriguing; a definite play) to 4 (dreadful and forgettable). Just a reminder, no spoilers here, just early impressions.

The final games covered here include "Buried in Shoes", "A Martian Odyssey", and "Freedom".

"Buried in Shoes", by Kazuki Mishima

As far as I know, Mishima has written only one IF game prior to this Comp, the short but poetic "Somewhere." I don't know quite how successful it was as an "interactive poem", particularly given how short it was, but I appreciated the novelty and the effort put into it. "Buried in Shoes," his new piece, bears some resemblance to his previous work, and I'm intrigued to see what Mishima might do with a longer form.

The ABOUT screen gives abundant information about the game, including a nice paragraph about the significance of the shoes. Having visited the Holocaust museum in Washington previously, I can relate to the impact the displays can have, and I'm interested to see what Mishima does with this content. Like "Somewhere," this game adopts a fairly minimalist style, which I think works well here too. In his comments for his previous game, Mishima said, "I think interactive fiction can be very poetic," and "Buried in Shoes" appears to be able to continue that thought process.

Capture Score: 1. Looks like an interesting experiment.

"A Martian Odyssey", by Horatio

This game is apparently accompanied by ambient music, but my interpreter (Zoom 1.1.2 for Mac, which is the latest version) doesn't seem to support it. I don't know if that will greatly impact my initial impression of the game, though; I guess it depends on the quality of the music I'm missing. Not much additional information accompanies this game; the CREDITS command notes that it is based on the short story by Stanley G. Weinbaum (don't know it myself), and the HELP command just gives a fairly terse list of valid commands.

The initial location description is about as bare as you can get, and it's not lost on me that two of the characters beginning the game on Mars -- myself and one other person -- are named Dick and Putz. Wandering around reveals more sparsely described locations and a fairly narrow narrative path. Perhaps the descriptions are intended to be as barren as the plains of Mars, but I can't say that does much to draw me in to play more. It's not even clear from the start that my character is moving around within a small space ship. Alas, the odyssey does not last long.

Capture Score: 3. Maybe the music would have helped after all.

"Freedom", by Anonymous

The author of this game wishes to remain anonymous, as it is a piece intended to replicate the "worst case scenario" of a person suffering from social anxiety disorder and, as such, is likely drawn from personal experience. The HELP screen informs me that I should probably play the game first before knowing this information from the ABOUT screen (to avoid preconceptions), but since I typically try ABOUT at the start of each game, I missed that opportunity.

Although I get the sense this piece is probably attempting to do something quite different from the typical IF simulation, I'm still struck by the distinct lack of simulation in the initial locations. Had I not read the ABOUT screen, I'm sure this would be even more jolting. My apartment has multiple rooms and objects, almost none of which are implemented in any rudimentary sense. Other locations have multiple exits, only one of which is actually usable, and it's clear I'm being led down a very narrow path. Although I think the subject matter might make for a fascinating piece, the initial implementation just leaves me notably underwhelmed. I may come back to it later to see where it tries to go -- or, perhaps more likely, I'll just wait and read the various Comp evaluations.

Capture Score: 3. Perhaps could benefit from more refinement.

And that should do it for my "capture score" evaluation of this year's IFComp games. Official voting comes to an end on Saturday, at which time I'll summarize the scores, my thoughts about the evaluation process, and put things in a bit of perspective. Later, I'll explore how the capture scores compare with the final grades and rankings of the games.

IFComp: Slow Capture

Only seven games left to go, and three days left in the Comp. So time to start wrapping things up with the penultimate batch of entries, as I review my initial impressions of each game's opening (introduction, "About" screens, and the first location), summarized by the Capture Score from 1 (intriguing; a definite play) to 4 (dreadful and forgettable). Just a reminder, no spoilers here, just early impressions.

Games covered here include "The Hall of the Fount of Artois", "Riverside", "Magic", and "The Lucubrator".

"The Hall of the Fount of Artois", by Simon

The last of four Windows-only games in the IFComp. I'm a Mac user, so I'll have to find out after the final Comp votes are tallied to see if this is unfortunate.

Capture Score: 4. Fortunately, only four of these this year.

"Riverside", by Jeremy Crockett and Victor Janmey

This is another game that comes without an information file, ABOUT screen, or any HINT or HELP commands, but the introduction and opening scene are written with enough skill and style that I can overlook this. It's a game with a somber tone; at the start, a close friend has been murdered, and we begin at the funeral. Where it goes from there is not clear, but the story is set up well and the atmosphere is believable.

Interested in getting more feel for the game, I played a few moves and realized that there would be more to the story, one that involved a potential mystery around my friend's death. I thought this was a good hook into the developing narrative, at least from a technical standpoint, although I thought the writing stumbled a bit at this point, and a few typos and/or misspellings detracted a small bit from the impact. Still, it looks like a good effort.

Capture Score: 2. Drew me in enough to generate some interest.

"Magic", by Geoff Fortytwo

One of only two TADS3 games in this year's Comp, this game is "a story about the dangers that magicians can face." It starts with a scene of me performing a magic trick in front of a dozen uninterested children; I thought at first it was written fairly well, but when it ended with me running away crying and giving up on magic, I was a bit jolted, particularly as I then wake the next morning in a dumpster. From there, it appears you can explore the neighborhood a bit, which includes the magic shop and some nearby houses.

Overall, it appears to be a moderately interesting game. The writing is generally adequate, with only a few typos, but the writing is awkward in places and the descriptions are not particularly engaging. The description of the magic spell discovered early on is an attempt at humor (I think) with a reference to Paris Hilton and trash, but it comes across as neither creative nor funny. There doesn't appear to be a solid hook after a few moves, although I admit I'm a little curious to see where the story will eventually go. But only a little curious.

Capture Score: 3. Could use a bit more refinement and a better hook.

"The Lucubrator", by Rick Dague

Dague has written or contributed to a number of IF games in the past, although I don't think I've played any of them. His latest game is a bit of an enigma; it starts with my character lying prone on an autopsy table, held down by restraints. There is a sharp cleaver nearby, but the restraints prevent me from doing much with my hands. After a few turns, I was honestly stumped, and actually had to resort to the walkthough; without mentioning the solution, I have to say I don't think it would ever have come to me considering the way that the restraints otherwise preventing me from doing anything.

I was more frustrated than challenged by this one, even in just the opening of the game. The writing is decent, but dotted in places by awkward sentence structure, and there are fairly common actions and objects that are not defined -- for instance, YELL is allowed, but TALK is not recognized. It's fairly clear within a few turns what is happening at the opening of the story, but my overall impression is that it could use a bit more work and some polish.

Capture Score: 3. An interesting idea hampered by its design and structure.

Almost done...

Feedback For Better IF Parsing

Over on Twenty Sided, Shamus Young posted a blog today on, of all things, interactive fiction. Seems he's been playing "Phantom of the Arcade" lately, an Inform-based text adventure written recently by Susan Arendt, his editor at The Escapist, and made available online. This spurred him to ponder the familiar issues and frustrations related to the IF parser, and particularly how the parser handles unknown or unacceptable input. "Feedback itself," he states, "is a reward" -- feedback that shows that, even though the command entered is invalid, the author and/or parser has anticipated it enough to provide useful information rather than a generic "I beg your pardon?" response.

One idea he came up with for this involves modifying the IF environment (particularly one that is web-based) to create what he calls a "feedback parser":

To do this you’d just need a bit of functionality added to the parser: Whenever it encounters something it doesn’t understand, it needs to submit something to a database on the website with the subject, verb, and room. (And maybe a couple of other tidbits for housekeeping purposes.) Within a few hours of going live, the author should have a very clear picture of where the rough spots in the game are (what rooms had the most dud entries) and what the commonly attempted player actions are in those rooms. This would be much smoother and more seamless than simple playtesting, and would include the input of all players instead of just a handful of dedicated testers. It would make the designer better at their job, and help focus effort onto the most likely responses.

I had a long, drawn out response to this on his blog, which I thought might be useful to reproduce here as well for discussion. Shamus touches upon one of the more interesting arguments in the IF world, one that has been bantered around for some time: Do we need a better IF parser?

I actually started writing a blog entry with this title a while back, but never finished it. I was thinking more along the lines of a parser than can recognize a broader range of input. The jist of the discussion was going to be No, we don't -- you can argue that the tools are already out there, it just requires more work and dedication on the part of the author to have a system that is better able to handle unrecognized or unacceptable input and provide useful feedback, as Shamus suggests. The issue is not necessarily that we need parsers that can recognize and handle more players actions, but ones that can recognize and gracefully handle more unacceptable input.

Players usually cite the parser as the main problem with IF, as Shamus describes -- players want to try different things, but when the parser just responds with a generic "I don't know what you mean," players get turned off, particularly when this happens over and over. Players get frustrated when the parser doesn't provide sufficient feedback to understand why a particular action didn't work or was not understood. They also get frustrated when the parser doesn't recognize input that it probably should understand (like when players refer to an item described in the narrative, but which is not implemented as an object in the game world). Players are also frustrated when the parser doesn't accept a wide range of input, such as when they try to use adverbs (quickly, carefully, angrily, etc).

Some of these things are issues that the author needs to address, and the community has discussed for some time about how adequate testing is needed to uncover most of these things. Obviously, there's only so much testing one can do -- and often authors use other IF authors or veteran IF players for their testing, which doesn't always reveal some of the problems that might come up when less advanced players try the game. Still, after playing enough games you can generally spot the ones that have undergone thorough testing and those that haven't. Many IF games and engines can capture the full text transcript of a game from start to finish, which the author can then review to see what players did (or tried to do), and learn from that. A good example is Aaron Reed, whose 2005 IF game "Whom the Telling Changed" was a finalist at SlamDance in Park City. He saved all of the transcripts from when the game was on display at the competition, and eventually compiled, analyzed, and published the data on his web site. It was a very revealing look at how many (mostly newbie) players approached IF.

Some of the other issues mentioned above, though, are less author-dependent, but there are still things that authors can do to prepare for such things. The Inform system, for instance, supports a huge library of extensions which can make the parser work better in some cases -- particularly for newbies who don't necessarily understand how parsers typically work. The aforementioned Aaron Reed, for instance, has written a customizable Inform extension called "Smarter Parser", which allows the parser to understand a broader range of input and can direct newer players towards proper parser syntax. There are also extensions which can perform basic typo correction, so that players don't have to re-type commands just because of a simple mistype. And there are plenty of others.

Part of the problem with IF parsers is that they need to operate under a defined set of rules, and it's important for player to learn those rules. But I think it's a valid argument to say that it's largely the author's responsibility to help teach the player those rules (as well as the rules of that particular game world). Those rules are taught through sophisticated and comprehensive error trapping, so when the player tries to do something that breaks either the parser rules or the game world rules, the player is given a good explanation of why he or she cannot perform the desired action. If that happens, players are generally more accepting and willing to continue; in the absence of that, they are more likely to just say "screw it" and get back to blowing things up in an FPS.

This is not to say the solution Shamus describes is not a useful idea -- I think it's a great idea, in fact. What it represents is just a new way of expanding the "test base" for a game in a dynamic fashion. It hasn't been done up to this point probably because playing IF within web browsers is still a very new advance for IF. As the technology develops (there are still a number of issues to resolve), I suspect we will definitely see more solutions like this.

I think the handling of unrecognized input would have to be handled a certain way, because the list of errors could potentially be huge. I think what would probably be more useful is a system that just saves every game transcript to a database and sends it to the author, and if there is any unrecognized input, it can be (for instance) highlighted in red so authors can spot it easily. That way, the author will have the full context of the error on display, without having to figure out when, where, and why it happened.

But essentially, I think what Shamus is talking about is a different, more comprehensive approach to (continually) testing and refining the games that we make. Which is definitely a good idea worth pursuing.

The End of October Vespers Thing

Wow, October came and went in a hurry. Halloween and the ongoing IFComp took up a lot of my time toward the end of the month, which threw me off by a few days. So here, at the start of November, is an update on Vespers over the past month.

On the modelling front, N.R. and I spent much of the month improving the performance of the game with some creative workarounds for the problem we have had with portals in Torque. Portalization, for those of you unfamiliar, is a method used by people who model interior structures for Torque (such as buildings) to split up these models into "zones" in order to reduce rendering overhead. So basically, if a building has different sections or floors, for instance, you split it up into zones using portals placed over any of the visible openings into to that zone (such as a doorway or window). The Torque engine then uses the portals to determine when it should render the geometry and any objects within that zone -- if the player can "see" any of the portals to a zone, the engine will render everything inside. If not, all of those polygons can be skipped, which can significantly improve rendering (and game) speed in most cases.

The problem is that it can be very tricky to get portals working in Torque. The interior model must be completely sealed everywhere for portals to work -- there cannot be any leaks of any kind, or the zones will not be set up. Portals are created in the modelling program using special "brushes", and there are a whole series of rules you must follow when using these brushes, or the zones will not be set up. Portals must also be square or rectangular, which presents problems for some of our arched windows.

As an example of how fussy portals can be, there is a page on the Torque Developer Network devoted to creating portals, which has a section titled "Unproven Findings About Portals". Here are actual entries from that section of what modellers are up against:

• Sometimes thicker portals experience problems.


• Sometimes portals can be made that are touching more than 4 other brushes.


• Sometimes portals will not work no mater what; and sometimes a portal works even when you try to build it wrong.

Encouraging stuff, especially when there are so many issues that are qualified with "sometimes" but without any additional information on when one might encounter those situations. In any case, it's likely that the interior models in Vespers are too large and complex for portals to work effectively, and it would take far too much effort to get them working at this point anyway.

So, we decided to try another route to reach the same destination.

As mentioned, the interior models in Vespers, such as the church, dormitory, refectory, and entrance hall, are fairly complex models with a good deal of geometry used to create detail structures, such as the wood beams along the walls and ceiling. Most of the time, however, the player is only able to see a small portion of all of this geometry. Take the screenshot below, where the player is in the main entrance hall, looking out towards the cloister:


Here is a layout of the monastery, with the arrow showing where the player is located and which direction he is facing:


All of those structures in the layout are being rendered by the engine -- the church, refectory, dormitory, kitchen, and so on -- and yet only a small fraction are actually visible from this position. That's a lot of unnecessary rendering. Everything inside of the church, all of the different rooms in the dormitory, even the kitchen and calefactory -- all of these are there, and the engine has to deal with every detail of each one, even though most don't need to be drawn on screen. So if we can come up with a way of not rendering all of these things, then performance should improve dramatically.

The solution we came up with is to create our own set of "zones" -- areas that define which buildings and objects should be rendered, and which should not -- using the game's general room structure as the guide. So for instance, we can define a "Bedroom Zone" such that, when the player is in the Abbot's bedroom, we know to render the bedroom, main entrance hall, and locutory (and all of the objects therein), but we don't have to bother with the kitchen, calefactory, refectory, church, and so on, or any of the objects within those structures. We define these zones and their contents in script, and when the player moves from one room location to another, the triggers at these locations tell the engine to check the new zone and render only what needs to be rendered. The result is similar to Torque's portal system, but in fact we end up with a bit more flexibility.

Sometimes, however, we only need to render part of a building. For instance, when the player is in the main entrance hall, we need to render the refectory -- but only the outside of the refectory, since the player shouldn't be able to actually see anything inside the refectory. Same for the church and dormitory. So to do this, we created multiple different versions of each building -- one with all of the interior details, and additional ones with few or no details inside -- and tell the engine which one to render at each location in the game. We do this by specifying each model version as one "level of detail" (or LOD). LOD is normally used by the engine to draw lower-detail versions of models as they get further and further away from the player, also reducing rendering overhead. But in this case, we use LOD here in a slightly different fashion. Since the engine allows us to "force" the display of a specific LOD when we want, we use this to our advantage to display the LOD version specified by the zone.

The results so far have been mostly good.

In general, we have been able to increase frame rates significantly. Whereas before we were seeing a good deal of "lag" on older machines in many game locations, now most lag issues are completely gone from these older machines, except in some of the most intense rendering areas (such as the cloister) where there is still some optimization to be done. On more recent machines, frame rates are now excellent, and that makes me happy. But all is not perfect.

The problem is that we've now run into the occasional "pause." There are some areas in the game where, upon moving into a new room location, the number of models (buildings, scenery objects, lights, and game objects) being toggled on or off is quite large, causing the game to noticeably hesitate for a moment while it performs all of these actions. Although I'm really only noticing this on lower-end machines, it can be pretty jarring, and is definitely not the kind of thing I want to see.

There are still some things I can look into to help the situation, but overall I'm pretty happy with the results so far.

Aside from that, we've spent some time working on additional environmental decorations, such as piles of scattered dead leaves to distribute around the monastery, including a few versions with leaves that animate with a light breeze blowing through them. Should provide a nice little measure of ambience to the scene.

There have also been some advances on the NPC animation front, although I'll wait to report more the next time. Most of our characters have been re-rigged in Maya now, including facial bone structures to provide expressions and lip sync, but since there's not much to show just yet I'll save it for another blog describing the whole setup process. I'm pretty happy with where the character models are at right now, and hopefully over the course of November we should start having some animations to plug into the game again. Should be fun to be doing that again.

Until next time...

IFComp: Capture Time

It's November, so the deadline for judging this year's IFComp is closing in fast. Time to move on with the next batch of entries, as I review my initial impressions of each game's opening (introduction, "About" screens, and the first location), summarized by the Capture Score from 1 (intriguing; a definite play) to 4 (dreadful and forgettable). Just a reminder, no spoilers here, just early impressions.

Games covered here include "Project Delta", "Escape from the Underworld", "Opening Night", "Afflicted", and "Everybody Dies".


"Project Delta", by Emilian Kowalewski

Another Windows-only game. I can't tell if this is a shame or not. I guess I'll find out after the final Comp votes are tallied.

Capture Score: 4. The third of four Windows-only games in the Comp.

"Escape from the Underworld", by Karl Beecher

This one comes with hints and walkthrough files, but without any background information or an ABOUT command. I generally like to have even a small amount of background info, whether it's about the inspiration for the game, an acknowledgement of the authoring system, or a shout out to the beta testers. There were beta testers, right? I'll have to make do.

Escape has a mildly entertaining but thin premise: I play a demon in the Underworld who, unhappy with his eternal task of torturing evil souls and seeking to better himself, must escape by making my way up to the "top floor." It is written in a humorous style, although the humor only partially succeeds. It comes across as fairly well put together, without any notable errors, but it seems to lack much polish, particularly in the room and item descriptions. I could probably play a game like this if the writing had a bit more style, but as it is it's a bit bland and I'm just not drawn in enough.

Capture Score: 3. A decent idea that faltered in the implementation.

"Opening Night", by David Batterham

As the ABOUT screen notes, this is a game that focuses on story rather than puzzles, which is generally my preference. In this one, my character has saved up a month's pay to purchase a ticket to the opening night performance of my idol, Miranda Lily, on Broadway. Starting out just outside the theater, it appears that at least part of the goal is to make it inside, as the doorman seems intent on upholding the theater's strict dress code. I'm told it will probably not be difficult to solve this game's puzzles, so the story must carry the day here.

Although it appears to be well written, I can't say that this particular narrative captures my imagination right away. There might be considerably more beyond the opening, but I find it more difficult to muster up the desire to play this one than a number of other Comp games. It's probably just a function of the premise more than anything else. I'll be interested to see if my initial impression differs from the final voting.

Capture Score: 3. Just not enough up front to grab me.

"Afflicted", by Doug Egan

Egan is the author of "Pascal's Wager", the winner of the 2008 Spring Thing (although I haven't played it yet). Interestingly, Egan notes it took four years to complete that game using Inform 6, while it took only four months to complete "Afflicted" in Inform 7. His new game is intended to be enjoyed by IF newcomers and veterans alike -- a worthy goal, but one that is sometimes difficult to pull off. Most common verbs are employed, although in the ABOUT screen I'm told that there is one new verb, NOTE, as well as an extra emphasis on the SMELL command.

The premise is that my character's job as city sanitarian is to complete health and safety inspections of all restaurants in my district, and I start in a place called "Nikolai's Bar and Grill" in a questionable part of town. The place is closed, the front door is locked, and nobody is close enough to hear me knocking. The first puzzle would appear to be getting inside; the rest appears to involve receiving a sanitation rating for the work that I do, although it's not clear how points are awarded.

My impression is that there is probably a lot you could do with this premise. I like the decrepit setting, and the writing is good without being silly, lighthearted, or too cliché. I'm interested to see where this game decides to go after this introduction, and it compares well with many of the other entries in this year's Comp.

Capture Score: 1. I want to see if my impression is correct.

"Everybody Dies", by Jim Munroe

Munroe previously wrote the game "Punk Points", which was entered in the 2000 IF Comp. Although I haven't played it, a review of this game from 2001 starts with: "You're a teenager trying to demonstrate to yourself and to your peers how angry and rebellious you are." This would also probably describe the opening of Munroe's new game, "Everybody Dies", which starts with a young, angry, vulgar kid who works at a supermarket bagging groceries and collecting shopping carts. There is no ABOUT screen, but a CREDITS screen acknowledges an impressively large group of beta testers. The HELP screen provides mostly generic help, although I'm informed that dying is "a part of life, and for most of the game unavoidable."

There's little direction when the game starts, although it seems that I have to retrieve a shopping cart before returning to the store. It's hard to know where this game is leading -- except perhaps for the title -- but with the only visible shopping cart submerged in the frigid river below, I'm a bit intrigued. The writing and construction appear sound, with a fairly convincing characterization of an angry youth.

Capture Score: 2. Would be interested in coming back to this one.

Only seven more to go...