Vespers3D: The End of June Vespers Thing

Hard to believe June has completely come and gone already. We're now halfway through 2009. To be honest, by this point I was hoping for more with this project -- a completed Vespers demo, more frequent blogs, maybe my own television series. Really, you'd think by now I'd know better than that, since I seem to say the same thing about every six months. I'm not that bothered, though. Earlier this month the wife and I were having dinner with some friends when the topic of the neverending game came up, and one of them was struck by how much passion I seemed to have for the project, having stuck with it so persistently for so long. She understood and acknowledged that it must be more about the process than the product. Although I knew this already, it still had an impact hearing it from someone else. It was nice.

Vespers continues to march inexorably toward its inevitable, yet completely unforeseeable, release.

Most development now is proceeding on three fronts: models, animations, and the vast pile of miscellaneous extras such as bug fixes, parser refinement, a web site, company logo, and so on.

As far as the models are concerned, we've advanced beyond the basic models needed for Day One of the game and are now working on the good stuff that isn't seen until Day Two and beyond. Since the planned demo is to contain action only from Day One, that means we're really now working on material for the final release. I find this exciting, although mixed with some unease since it means I have to actually finish the demo and get it out there or else nobody will ever see this new material.

It also means I have to tread a bit lightly, since I am now at risk of giving away spoilers.

The most interesting model work for Day Two so far has been in the infirmary and the stables, which are really starting to come together. The infirmary work by N.R. is especially nice. I wish I could show it all put together, but I'm not quite there yet. It's too interesting to pass on, though, so I can at least offer a glimpse of one of his updated bed textures. His texture work is really quite excellent.


The new bed textures portend ominous things.
The stables are also looking fantastic, although there is still a bit of detail work to do on it, and we don't have any horse models ready yet. But I do think N.R. did some amazing work on the damaged stall doors and the hay, and I think it nicely sets the scene for the action that occurs there on Day Two.



The nearly complete stables.
A good chunk of my life disappeared while I designed the outer wall of the grounds and placed every last section of the wall, which was incredibly tedious and required constant updating of the terrain in order to keep things as level as possible. I'm pretty happy with the end result, but I did notice that the presence of the wall is affecting performance on older machines. I wasn't expecting this, since the wall is comprised of small, lightweight objects that Torque calls TSStatic objects, which are designed to be placed in relatively large numbers without greatly impacting frame rates. But it seems that, with the large number of wall sections and the vast number of other TSStatic objects in the game (including all decorations, like straw and leaves), performance on older, slower machines is starting to take a hit.


A shot of only a portion of the outer wall.
I'm not extremely concerned, though, since I've come up with a relatively simple and straightforward solution similar to what I've done with other, more important objects in the game (the ShapeBase objects, such as the beds, desk, chairs, and so on). More on that in another post.

Finally, there's the graveyard. It plays a very small role in the game, but I wanted to make sure we had a good representation of it, and I think N.R. did a great job with the grave markers. I haven't yet had the time to drop them in their proper places in the game, but I thought it would be worth showing off a bit more of N.R.'s work here.


Gravestones and impromptu grave markers.
Character animation work, as always, continues to be a challenge. Dave Cornelson, he of Textfyre and the return of commercial interactive fiction, had an interesting and relevant blog recently about how difficult it is to find and keep a good artist; seems he went through several over the years during development of his just-released game. I share his frustration. I'm still working with the same set of local University students, but some are too busy with classwork, while others are too busy with life. Work proceeds in spurts, separated by lengthy droughts. We've been in a bit of a drought the past couple of months.

Nevertheless, things do continue to move forward. Drogo, one of the more interesting and challenging characters in the game, is all but finished for Act I. I had been looking forward to implementing him for a long time, and it's great to finally see him in action. I'll introduce him in a separate post.


Drogo pondering what to say.
I still have a lot of work left to do on Constantin, Lucca, and Matteo to bring their animations and sound up to date, so there is certainly plenty of scut work for me to spend my hours (upon hours) on. But once that work is done, the only character left is Cecilia. Oh, Cecilia.

She's going to be a major challenge. We already have some of her animations worked out, but putting her together is going to be quite the experience, since the player interacts with her very differently than with the other characters. There are so many more possibilities with her, so many more "unusual" situations or actions. She is, in many ways, a series of "exceptions to the rule" of NPC interaction, at least with respect to the other NPCs. I'll report more on her as we go, although again it will be a bit tough to avoid spoilery material.

Then there's the miscellany. I spent a good deal of time fixing the kitchen cupboards so that the opening and closing of doors appropriately impacted the SEARCH command -- in other words, you should only be able to see items inside cupboard doors that are open, but not ones that are closed. I also spent some time revising the code that implements supporters, so that various inventory objects can be placed on top of other objects (such as a bed). The whole issue of supporters (and containers, for that matter) is another one of those features that is relatively straightforward in text, not quite so much in graphics. That will be the topic of a future post.


Bed, as supporter.
The endless revision and refinement of the parser continues as well. One of the big problems with working with the parser code is that most of it was written a couple of years ago, and my impression of it is that many parts seem to be held together with Elmer's glue and a little duct tape. Most of it works the way I want it to, but there are always a few nagging issues that haven't yet been resolved, and going back to the code is a risky proposition. Although I've commented the code profusely, there are still many areas where I have the parser doing things that maybe don't quite seem right. Are those bugs that I just failed to previously identify? Or are there good reasons for the code and I just forgot to comment on why I chose that approach? Not to mention that going back and making even small changes could trigger a whole chain of downstream errors that I may or may not catch.

One good example is the GIVE command. You can give items to NPCs if you choose, but you can spell that out two different but equivalent ways: GIVE THE KEYS TO DROGO, or GIVE DROGO THE KEYS. The first construct is easier to deal with, since the preposition (TO) nicely separates the two objects (THE KEYS and DROGO). Thus, the parser has an easier time distinguishing the direct object from the indirect object. In the second construct, this is more difficult, particularly since one of the first actions of the parser is to remove definite articles (THE). So the phrase that is parsed becomes GIVE DROGO KEYS, and the parser sees that as a verb followed by a single token (similar to an adjective-noun combination, such as GOLD KEYS). At this point, the parser would have no idea what the DROGO KEYS are, so it would deliver a mostly unhelpful error message, such as "You see no such object."

Going back and modifying the parser code to better handle this type of construct will require a bit of work, and I cannot possibly predict what it will do to the rest of the parser's behavior. Just one of those things I'll have to dive into, hope for the best, and test the crap out of it.

We've also been spending a good deal of time on more public concerns, such as an official web site for the company and the game. We've decided to go with Joomla as our content management system, and so far I'm fairly happy with the system. The site should be up and running soon. One of the issues is figuring out how to incorporate my external (Blogger) blog with the new site, since Joomla and Blogger don't play well together. I may end up converting it to Wordpress and then integrating it with Joomla, since it's relatively easy to convert from Blogger to Wordpress. I'll have to see. If anyone has any particular advice on that, I'd love to hear it.

A new company logo is also on the way (as you might see below), and I'm pretty happy with where it's going. More on that to come, hopefully very soon.

That's all for now...on to July.