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 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.
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.
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.
Character animation work, as always, continues to be a challenge. Dave Cornelson, he of Textfyre and the return of commercial interactive fiction (more on that another time), 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.
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.
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 still 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 this blog with the new site, since Joomla and Blogger don’t play well together. I may end up converting this blog 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, 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.
Enjoyed this article? Subscribe to The Monk's Brew RSS feed.
It doesn't seem to long, at least from my perspective, and from outside. You see I've spent around 1 to 2 years to complete a brief game of Interactive Fiction, and that it's only text. An usual feeling when making art is: I've spent 12 months on something that can be completed in less than 3 hours. This is something that I commented with Paul O'Brian so long ago about his series of Earth and Sky: a lot of people commented that the third instance was too short, and Paul told me: ey! I spent one (or two, I don't remember) years to make the game, don't tell me it is too short (more or less, I'm paraphrasing).
I can't remember how many months you take on Vespers, or I can't remember how many time has pass from the release of the pilot of Frayed Knights, but for me, for a graphical 3D ambitious game, from 1 to 5 years of development is quite normal/desirable. More than 5 years… tsk, tsk, it is more kind of waste of time, or lack of time, or lack of resources. (Blue Lacuna was build on 5 years :P, man, that it is time, for a text game).
Talking about the bed as a supporter… I'm thinking that it could be a good idea to put the location of the hot spots as random. This could give you a more natural feeling of the objects lying on the bed, because now they feel like making a parade.
Talking about the parser and the "reverse actions". Why don't you copy the Inform 6 model, or TADS3 one? If I remember well in the I6 grammar you could specify a kind of grammar as the reverse of an action, so you could say something like this:
!Better than that! Here is the original code for the I6 grammar for the verb Give:
Verb 'give' 'feed' 'offer' 'pay'
* held 'to' creature -> Give
* creature held -> Give reverse
* 'over' held 'to' creature -> Give;
As you can see the inform parser is potent enough to understand that in the phrase:
>give Drogo the keys
"Drogo" is an object, so there's no need of further association with the following words, so it can look up in the next token for the other objects "the keys" (I think parsers usually removes already matched words and continue parsing the next tokens). What I'm trying to explain is… if Inform does it, you can! Just copy it! Copy the greatest, don't reinvent the wheel. You have plenty of design documents about parsers for I6, for I7 and for TADS. And you have the source code as well, so what are you waiting for?
Note the "reverse" attribute in the grammar, that means that the action is programmed to work for
GIVE object TO pnj
So with the phrase GIVE pnj object we only need to reverse the behaviour. That it is the idea, one kind of action, different grammars to say it.
Hope this helps.
Regards, Ruber (aka Urbatain)
It may not seem like a long time, but it really has been. If you think more than 5 years is too many, then I need to pick up the pace because it won't be much longer before I'm there!
For supporters, making the hot spots random can be a problem given the different sizes of objects that can be placed on the supporter. So you have to be sure that the spots are chosen so that there are no instances where objects overlap each other visually when placed on the supporter. I'll go into that in more detail later.
As for the parser, I actually did mimic the way Inform 6 does its parsing, so the way you describe the verbs and their syntax structures is exactly the way I've implemented things. The problem is not in the syntax, though, but in the way the parsing is performed. This is very low-level action that is very complicated and difficult to interpret from the Inform code, so for much of it I had to come up with my own interpretation.
The way I've implemented the parser, it is difficult to parse out two nouns that are not separated by a preposition. Mostly that's the result of me coding the parser without putting a lot of forethought into those (relatively less common) situations where two nouns are right next to each other. So I just need to go back and modify the parser so it can do that, which hopefully will not mess up everything that the parser is currently doing well.