Wrapping Up At the GDC Austin

I'm finally getting some time to put some thoughts together on this year's GDC Austin, as I sit in the airport waiting for my flight back. Luckily, it's still possible to put some thoughts together, after dumping half a beer on (and in) my laptop last night. I thought for sure that was the end of the line for the MacBook Pro, but it seems to have survived the scare.

It was an impressive amount of beer dumped directly over the power button and right half of the keyboard, and I wasn't exactly the swiftest to respond. But after giving it some time to dry upside down, it did start up the first time I tried. After that, though, on subsequent power-ups it would only cough and gasp before shutting down. It looked bleak. I'm not sure what did the trick. I gave it one last shot by holding down the power button a little longer than usual; the little power light flickered and the laptop gave a loud, almost alarming BEEP (which I've never heard it do before, must have been really pissed at me), and then it started up just fine. Seems to have recovered from its hangover now, thankfully.

As to more entertaining matters, I have to say, my talk on design innovations in interactive fiction was clearly the hit of the Austin GDC.

I should probably clarify that: by "clearly", I mean "to me", and by "the hit" I mean "easily the third or fourth best-attended lecture out of the four at 9:30AM on Day Two."

The talk did go well, although I now understand that 9:30AM is actually considered pretty early at conferences like these. There was a time in my life when 9:30AM seemed very early, maybe too early for intentionally getting out of bed. Now, not so much. I'm certainly not one of those people whose eyes automatically pop open at 5:30 in the morning every day, but I have reached the point where sleeping until 8:30 is a rare luxury. I think, when they combined the relatively early presentation time of 9:30AM with the understandably niche topic of interactive fiction, the result was about what I expected, which was a modest crowd. I don't remember the number specifically, I'd say maybe 30, give or take a few.

Which is not a bad group at all, except that I was in the semi-cavernous "Ballroom G", which was designed to fit many more. At least their expectations were high.

I learned that morning lectures aren't the greatest for humor. Even the high-powered Blizzard crew found that out the following day. I also learned that even those intentionally attending a lecture on interactive fiction don't necessarily know much about interactive fiction. A number of people looked at me funny when I mentioned "Zork", and only two or three people in the audience knew the reference when I flashed up a picture of my XYZZY license plate. For real.

But overall, everything went off without a hitch, and there were some very interested attendees with nice comments and a few good questions. People seemed genuinely appreciative of the content. I had too many slides, so I had to cut out some of the most important ones (where to get and play IF games), but people were interested enough to stay after and get the information. I got to cover a number of great pieces of IF, and spent a bit of extra time on works like Alabaster and Blue Lacuna. People really seemed to be fascinated at what these pieces are able to do.

Gamasutra was at the conference to cover the various sessions, so I was looking forward to a summary article online. Alas, this would not come to pass. I'm assuming it was because of limited personnel, as well as a not-quite-headliner presentation, which is just how it goes. But it's too bad, because it could have extended the reach of the topic to a wider audience.

All in all, though, it was a good time and a fun experience. More thoughts to follow.

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

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

The One Thing He Forgot To Mention

It's blog post number 100, so time to catch my breath. Crazy string of weeks there from April through mid-May, trying to make deadlines, having those deadlines pushed back, trying to make the deadlines again, and so forth. Some successes, some failures, but you can't argue with the fact that deadlines are great for getting shit done, even if you don't get it all done.

It's a little weird because my day job is filled with deadlines. Basically, it's like a slow march from one deadline to the next, and every so often I get caught up in it and spend massive amounts of time working like crazy to finish under the wire. But that's work. This was a deadline for a hobby. None of the panic, despair, and regret to deal with. It was a very different experience.

One of those deadlines was for the last Utah Indie Night, back at the end of April. I missed the last couple, so it was nice to be back, and to have another rare opportunity to present Vespers in public -- even if we didn't get everything for the full demo done. TRC had some nice things to say, which I appreciated, even if the game isn't very playable yet. Now that Aaron Reed has finished Blue Lacuna, it's now down to me and Jay to see who finishes last. Sorry, Jay, that flying car is all mine, so better start saving up now.

On a related note, at the start of the Utah Indie Night there was a short presentation by Darius Ouderkirk on how to choose an indie game project, with the key being a project that you can finish and release. As Jay blogged, it was simple but hit a lot of very good points -- even if, as pointed out to me later, he hasn't shipped a game himself yet (d'oh!). It was filled with good advice; a collection of fairly common sense approaches that have been mentioned in one context or another in various places around the 'tubes, but assembled and presented in a nice way.

But as I think about it now, there was one thing he forgot to mention.

With most projects, especially those you put a lot of yourself into over an extended period of time, there are peaks and valleys. And sometimes, those valleys can really suck. Sometimes, as Jay mentioned in another of his blogs, it has a lot to do with motivation. All games have fun parts and tedious parts, and those tedious parts can start to feel like chores after a while. Designing and implementing dialog boxes. Placing endless numbers of decorative objects, like walls or leaves. Modifying terrain. It can get pretty dull, but there are ways to fight through it, mixing the dull parts in with the fun parts. The target is always in front of you, so you just plug away until you get there.

But then there's the other type of valley: the periods of self-doubt that grow insidiously the longer you work on a project. Often you end up spending so much time working with all of the pieces at the microscopic level that you go long periods without taking a step back to see things at the macroscopic level. But then sometimes, when you do, the view doesn't seem so pretty anymore.

The usual questions start popping up, questions like "What am I doing?", or "Why am I doing this?" You have a clear view of all of the flaws, and none of the virtues. Nothing looks as good as you thought. The game doesn't seem very fun. The interface sucks. And of course, nobody is going to want to play it.

And that can be a really deep valley, because now you're not just dealing with the motivation to push through the boring crap, you're dealing with the motivation for the whole project. It's the kind of valley that can kill a project.

Of course, as with many things, it's never as good or as bad as you think, and sometimes it just takes a little perseverance to get through those periods. Maybe getting back to the microscopic level until the bad mojo passes. Or maybe taking a little time off from things and recharging the batteries. Or, perhaps, using the opportunity to get other people involved -- letting fresh eyes take a look at things to see what works and what doesn't, recalibrating your inner barometer.

I don't know what proportion of game projects go through valleys like these, but I imagine it's fairly high. I think it's probably more of an issue for individual developers and smaller indie groups, since there are fewer eyes looking at things from wider angles. Regardless, I think it's an important issue to mention to aspiring developers. Hell, it applies to anyone working on any kind of creative project. Be ready to hit at least one, and decide whether you're gonna suck it up and fight through it, or let the project wither away.

So I'm in one of those valleys right now. The closer it seems that we get to a working demo, the less I think this is actually going to work. It's hard to imagine people thinking the game is fun. The performance will stink, the animations and voice acting will disappoint, and the interface will be nothing but a confusing mess. What's to love?

I've taken about a week off from the game, but I'll be getting back to it soon. And I think maybe the best thing to do right now is to start getting some new eyes to look at the game. Do some testing, see if it really does stink. Maybe see what parts can be improved, and what parts just don't work at all. It's getting to be that time. And so I may need some help with that.

The Early April Vespers Thing

Turns out February kind of kicked me right in the family jewels, which is why there was no end of February update -- or much of anything, for that matter. We ended up getting very little done in general, to be honest, but it was for a whole variety of justifiable reasons and so as a group we just tried to put that month behind us. I also officially aged yet again during that time, but I've already passed the point where I should really be going public with that.

Then there was March, which ended up looking a lot like February, at least on the outside. But March actually did not suck, and we did make considerable progress on a number of fronts. But between all of the progress on the game and the travelling and extra work for the day job, blogging became the odd man out. Thus, the end of March update has been pushed into April. But there is much to discuss.

I ended up spending a large chunk of February wrestling with Torque's GUI system. We wanted to create a new set of GUI borders to use throughout the game, for small in-game windows like the text output window and the inventory window. Torque has a nice built-in system for re-sizing windows and their borders, so in some cases you can create a small image file for your border that contains only the critical parts -- the corners and a small portion of the top/bottom and left/right sides. Then the engine uses this to create the full window border at whatever size you specify, stretching the sides as much as needed. Problem is, this only works with border images that can be stretched. Since N.R.'s spiffy new border is most definitely not stretchable, we needed to revert to just a basic bitmap image of the whole border. For the text output window, though, we allow the window to be resized to three different sizes, so now we need three new bitmaps. Not a big deal, but it does mean more images, more memory, and more drive space. Oh, and for some ridiculous reason doing so completely screwed up the inventory window.

The inventory window, when visible, is supposed to sit on top of the text output window. So when the text output window is changed from one size to another, the inventory window position needs to be adjusted. This would seem like a straightforward problem, but I think I spent about two weeks trying to get it to work right. Rather than bore you with the details, suffice it to say that the more I think I know about Torque's GUI system, the less I actually seem to.



We also spent some time fixing up other GUI windows and adding some more environmental decorations, such as snow drifts in the cloister and on the front entrance. Things are looking nicer, but all in all not a very productive month.

March was far kinder than February. On the NPC front, Lem finished his work on Lucca, while Shawn finished up Constantin and Matteo, which means I've been spending a lot of my time exporting animations, putting in the code for each, and getting the timing of the audio just right. It's a lot more work than it seems at first, especially since things never seem to turn out right the first time. But it's also very gratifying to see animations and audio playing together in response to a command. It's one of the things that makes this feel like a real game.

N.R., meanwhile, has churned out the last of the main monastery structures, the stables and the infirmary. Neither of these are approachable until Day Two of the game (Act III), which is beyond the demo, so for now the structures will stay relatively empty. But he did a really nice job keeping the same structural themes throughout. And I think the stables will fit very nicely with 3d-diggers's Horse Pack, which we will be incorporating.

The infirmary.

We did have to make one relatively minor change to the game from Jason's original text version. In the original, the player can climb a ladder in the stables up through an opening in the roof. The roof, then, is dealt with as a single "room" or location in the game. This is generally not a problem in 3D, but it becomes complicated when you need to account for where the player is in space. Up on the roof, the player could move around to any of the four sides of the building, which would really complicate one of the puzzles in the game. It's another example of something which is much easier to implement in text than in 3D.

So instead of allowing the player onto the roof, we decided instead to make a hayloft inside the stables, and to use this location instead of the roof as the destination for the ladder. We'll then be able to use bales of hay to create a relatively small space for the player to move around, instead of the larger open space up on the roof, and it shouldn't have any measurable effect on the puzzle involving this location.

The stables, with the hayloft.

Finally, after much debate, we decided to implement the cat from the original text game. The cat has mostly symbolic meaning in the original, but due to some more 3D-related complications, we were thinking previously that we might just leave it out. Jason later convinced me it would be worth the effort, if only to lend a nice atmospheric touch to the game. So N.R. designed and built the model, and Lem got to work rigging and animating it. In the end, I'm really glad we did it -- even if it ends up being only a tiny, insignificant part of the game.



What's up Next?

April has arrived much sooner than expected, and with it comes two big deadlines, which just happen to be on the same day: April 30th is the next Utah Indie Game Dev Night, and it's also the submission date for this year's IndiCade. Although the game is obviously nowhere near done yet, we are closing in on being finished with Act I, which is to be our "demo" of the game. And since IndieCade permits and encourages the submission of works in progress, our plan has been to submit the complete Act I as an example of a "finished, playable level" from the game.

We had also planned on being done with Act I for the next Utah Indie Game Dev Night, so the fact that these both fall on the same day is helpful. But there is still a huge amount of work to be done to reach that point, and with the day job remaining extremely busy, I'm not sure yet if we'll really be able to do it. But the gauntlet has been thrown down, and we have taken it up. We'll see if we're up to the challenge.

Targeting Older Systems

Way back when, when the Vespers project was first starting out, I had to decide which game engine to use. Initially, the choice was between the Torque Game Engine and the Unity engine. I eventually chose TGE for a few reasons -- at the time, the engine had been around longer than Unity, the community was larger, and it was less expensive and more straightforward to develop cross-platform games (specifically, Mac and PC).

Once that decision was made, then there was the choice of which Torque engine to use: the basic TGE engine, or the higher-end TGEA (TGE-Advanced) engine, which back then was called TSE (for "Torque Shader Engine"). TGEA offered a number of more advanced features, the most obvious of which was higher-quality graphic rendering. That came at a price, though; at the time, the engine would only run on Windows machines, and it required machines with graphics cards that could handle the bigger load. Also, although TGEA does now support OpenGL and Macs, back then it was not so clear if that would ever actually come to pass. Since I was more interested in developing simultaneously for Windows and Macs, TGEA didn't seem like the best option at the time. TGE had been around longer and was more stable, even though its graphics performance was not at the same level as TGEA.

For me, though, stunning shaders and slick water rendering were trumped by the desire to create a game that would run on a wide range of machines, especially machines that are older or without the top of the line video card. The problem there is that, given the length of time for development, it's hard to put (or perhaps keep) a finger on what constitutes an appropriately "old" machine. When I started development of Vespers, my main desktop dev machine was still fairly new and probably middle of the line. Now, however, the machine is going on six years old. That doesn't seem very old, and it still runs most of my applications nicely enough, but in computer years that's almost geriatric and at this point it's naturally much slower than the machines from the past couple of years.

This is not a big deal for day-to-day activities, but as we add more and more content to the game, we're seeing some serious performance issues on my now old machine, despite a few rounds of optimization. But that makes me start to question what I should be targeting for a minimum system requirement. I had always thought that my machine would still be somewhere in the middle by the time we finished development, but now I'm beginning to feel like it's toward the bottom end.

(In case the four of you reading this are interested, my dev machine is a Mac G5 Dual 2 GHz model, circa 2003, with an ATI Radeon x800 video card, but it also runs well enough on the same setup with an ATI Radeon 9600 card. My wife still uses a Mac G4 laptop, so there are certainly G4 computers still perfectly usable. But Macs have evolved over the years to faster G5 chips and now a couple of rounds of Intel chips, as well as more modern video cards.)

I've generally been going on the assumption that if the game runs well enough on my dev machine, by the time it's released that should be a fairly reasonable minimum system requirement. But it will be progressively more difficult to ensure it runs well enough on machines that are even just a little bit older. Still, my goal is to try and include as many older machines as possible. The more the merrier -- but within a still to-be-determined limit.

So that leads me to wonder: how long do you all typically own a computer before replacing it with a new machine? Adding memory or upgrading the video card extends the life of a computer, of course, but that's not what I'm talking about here. I'm interested to know how long people generally keep their rigs before replacing them with a new box. Some people of course keep their old rigs around for different tasks, but I'm interested in knowing how old some of the systems are out there that people still use for gaming (particularly 3D games, like Vespers), and what kind of system people would be interested in seeing this game run on -- Mac or PC/Windows. If you would, let me know in the comments below.

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.

Curse My Expensive Font Tastes

Without question, some of the best advice I've been given on the business of indie game development has come from Tom Buscaglia, the Game Attorney -- probably one of the best attorneys representing game developers. Much of this advice comes from his Game Dev Kit, a set of information and forms for start-up game developers, which in my opinion is an excellent resource for any small start-up indie. Above all, the best advice is:

"Quite simply, you can not sell what you do not own."

So basically, any and all assets put into a game must be owned by the legal entity (company or individual) that owns the game, or they must have an appropriate license from the actual owner of the asset. Once you really get elbows deep into the development of a game, you quickly realize how complicated this can become due to the many categories and sheer volume of assets that are needed for game development. Every model, every texture, every musical piece or sound clip -- all of it must either be owned by the company making and selling the game, or they have to be licensed to sell it commercially.

This can end up being quite the chore, and it's good practice (especially for the small indie developer who is working primarily on his own) to keep a "master asset list" to track all of these assets and their ownership or licensing status. It also helps to bone up on some of the basic legal issues surrounding appropriate documentation of ownership, and to make sure you take care of those issues sooner rather than later. It's far too easy to slap a sound, musical clip, or texture into your game, even as as a placeholder, and then completely forget about it. Believe me, it sucks to have to track down that dude who helped you with your title music a couple years back because you never asked him to verify and transfer the IP over to you.

One of the assets which, I think, is most often overlooked in this respect is fonts.

Fonts are one of those things that I think a lot of people take for granted -- your computer comes with a whole mess of them installed, and it's easy to find hordes of free ones online. They're often passed around as easily, freely, and inappropriately as MP3s. But for games, fonts are an asset just like anything else, and unless you own it or are licensed commercially, you can't sell it. So the solution is to create your own or buy an appropriate commercial license, unless you want to stick with boring public domain fonts.

The problem for me is that I have a special thing for fonts. I love fonts. I collect them. I hoard them the way some women hoard shoes. I'm a regular customer on MyFonts.com and if they offered a frequent buyer rewards program I'm sure I'd soon be platinum level.

So for me, finding the font that is just right for use in Vespers is a long, exhaustive research project. Right now, we're using two main fonts in the game, one for the text input and output windows, and the other for most everything else (the main logo, menu items, titles, buttons, and so forth). The font for the text windows is not a large concern for me, as long as it is clear and legible at multiple sizes, and has at least some interesting style to it. Early on, I settled for a font called Flute, which is shown below. Flute is a pretty cheap font -- I think it originally sold for $8 and last I checked was free on MyFonts.com -- and there shouldn't be any problem getting an appropriate license for our use. The other font, however, is a bit of a problem.

Flute

Until recently, the font I have been using for all of the good stuff is called Cezanne, by P22 Foundry. Those folks make a lot of very high quality fonts that are used widely for commercial purposes. In fact, I've seen Cezanne in a lot of places -- on TV, in print, even on the cover of my local phone book. It's an extrordinary font that I think is absolutely beautiful, and of all of the fonts I've researched, this one really stands out from the others. I hesitate to say that it is perfect, but damn if it isn't close to that.

Cezanne

But you have to write to P22 if you want to use their fonts commercially and get a special license, like for what we're doing. And, of course, they responded by asking a wild amount of money for this, on the order of $1,500 -- half for embedding the font, the other half for the commercial license. Now, I understand this, of course. This font is a work of art, and it makes sense for them to expect an appropriate license payment from someone who wants to make piles of money on a product the appeal of which is due, at least in part, to their craftsmanship. But given that we're a small indie company with a development budget in the low five digits, this represents a significant fraction of our overall development costs. I tried a little negotiation, and they offered an alternative licensing plan that is less expensive, but it's still a lot. So I've been looking at alternatives.

I've always thought, for some reason, that the main font in the game should be a handwritten font. I'm not entirely sure why, I just feel like it communicates the feel of the game (from the Abbot's perspective) the best. So I'm looking to maintain that, but there are only so many options. Once you get past a few good ones, most handwriting or calligraphy fonts start getting far too curly, decorative, or perfect. And I'm not that easy to please.

Suffice it to say that I haven't come across another one yet that has jumped out at me as a clear replacement for Cezanne, but there are a few options. The best of the bunch is a font called Whitechapel, from Blambot, a foundry that specializes in comic fonts and lettering. It's a nice handwriting font that I think conveys the right image, although I still think it's a step below Cezanne and it doesn't completely satisfy me. So when Blambot told me that our use of the font constitutes "redistribution of a derivative work of the font" which would cost $500 for an appropriate license, I thought, "Thanks, but no thanks."

Whitechapel

One of the problems here is that our use of the font is a little atypical. Often under most font licenses, it's illegal to include the font file itself, such as the TrueType file, with a distributed game. But with games powered by the Torque Game Engine, you don't need to include font files with your games -- the Torque engine takes all of the fonts used in the game and creates a special kind of bitmap file for each font and size. The characters are basically rendered to a bitmap and stored for later display. There's no way to reverse engineer it, and no way for clients to take that bitmap and somehow install it on their machine. Nevertheless, many of these companies still believe that this constitutes embedding and redistribution.

I do have permission to use another font, Secret Scrypt, a very cool font from another very cool font foundry called Canada Type. It cost a mere $30 for its commercial fee. It's a bit heavy for my tastes, but it was actually the first font I started using for Vespers, so I may end up just going back to the start with respect to this font.

Secret Scrypt

Curse my expensive font tastes.

The End of December Vespers Thing (Or, Back After A December Hiatus)

December was a pretty crazy month. The first half was consumed by a major deadline at work, so I was in "Super Cthulu Crunch" mode (again) for quite some time. This was mercifully followed by some much-needed vacation time visiting family members out of state, and while I did have my laptop with me, I wasn't able to spend much time working on Vespers or the blog. So December basically became a short one-month hiatus essentially by default. I know this was difficult for many of you. Apologies and such.

Now that I'm back to the usual routine, it's time to pick things back up, and there's plenty of good stuff to talk about -- including some hands-on time with a (somewhat) recently released adventure game with some eerily familiar themes. But more on that later.

For now, at least, only a few words on Vespers over the past month.

Despite the lack of production on my end, and despite taking on additional work outside of Vespers, N.R. was able to finish off the last of the LOD (level of detail) work on the monastery complex, which I had talked about earlier. This is kind of a big deal, I'd say, since that represents a lot of work and signals, I believe, the last of the work on the main monastery buildings. There are a few details that need to be added, like some additional decorations and the wooden stairs in each of the towers, but those are objects separate from the buildings themselves. So it might be fair to say that we're finished modeling the main structures of the monastery complex. That's pretty cool.


Right now N.R. has turned his attention to some of the interesting 2D artwork, for a change. That includes a new title logo, with a different font and altered blood spot. We're going to try and do some animation with that blood spot in the intro sequence, but we'll see how that works out. He's also working on some new designs for the main menu and the in-game HUD elements, such as the text output window. I'm looking forward to new graphics after looking at the hack job programmer art I slapped together who knows how many years ago.

We're also looking to try something a little more interesting with the splash screens at the start. Instead of just popping up a couple of static 2D graphic logos to which nobody pays any attention, N.R. thought it might be worth overlaying the logos on top of an appropriate work of art. His excellent choice was The Triumph of Death, a piece by the great Flemish painter Pieter Bruegel (the Elder) from around 1562. Although it's likely that the macabre content of the piece is more a reflection of the violent history of the Netherlands in the 1560's than of the plague, the theme is still highly relevant: death is an ever-present threat in the world, and ultimately seizes all men and women, rich and poor alike, and to struggle against this fate is foolish and futile. In one instance, the content was described as "a vision of hell and its forces loosed on earth"(1). Without being too much of a spoiler, it's quite the fitting selection. Although the painting itself is considered in the public domain, we were fortunately given permission to use a good quality digital reproduction from the Web Gallery of Art (an awesome reference site, by the way).


You can see higher resolution versions of the painting, including detail close-ups, here at the WGoA web site.

The character animation work also slowed down considerably during December for a variety of reasons, so not much new to report on that front. But things are starting back up again, and there should be some new content to work on within the week, I expect.

The next Utah Indie Games night is coming up towards the end of January, only a few weeks away. We were thinking we might have everything from Act I done and ready for that event, although it will be a challenge at this point given the slow progress in December. I'll need to install the remainder of the animations for Ignatius and replace those for Constantin, and then we would need the entire set of animations created for both Cecilia and Drogo. That would get us a roughly complete Act I, although our plan is also to re-do the animations for Matteo and Lucca before declaring Act I officially complete.

And on one final note, the end of December brings yet another anniversary of sorts: December 30, 2005 was the day I received an e-mail reply from Jason agreeing to a 3D remake of Vespers, which essentially marks the start of this project. Coincidentally, that same day I received an e-mail from N.R. asking about being involved in the creation of the game. So tomorrow marks the three-year anniversary of the start of our development. Three years...wow.


(1) Bruegel's The Triumph of Death Reconsidered, by Peter Thon, Renaissance Quarterly © 1968 The University of Chicago Press.

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.

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

The End of September Vespers Thing

Another month has come and gone, which means it's time for a quick Vespers update.

Nope, it's not finished yet.

Was September a good month? In general, I'd say it was pretty good. On the one hand, another student animator has left the project, which means we're down to three. At least I'm assuming he's left the project -- like so many that came before him, he's just no longer responding to e-mails. It's not too troublesome since he never really got off the blocks with this project, but still...is it just animators, or are other people like this as well? In the face of overcommitment or disinterest, is it everybody's instinct to lie low and hope nobody notices? Or just animators?

On the other hand, the remaining three animators are progressing nicely, and one in particular, Shawn, has agreed to devote a good deal of time and effort over the next few months to get these animations done. That would really be fantastic. The slowest, most tedious part is getting the models rigged, setting up the faces for lip sync, and making sure the models and animations export properly and appear in the game engine the way they're supposed to appear. Once that's done, then the animations can be cranked out. We've just about reached that point with a couple of the characters, so I'm hopeful that we'll have a batch of new animations soon.

Guys, if you're reading this: don't do the vanishing act thing!

On the modeling front, N.R. and I have spent the past month mostly on two fronts: decorations and the calefactory. The decorations at this point have been mostly cobwebs, which look great. Animating them has been a challenge, however -- it's really difficult to replicate the typical motion of cobwebs blowing in a breeze. We'll use them sparingly to save on frame rates, but they should provide an extra little bit of atmosphere. Now all we need is a smattering of dead leaves around the place, and we should be set with the decorations.

Then there's the calefactory.

It's quite interesting how little information is readily available to describe precisely what a calefactory is and what typically went on inside one. I think that's part of the reason Jason left the calefactory description in the text game so limited -- in fact, other than the heat in the room, there isn't much description of it at all:

>look

Calefactory
Positioned directly between the dormitory and your own room, the calefactory warms both, although lately it is less than adequate. While the calefactory itself is stiflingly hot, its heat stays confined. Your brow grows damp: your body, feverish. Slightly melted snow creeps in from the cloister to the northwest.

Nothing on the shape of the room, its contents, if it has any windows, even the source of the strong heat in the room. Is it a fireplace? A stove? Any chairs or tables? Jason is essentially giving us freedom to improvise, but it's a little tricky -- on the one hand, we need to figure out what a calefactory normally would look like and what would appear inside, while on the other we don't want to start adding a whole set of objects that the player would want or expect to be able to interact with and which might mess with the established game structure and mechanics.

It brings up one of those interesting differences between textual and graphical interfaces: with text, authors have the freedom to paint with broad strokes and allow the reader to fill in many of the details, while with graphics, designers are forced to provide those details. With respect to setting, this can work well both ways. In the text version of Vespers, for instance, Jason provides little detail in the descriptions of locations such as the calefactory and the kitchen, but it doesn't diminish their impact on the player's mental model of the game setting; despite not knowing what was actually in those rooms, they still felt real and not at all empty -- and Jason didn't have to worry about implementing all of the different items that would probably be there. But there's also something magical about recreating a setting visually down to the last detail and providing the audience the opportunity to experience that setting in ways they couldn't otherwise. To me, that is one of the pleasures of watching historical (fiction or non-fiction) movies.

Of course, that also means we have to go and figure all of this stuff out, and to try and retain some semblance of historical accuracy. I've done some rudimentary research on calefactories, but as I said it's surprising how little information is readily accessible. About all I know for certain is that there should be a fire source and probably some places to sit.

This is about as far as we've gotten so far. Look, a firepit!



Until next month...

Holidays Are Good For Gaming (And Coding)

Following on the heels of Scorpia's and Coyote's posts, I just felt the need to say how great long weekends can be for gaming. Especially game coding. I had a mess of spare time to myself over the weekend, so I was able to get in some quality gaming and coding sessions that I hadn't had in some time.

I had an itch to replay Doukustu (Cave Story), so I downloaded it again and fired it up. It never ceases to amaze me. Such simple gameplay, and yet it's so engrossing. Everything just seems to work well in that game -- the graphics, story, interface, music, you name it. Even though there is never any direct communication depicted between the protagonist and the other characters, and even though your only communication is equivalent to the simple "TALK" mechanic, it still manages to feel like a series of conversations that nicely advance the story. A lot we could learn from that one.

As for Vespers, I was able to implement some things I had on the list for a long time. One was getting the fireplace in the locutory working, which meant putting together the mechanics for flames, smoke, and firelight, and then implementing the BURN (not to mention EXTINGUISH) verbs. Also got to put in a mess of N.R.'s new models, which have some really nice textures. Got some straw on the floor, cobwebs on the walls, and a slick new (well, old) desk for the Abbot's bedroom. I got a lot done, and it felt good. Couple screenies for you below; click to see the big version if you like.



Now to figure out a response to Corvus...

Orange River Studio, LLC

Many indie game projects start out as fun side pursuits among a small group of friends. Often at the start there is an idea, a concept, some talent, and motivation. A lot of projects, along the way, fall short in one or more of those areas -- the idea isn't as cool as it first sounded; the concept doesn't work as well as expected; the talent to achieve the goal is lacking; or some folks just lose their motivation and the project fizzles out.

If things work out and you have a reasonably good mix of those elements, you reach something of a milestone: that point when you're convinced that you can really do it. With Vespers, that occurred sometime after the first year or so of development.

That milestone is usually followed by a period of laboring away at the many tasks and details of the game. Coding, modeling, animating, testing, squashing bugs, coming up with solutions and workarounds to various problems that arise. Slowly and steadily plodding away at all of the different chores. If things continue to work out, you soon come to another understanding: Not only can you do it, but you really are doing it. But with that awareness comes a realization: if you're truly intent on finishing the job, you're gonna have to start getting serious about the business side of things.

Therein lies the next milestone: you're committed enough and far enough along to take the first steps toward creating a business entity.

It's seems a little silly to me when I think about forming a company, maybe even a little conceited. I mean, really, the truth for most small indie games is that they won't sell more than a few hundred copies at most. Do you really need to spend time and money forming a company for that? And without a long-term plan for additional games beyond this one, doesn't that seem a bit excessive?

The answer, actually, is that it does make a lot of sense. Even for a group as small as ours, even for a single game, and even at this (relatively) early stage of development.

Our situation is not unlike that of many small indie groups, and one person with a lot of experience with these groups is Tom Buscaglia, an attorney from Washington known as "The Game Attorney". Over the years, he's developed a certain expertise in the legal side of indie game companies, and he's done a lot to help small groups take the necessary steps to make sure everything they do is in order and legit.

Often, small hobbyist groups like ours make enough progress on their projects to reach a point where they can put a demo together to show interested parties, like a publisher. But as Tom has said, these scenarios are usually full of potential problems that could make it impossible to get the game to the public. Questions raised include things like:

• What legal entity will interested parties deal with?


• Who on the team gets what if the team succeeds?


• Who owns the assets in the game?


• Are there any problems with the assets that would prevent the game from being taken to market?

As Tom says:

"To a publisher (or a lawyer or businessman) how you address these basic questions at the beginning of your project reflects on whether this team is "together" enough to come through with the finished product. The failure to have dealt with the more mundane legal issues of forming a company, deciding shares first and securing Intellectual Property rights to the game assets may be just a lack of business experience. But to business heads like publishers there will be little sympathy."

A lot of groups don't want to deal with those things -- at least, not until they have to, and by then it's usually late enough to cause big headaches. So Tom's advice, of course, is to take care of these things sooner rather than later. Granted, he's a lawyer with a bias, but it's pretty sound advice -- at least when you've reached that second milestone when you're reasonably certain you're going to have a product ready in the (relatively) near future.

Forming a company like an LLC has a number of distinct advantages, even at this point in time for our group. It defines who other companies deal with, who owns the assets, and how any royalties are split up. And even if we decide down the road that Vespers is to be released for free, it still helps to ensure that the project and all of its components are in order, and helps to define how we might proceed in the future on any additional projects.

There are also a few other reasons for doing this. For one, it's much easier (and more professional) to designate the company as the primary, central entity that deals with outside parties -- other artists or contributors, publishers, and so on. In many of these cases we would be dealing with things like NDAs and contributor agreements, and it's a lot better to specify that these agreements are with the company rather than with me personally.

Then there is also the liability issue. By forming a company like an LLC, liability becomes less of an issue for me (or anyone else associated with the company). For instance, if we release the game and later we get sued by someone for copyright infringement, then in the absence of a company then all of my assets are at risk, including my property, house, car, and so on. By forming an LLC, my personal and professional liability are separated, so none of my personal assets would be at risk as a result of some legal action against the company or one of its games.

That said, creating a company also raises more questions. To this point we haven't really considered ourselves as a "game development company" per se, only as a "Vespers development company" -- that is, is there an expectation that we will really function as a company that makes not just one, but perhaps many, games? And if so, how will the company operate? Who's in charge? Who makes decisions? Who handles different responsibilities? Are there any employees, or just partners? How are those partnerships defined?

Tough questions to answer. I'll be spending a lot of time in the upcoming months trying my best to answer them. For now, however, I'll be working on everything necessary to make Orange River Studio, LLC, a real entity.

Vespers on the iPhone...for real?

My last blog was mostly tongue-in-cheek, referring more to the IF version of Vespers on the iPhone running in Frotz. Still, there has been speculation over on the GarageGames forums that the Torque engine was being ported to the iPhone platform. I didn't give it much consideration, though, since I figured (a) it would be a long way away, (b) licensing would be more than it's worth, and (c) they'd be far more likely to port their 2D engine rather than the 3D engine. Plus, I can't imagine Vespers truly running on the iPhone in 3D -- surely there's no way the phone could handle the load. It would beg for mercy, maybe even spontaneously ignite.

Well, so much for (a), (b), and (c) at least.

Yesterday, GarageGames officially announced the licensing and availability of the iPhone version of Torque. (It's actually called iTorque, but really, it's almost too painful to type that. Seriously. I'll just call it iPVT or something until they correct that gaffe.)

By the way, what is that iTGE guy doing? Digging a hole? Farming? Shooting pool?

So it turns out they're porting both 2D and 3D engines, which is pretty cool. And the SDK is apparently available now, although at first only to commercial licensees, which I'm not. The indie version is supposed to be available soon, after they've worked out some of the kinks. The nice part is that their licensing model is really not that bad: $500 for the 2D or 3D SDK (for current owners) with the right to publish one title; future titles are only $100 each. And no royalties for GarageGames, ever. That's a pretty nice deal, all things considered.

The Unity engine will also be available for the iPhone at some point, which means that there will be a whole lot of goodness coming to the iPhone. I really know nothing about the iPhone and its memory or graphics, but I imagine since both Unity and TGE will allow for iPhone development, it must be at least somewhat capable.

My guess, however, is that 3D gaming will still be limited, at least for a while. I really can't imagine that we'll be seeing complex 3D graphical games running at acceptable speeds on that platform, although the smaller screen would presumably dictate (and allow) simpler, less intensive models. Maybe as the platform evolves we'll see more powerful 3D chips able to handle large models and textures with detailed lighting. Who knows.

As for Vespers, I still have serious doubts.

Graphically, it's a pretty intense game -- even though that really hasn't been the objective. The monastery is a fairly huge set of models with a lot of polys and some large textures, and it's still makes my desktop cough and wheeze. There's a lot we could do to simplify and optimize, but that would take a lot of extra work.

Then, there's the whole interface thing. I think it probably wouldn't be too hard to come up with an interface design to allow for simple movement similar to the typical W-A-S-D/mouse combination, but there's still the accompanying text input and output. I don't know. It might be possible, but it would require a whole lot of redesign.

Still, it's nice to see the possibility there, however distant. But we still have a long way to go with the desktop version.

Vespers on the iPhone

Now that would be cool. But not this Vespers, the original text game.

So I hear Frotz, a popular Z-machine implementation used for playing interactive fiction, is now available for free on Apple's iPhone App Store. Apparently there was some question about whether Apple would allow it in the store, probably because it is an interpreter used for playing separately downloaded game files. But it looks as if, for now at least, it is approved for downloading.

The software comes pre-packaged with a number of good IF games, and it looks like Jason's original text version of Vespers is one of the ones included. Very sweet. Even better, the program can connect directly to the IFDB, allowing users to easily download and play any of the hundreds of games in the collection. From the screenshots, the interface looks nice and clear, and appears to be quite customizable.


Combined with the potentially vast user base for the iPhone/iPod Touch, this package might very well prove to be a great way of expanding the IF audience. I think a lot will depend on the speed, implementation, and interface. As soon as I can get my paws on a Touch, I'll be trying this right out. For now, though, it looks very promising.

In the meantime, I'll have to start daydreaming about how I'd do movement on this thing...

One Step Forward, One Step Back

Such is the life of an indie developer, or at least it seems to be when it comes to character animation.

So far, the experiment with our student animators has gone...well, slowly. With five students on board, things were bound to take extra time. It's tough to move forward while making sure everyone is on the same page, setting up their model skeletons the same way, making sure their model heirarchy is consistent for exporting to Torque format, and so on. There was also the added delay in moving our models from 3DS Max to Maya, which introduced a whole variety of issues. As I've learned, there is a long lead-in period when starting with a new modeling program making sure your models play nice with Torque. Add to that a group of students who are new to the models and new to Torque, not to mention the fact that it's summertime, and you've got a recipe better suited to a slow cooker than a short-order grill.

Still, this week we reached a small milestone, when we finally got our first character set up properly in Maya with the right skeleton, the right textures, and the right object heirarchy for proper Torque export. The character is set in his correct "root" pose, and the exported model imports properly into the game engine. Now all we need to do is set up a facial skeleton for expressions and lip sync, and the model should be ready for animation.

The nice part about that is that we can easily apply these advances to our other models, so a few more character models should be animation-ready within a short time, I expect.

Nevertheless, as these things go, it's not all sunshine and butterflies.

One of the student animators never really made any progress with his character, and something always came up preventing him from attending any of our weekly meetings. As his communications became fewer and fewer, I recognized the telltale signs of yet another animator silently heading for the exit doors. After bringing it up with him, he did finally admit to being overcommitted, so now we're back down to four animators.

Which is still good, of course. Four is a good number to have, and right now most are working together nicely as a team. We're still in the slow stages, but I think we've reached the point where things will start picking up again.

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.