Recent Vespers News
A Milestone Of Sorts
20 Feb 13
Time for another pseudo-quick update.
I know it's been a long road so far with this game, a lot longer than I planned. It's amazing how much the computer gaming world has changed since I started this thing -- back then, there were no iPhones or iPads, and most gaming was either on desktops or consoles. Now, the game industry has shifted dramatically toward mobile devices, just like a lot of other industries. I sometimes wonder how many people still use their desktops for gaming. Nevertheless, this game needs to be done and put out there, and it's about time I did something about that.
So as I mentioned in my last post, I managed to get over a pretty large hump at the end of last year, and since then progress has been rapid. At this point, I've finally managed to do what I've been trying to do for some years now: get all of Act 1 content and the first cutscene put together so you can play the game through all the way from the very beginning to the end of the first cutscene. There are assorted little pieces that still need to be slipped in here and there, but nothing too important. A few extra sound files, a few environmental objects, maybe some more non-essential verbs, and of course the occasional bug fix, but that's really about it. The one important thing I haven't implemented yet is the PRAY command, but that's less important for Act 1 than it is later in the game, so I'll work on that soon enough.
That content, in a nutshell, is what I've been talking about for so long as the "demo." And I mean that more in the manner of "tech demo" than "demo of a complete game," since this is really just one big experiment, and my goal is to see if this is at least worthwhile to continue all the way through to the end. But that means, with a bit of cleaning up and some testing, I might actually, seriously, no-kidding-this-time be able to get this submitted to the IndieCade meeting this year, since they accept works in progress. They may hate it (or, worse, ignore it), but at least it can get submitted and I can stop saying over and over (and over) that this is the year I'm going to do it.
So after I clean up a few loose ends, that means I need to start focusing a lot of effort on testing and feedback, and that is about to start in earnest.
I've already enlisted a handful of testers, but if there's anyone out there still paying attention and who is really up for it, let me know and I'll set things up so you can download the latest version and start hacking away at it. But please only do so if you can dedicate a bit of time to it and can give useful feedback. I'm also starting a closed, invite-only Google group to have a discussion forum for testers of the game.
I think the deadline for submission to IndieCade is toward the end of May, so there's a good amount of time left to smack this thing around and fix some of the big problems. So it's time to get started and move to the next phase. Who's with me?
Hello? Is this thing on?
16 Feb 13
Oh right, the game thing. Almost forgot about that.
Well now that you mention it, yes, as a matter of fact it is definitely on. For a while there it didn't seem like it, but if you ask me why that was, I'm not sure I could give you a great answer.
2012 started strong, but March never seems to be a good month, and apparently I have problems getting past it. Last year, it was a combination of things, but I think the biggest reason is that I just had too many things to do in life and not enough hours in the day to do them. On top of that, I had run into a real road block in development, the kind that brought things to a standstill, and there just didn't seem to be enough inertia to get past it. So faced with a brick wall, development stopped.
The road block was basically a lot of architecture redesign to accommodate more than one Act, and more than one Day, in both the game code and the file structure. When I started, I never really gave that much consideration, thinking that it wouldn't be a big deal to handle when the time came. Well, apparently I was wrong about that. I thought about it for a while, couldn't come up with a satisfying solution, and got frustrated. The rest of life came at me, and once I stepped away from the problem it was hard as hell to get back into it.
But all that appears to be behind us now.
It was really nothing more than brute force and time that solved it. It's possible that the injury to my shoulder may have helped, as it removed some of the competing priorities in life, but who knows how true that is. All I know is that I finally sat my ass down in that chair for a few days, forced myself to come up with a solution for the architecture, and hammered it out. And once that was done, the doors opened and the rest started to flow again.
That was a couple months ago, and since then I've been making progress in leaps and bounds, tackling some of the things I thought I might never get to.
I had to implement the sequence for making the girl appear at the front door after an appropriate delay from the start of the game. I had to implement a system of random environmental sounds, for things like wolf howls and wind gusts. Thunder and lightning had to be implemented, to herald the approach of the girl. Other mechanisms had to be implemented to prevent the player from doing unwanted or unexpected things with the girl. And all of this had to be coordinated so that none of these interfered with each other, or interrupted a conversation the player was having with one of the other characters. All that is now done.
More verbs have been defined and implemented, and more work was done with the text parser (yes, even that) to clean things up and give more appropriate responses. We now seem to be handling the word "her" with more grace, given that it can be both a possessive ("examine her eyes") and a pronoun ("give her the blanket"). And there are many more responses to player commands that show a need for assistance, such as "What am I supposed to do now?"
All of these are done, and all of it in just the last few weeks. Removing that road block did wonders for things. I've checked off so many items from the task list that I have to create new ones to keep myself busy.
I've now reached the point that I'm only a few steps away from finishing Act 1 and connecting it to the first cutscene. Once I do that, it's just a few more steps to package that as a real demo, and then I'll move into a period of serious user testing. Who knows? Maybe it will be done enough to submit to IndieCade this year, like I always say. We'll see...
Screenshot Saturday, 11 Feb 2012
11 Feb 12
The Vespers submission for Screenshot Saturday for February 11, 2012. Check out all of the indie screenshot submissions over at screenshotsaturday.com.
Screenshot Saturday, 11 Feb 2012
11 Feb 12
The Vespers submission for Screenshot Saturday for February 11, 2012. Check out all of the indie screenshot submissions over at screenshotsaturday.com.
Vespers, Act I, showing the monastery entrance doors and the highlighted alms box.
The Completely Random 2012 Update
9 Feb 12
I've been working on Vespers such a long time now that I think people consider it part of who I am. And not so much in an inspirational or spiritual kind of way, more like a lingering-chronic-disease kind of way. So every now and then when I see friends, I get a few "Say, how's your game?" questions, and while it's nice to know that people still think about the game it really just sounds more like commiseration than anything else, kind of like "Say, how's your irritable bowel?"
The Completely Random 2012 Update
9 Feb 12
I've been working on Vespers such a long time now that I think people consider it part of who I am. And not so much in an inspirational or spiritual kind of way, more like a lingering-chronic-disease kind of way. So every now and then when I see friends, I get a few "Say, how's your game?" questions, and while it's nice to know that people still think about the game it really just sounds more like commiseration than anything else, kind of like "Say, how's your irritable bowel?"
Despite the lack of updates on this blog for some time, the game actually is progressing. Seriously, I'm not kidding. In fact, I'd say it's progressing very well – better than at any point over the last few years. The reason, some of you may guess, is that I was finally able to find an animator who is willing and able to handle everything I throw at him. He's so motivated, in fact, that I'm having a hard time keeping up with him. Right now I have a huge backlog of work getting all of his animation sequences exported and integrated into the game, which is a great problem to have. I'm flush with material and there's enough to keep me going for quite some time.
The animator, as it turns out, is the same guy who has done all of the modeling and 2D work for the game and who currently has the title of Art Lead on the project, N.R. Bharathae. Animation isn't something that he has done much of in the past, but he's had a pretty good handle on it from the start, and the quality of his work is good even at this stage. There's enough work still left to do on this project that it should give him a lot of practice and, in the end, a nice body of work to show off. Hopefully that will lead to more work for him in the future. In the meantime, I couldn't be happier to have him – it's been a long time since I've had such a steady and reliable influx of new material. (Note to the gods: this should not be taken as any form of jinx. Nothing to see here, move along.)
So where do things currently stand?
Vespers, as some of you know, plays out over three game days, and I've taken the additional step of dividing those days into Acts. So the game takes place over five Acts: Day 1 consists of Acts I and II, Day 2 consists of Acts III and IV, and Day 3 is the final Act V. A cutscene also marks the transition between each Act. Since my focus has largely been on just Day 1 to this point, we're basically talking about Act I, the first cutscene, Act II, and the second cutscene. The end of Day 1 is basically what I'm targeting for the first beta release. (Technically, it should probably be an alpha, but I have no idea what I'm doing anyway, so who cares.)
As it stands right now, I have just about all of the material needed for Day 1. This qualifies as Excellent. All of the characters and their animations are done, including the two cutscenes, although a lot of it still needs to be exported into DSQ files and then set up in the game. Once in the game, it is likely that we'll need to make a few adjustments here and there, but the mere fact that all of the material is sitting on my hard drive waiting to be implemented is quite exciting. Right now, N.R. is beginning work on the material for Day 2 (Act III), which is even more exciting, since I'm not sure if I ever truly expected to get past Day 1.
There is still the question of how to implement the PRAY command, however. In the text version of Vespers, PRAYing has an important impact on the game, and Jason did some creative things with it, particularly in the description of the effects on the player. I have a plan in mind to do something similar in this version that involves the use of Jeff Faust's AFX code for Torque, but that's not an easy system to digest. I'll probably include some temporary placeholder effects taken directly from his sample code while I spend the time learning the system and developing all new effects that are more appropriate to the game.
The main problem I'm confronted with right now is expanding the game code beyond Act I. I didn't do a lot of planning ahead when I first created the code structure for Vespers, partly because I didn't really have a firm grasp on the way Torque requires its code to be structured. I also didn't think much beyond Act I, anticipating that I would just figure it out when I eventually got there. Time to pay that debt, cowboy. It's going to require a whole mess of restructuring, and how to do that isn't completely clear yet. Admittedly, though, it's a fun problem to finally tackle.
As for this blog, my goal is to do more to keep things updated here. Since my spare time is limited, and I'd rather use it to work on the game than to write, I'll be focusing more on shorter entries. IndieCade once again is open for business, and I'd really like to have a work-in-progress submitted if possible, so time will definitely be tight. I have a few ideas for things to blog about, and I'll try to contribute regularly now to Screenshot Saturday, just to keep me honest. More to come. We'll see how it goes!
Now We're Getting Somewhere
20 Apr 11
Well, it certainly has been a while, hasn't it?
It is fair to say that the general lack of activity on this blog has been directly related to the lack of significant progress on Vespers. While much of that has been due to the inconsiderate intrusion of Real Life on the development process over the past, oh, 18 months or so, a fair share of the stagnation was also due to an unfortunate combination of bad luck, shortsightedness, and an incredibly exasperating game engine.
I'll conveniently ignore the former stuff, and expand just a bit on the latter.
An actual, honest-to-goodness screenshot of the cutscene. Seriously.
As I've discussed in earlier posts, most of what I've been focusing on since last fall (or so) has been the first cutscene, since the demo will be all of the action leading up to, and including, the first cutscene. Of course, in the original text version of Vespers there is no cutscene per se, but there is a short sequence of events that spans a few turns and which the player has no control over and cannot interrupt. So in a sense, it's a scene playing out over three or four turns regardless of what the player tries to do, which is really not that different from a short cutscene. So that's how I decided to implement it, despite all of the discussion on the interwebs over the past few years about how cutscenes are evil and kill puppies.
Rather than play a pre-rendered cutscene movie like some games, I wanted to have one rendered in-game, using the same character models used throughout the first Act, with some creative scene design, lighting, and camera manipulation thrown in. Not really a big problem conceptually, but reality doesn't often play nice with concept, and this situation was no different.
Now, rather than bore you with the details of all that went wrong over the past six months or so, let's just say that most of the issues could be traced back to three key things:
1. Some of the character models weren't originally set up exactly as I needed them to be; 2. The animator used a separate copy of each character in order to make the cutscene animations; and 3. The Torque Game Engine is very fussy about a lot of things when it comes to playing animation sequences.
Basically, in Torque, you create a character model, rig it with a "skeleton," and then create animation sequences for that skeleton. Different models can use the same skeleton, and any animation sequences developed for the skeleton will work with any model that uses that skeleton. The only requirement is that the skeleton must be constructed precisely the same way, down to the very last tiny little detail, for an animation sequence to work with it. Generally speaking, this is not a problem. But along came #2 above, and with it came some minor but undetected changes to skeletal structures that couldn't possibly get past #3 above. Some of these were easily correctable, some not so much. Extra time, workarounds, and so on, you get the picture.
There isn't a video of this anywhere...is there?
In the midst of this came the realization of #1 above, and the need to fix some of these seemingly minor but ultimately important model structure issues. But naturally, making changes to model and skeletal structures led me once again into the endless pit that is #3 above. So not only would I have to update and recreate the models and animations for the cutscene, but the same would apply to all of the animations for these characters for Act I. It became like a revolving door, round and round from the cutscene to Act I and back again.
With the additional constraints of time and life on top of everything else, it began to feel like I was on a Road to Nowhere at times.
Fortunately, I was able to find a few great people to help, people who know a lot more than I do about the baffling intersection between modeling, animation, and the Torque Engine. With a little persistence, a great deal of assistance, and a whole slew of questionable workarounds, I was finally able to push through it. And now we have a cutscene.
It still lacks a background musical score, which I'm in the process of working on, so overall it seems strangely quiet. But it's all there, it's all coded, and it runs smoothly from start to finish with all the right camera shots, pans, and sound effects. I'm quite relieved.
Now all I have to do is go back and re-export a whole mess of Act I animations...again.
All's Well That Ends Well?
21 Jan 11
Some encouraging news, for a change.
My last post, back in November (really?), discussed how the parent company behind the Torque Game Engine, the engine I'm using for Vespers, was shutting down the portion of the company responsible for engine development. I think a lot of people saw that coming. The original company, GarageGames, was a small, friendly, down-to-earth group of people that had a passion for helping other people make games, and it helped them build a strong game engine and a large, fairly devoted community. The employees spent a good deal of time on the forums interacting with the customers and developers, and this created a nice connection that a lot of people appreciated. Then things started changing. They expanded their product line, perhaps a bit too fast and a bit too wide, and ended up stretching themselves too thin. They changed their name from friendly GarageGames to the slightly weird and distinctly unfriendly TorquePowered. Focus began to shift to online gaming, away from their core of PC/Mac development. One by one, many of the original employees resigned to join other companies or pursue other opportunities. They were bought out by IAC, a large corporation, and while they tried to spin it to their advantage, there was no overcoming the sense that they had sold out. When they moved from cozy Eugene, Oregon to vapid Las Vegas, the transformation of the original company appeared to be complete.
It was a sad day when it was announced that the parent company overseeing Torque was shutting down its operations, but to be honest I think most people had already been saddened for some time by what appeared to be the prolonged and inevitable death of GarageGames.
Importantly, though, those of us who were still in the process of developing games with Torque engines – and who cringe at the prospect of porting to a new game engine – had to patiently wait to see what would happen to the Torque product line, and how it would affect licensing issues. (Of course, that would only be important to people who actually release finished games, so just pretend for now that it was of great concern to me.)
So with yesterday came the announcement of the rebirth of GarageGames. The company and the product line is now a subsidiary of Graham Software Development, and the decision was made to relaunch the company under their original name and with a commitment to return to its "indie roots." There is a renewed focus on the community, perhaps Torque's strongest asset, and a desire to make the Torque products more stable, more intuitive, and better documented. They're reducing their product line so that they can focus on fewer engines, and dropping the prices on all of their engines to $99 to celebrate.
This is all good news, of course, and it is comforting to know that licensing is no longer a concern. It's also good to know that I won't have to update the "GarageGames" logo on my splash screen, which I thankfully never updated to "TorquePowered".
Still, I'll view these events cautiously. GG is saying the right things, and I like that the focus is back on the community. That would be a wise move. But it's not like we haven't heard much of this before; better documentation has been an issue with Torque products for years, and has been promised many times. There is still the fact that many of the original GG guys have moved on to other pursuits, and they're not only still in Vegas, they're moving into an even larger office building. Their image has taken a multitude of hits over the past few years, and it will take some work to repair that.
But they do have two big advantages in their product line and their large community, and full access to the source code at such a low entry price is very good. It's good to see GG back and on what appears to be the right track. We'll have to see where they take it this time.
Whither (Wither?) Torque
12 Nov 10
Thanks to Rampant Coyote for bringing this to my attention, but for those of you who haven't heard, InstantAction has decided to shut down its operations. While this is certainly sad news for a number of people who will be out of work, a lot of you are probably saying, "Who?" The truth is that I'm not sure I could accurately explain exactly how this relates to me, even though it does.
Whither (Wither?) Torque
12 Nov 10
Thanks to Rampant Coyote for bringing this to my attention, but for those of you who haven't heard, InstantAction has decided to shut down its operations. While this is certainly sad news for a number of people who will be out of work, a lot of you are probably saying, "Who?" The truth is that I'm not sure I could accurately explain exactly how this relates to me, even though it does.
About three years ago, GarageGames – the company responsible for developing and selling the Torque Game Engine (TGE), the 3D engine I'm using to make Vespers – announced a 'partnership' with InterActive Corporation (IAC), which is just another way of saying that GarageGames was bought out by IAC. The idea, at least as I understand it, was to redirect the development of the Torque line of game engine products to support a new gaming platform called InstantAction. I never really played around with InstantAction, but basically it was something akin to a web-based console where players could play various 2D or 3D games, most of which would presumably be made with Torque products. Continued effort was put into developing the various lines of Torque engines, but a lot of it was banking on InstantAction becoming a popular and profitable gaming portal. In the meantime, GarageGames re-branded themselves as TorquePowered, and after some time moved away from their origins in cozy Eugene, OR to, of all places, Las Vegas. Turns out the move was basically a metaphor of what was happening to GarageGames as a whole, as it evolved from a small, friendly, close-knit group to a larger, more faceless, corporate presence.
The guys at TorquePowered tried hard to put a pretty face on those developments, but the Torque community was largely wary and suspicious, and in the end they were probably right to be. Nobody can say for sure if GarageGames could have continued to survive without being bought out by IAC, but there's no arguing that those events forever changed the company and their relationship with their community.
It's hard for me to say what exactly it means that InstantAction, IAC's flagship online gaming portal, has gone belly-up, at least with respect to the Torque engine. I don't have any familiarity with IAC or its subsidiaries, but it seems that the entity that InstantAction represented must have had ownership of the Torque line of products, since today's announcement was that "Torquepowered.com will continue to operate while InstantAction explores opportunities with potential buyers for Torque." So InstantAction, as a company, apparently owns the Torque product line, and now we're seeing the demise of InstantAction. So it goes.
Whatever the case may be, this means that TGE, the core engine of Vespers, is now officially in limbo, its future uncertain.
The ultimate impact is likely to be minimal, but I can't say for sure. The most likely scenario is that some company will buy the Torque line and continue to honor the current licenses. You never know, though, and it's a little harder to predict what will happen specifically to TGE (the engine I'm using, not their newer, fancier engines), since it's an older, out-of-date product that wasn't even being supported by TorquePowered (nee GarageGames) anymore. We'll probably know more in the coming days and weeks.
I can't help but think of a time, probably around five years ago, when I was about to embark on this project, and I was looking for a game engine to use. I had narrowed it down at the time to the Torque Game Engine and the Unity Engine. I liked Unity specifically because it was Mac-based, but at the time it was still very young and its future was not well outlined; its community was also small and there were plenty of engine features that had not yet been implemented. TGE, on the other hand, had a more mature code base and its community was quite large and helpful. Plus, it was cross-platform. I chose TGE, but I always kept an eye on Unity.
Unity is now thriving, of course, and is probably the leading indie game engine out there. TGE, on the other hand, is outdated, no longer supported, and is now adrift at sea.
Yes, it looks like I chose Betamax. Ah, well. We'll see what happens from here, but I'll keep plugging away.
Time...Marches On
29 Oct 10
So last night was the latest Utah Indie Gamer night, and I couldn't make it. Bums me out a bit, because I enjoy connecting with those folks and following along with some of their projects, especially Jay Barnson's Frayed Knights. At the same time, though, each successive gathering just seems to highlight the fact that I still haven't reached any major milestones on this project.
Time...Marches On
29 Oct 10
So last night was the latest Utah Indie Gamer night, and I couldn't make it. Bums me out a bit, because I enjoy connecting with those folks and following along with some of their projects, especially Jay Barnson's Frayed Knights. At the same time, though, each successive gathering just seems to highlight the fact that I still haven't reached any major milestones on this project.
It's now the end of October, and still no Vespers. Still no demo. Seriously, what gives?
Fine, so four and a half years into the project, I'm willing to admit it's taking slightly longer than anticipated. It was a struggle to finally reach that conclusion, but there you have it. I thought I was choosing a relatively small, concise project for my first go at 3D/IF, but I suppose choosing a project should probably be kind of like packing for a long trip – set out what you think you'll need, and then eliminate half of it. "What you want it to be" is probably a lot more than "what it really should be," no matter what your starting point is.
This is my hobby, so while it tends to consume me at times, it still falls relatively low on the Life Priority scale, even when there are deadlines approaching. And I'm still highly dependent on others for needed content, and those deadlines don't necessarily apply to them. Nevertheless, we continue the slow, plodding, inevitable march forward. Oh yes, it is inevitable. Like erectile dysfunction or a colonoscopy, it's coming whether you like it or not.
I've made no attempt to hide the fact that animation has been the greatest challenge of this project. Hard to imagine how many different animators have come and gone on this project, but let's face it: this is not your typical 3D first-person animation job.
That said, I did find a wee bit of stability with one animator, Kevin Grove. New to the project, Kevin took on the unenviable job of animating Cecilia during the first Act, which is anything but a simple task. Unlike the other characters, Cecilia exists in multiple stages throughout Act I, so there are different root poses, different meshes, and a number of sequences that have to be timed and positioned just right. Very different from the other characters to this point. I'll go into that more in a later post.
Kevin was just what I needed, and he slowly worked his way through all of Cecilia's animations for Act I. This was incredibly tedious work, with a lot of back-and-forth between us so we could get things just right. I still have a number of animations to implement in the game, but it's a relief to know all of the content is there for Act I now. It's all just a matter of putting it together within the game.
Same goes for the first cutscene, which is the longest and most involved of the cutscenes. Fortunately, my other animator, Lem, came back into the fold long enough to knock out all of those animations. This was a seriously complex task, requiring him to animate four characters in the same scene, all interacting with each other, while following a storyboard. The results look fantastic so far.
But it's not just the animators holding things up, really; it's the whole Torque animation system, starting with the exporting of animations as separate files (.DSQ files) from the modeling and animation software, and ending with the proper loading and execution of those animations in the game. It should be the easiest part of the process (compared with animation development itself), but the reality is that Torque's animation system is old, cryptic, and unpredictable. Animations may or may not work when exported, body parts may fly in unexpected directions (if they appear at all), and results may look different even just on successive playthroughs. Documentation on the process is nearly nonexistent. It's maddening at times; in fact, seeing animations work they way they're supposed to is uncommon enough to be surprising. The instant you think you're getting the hang of it is the moment Torque throws something completely new and baffling at you, knocking you back down to earth.
The good news is that content is slowly but surely getting done, and I have enough content at this point to essentially finish the demo, which will consist of Act I and the first cutscene. I've been working with N.R. to finish the remainder of the modeling content for the rest of the game, and although we're close, things may slow down as he concentrates on other work. The problem, as always, will be the animation. But I have an idea about that, and I'll talk about it more on a later post.
Adventures with NPCs Redux: Lucca
28 May 10
Here we resume our efforts to bring our NPCs to life, beginning with bits and pieces of text from the IF version of Vespers and ending with a modeled, animated, and voice-acted 3D character. Last time I discussed the development of Constantin, the large hulking monk with a short temper. This time I relate the development of Lucca, who had some interesting and unique challenges of his own.
Adventures with NPCs Redux: Lucca
28 May 10
Here we resume our efforts to bring our NPCs to life, beginning with bits and pieces of text from the IF version of Vespers and ending with a modeled, animated, and voice-acted 3D character. Last time I discussed the development of Constantin, the large hulking monk with a short temper. This time I relate the development of Lucca, who had some interesting and unique challenges of his own.
Lucca was going to be a tough character to convincingly recreate. He's the youngest member of the monastery, a teenager who recently joined the order. He's very attached to Matteo, one of the monastery's father figures, and is generally an emotional character during the course of the game. Again, we didn't have a lot of text to go on initially aside from a short description:
The youngest of those who remain, Lucca joined the monastery only a few short months ago. The son of a count, he had never seen death before the arrival of the plague. It haunts him.
After some discussion between myself and Jason Devlin (the author), we decided we wanted Lucca to have pale skin (maybe slightly paler than the rest), blue eyes, and delicate facial features; probably quite frail overall with a slight build and thin face. We presented these ideas to N.R. Bharathae, our lead artist, who came up with his concept for Lucca.
Figure 1. Lucca (with Matteo) concept sketch.
This looked like a perfect starting point. Using this, N.R. designed Lucca's 3D model and then applied some of his slick textures. As with the others, we were going for a more realistic appearance for our characters. N.R. did a great job with him.
Figure 2. Lucca textures.
Figure 3. The Lucca model.
During this time, we continued in our task of finding and recording a voice actor for the part. Matching a voice for a young man would not be as difficult as for some other parts, but the real challenge was finding someone who could play the part convincingly, given that Lucca expresses a great deal of tearful emotion during the game. Fortunately, we were able to find Christopher LeCluyse.
Christopher is a veteran of the stage, both acting and singing. Not only that, he also has expertise in medieval literature, and was able to help out with some little-known facts and inconsistencies in our story. For instance, Christopher pointed out to us that, during the time period of our game (ca. 1300-1400), pews did not yet exist in churches -- only choir stalls. So we were able to make that adjustment in our storyline and setting.
Figure 4. Christopher and Lucca.
"Christopher LeCluyse (Lucca) brings to Vespers twenty years of professional vocal training and performance and a doctorate in medieval language and literature. He sings regularly with a variety of choral and early music groups and has appeared on recordings with Conspirare. Chris is also a professor of English and writing center director at Westminster College in Salt Lake City." -- C.L.
Finally, there's the work of our animators. Lucca presented a different kind of challenge than the previous characters, because we wanted to try something a little more complex with the way he idles. At the beginning of the game, Lucca is first seen running into Matteo's room in the dormitory, where he then scrabbles frantically at the ground, trying to unearth one of the stones in the floor:
Matteo's Room
This room is small: the same as all the others. A bed is pushed up against one wall, opposite the door to the north.
Lucca scrabbles frantically at the ground, his blood staining the stones.
>EXAMINE GROUND Lucca scrabbles at the stone, trying desperately to unearth it from all sides.
>TALK TO LUCCA "Why do you dig, Lucca?" you ask.
"Matteo is hiding something. I just know it's under here."
>AGAIN "Why do you think that?" The blood pours from his fingers.
"I just know," he sobs. "He scrapes around here at night."
>AGAIN "Leave me alone," he blubbers through the tear-laden mucus that streams from his nose.
>ASK LUCCA ABOUT MATTEO "He knows something, but he won't tell me," he sobs more heavily for a moment. "He tells me nothing anymore."
My thought was to have Lucca idle using a cyclic sequence, showing him repeatedly scraping at the stone in the floor. But playing this sequence over and over again, without any alteration, would quickly get old and not look very professional. My thought was to try and break the monotony by including a few additional idle sequences played at random points during the cyclic sequence -- one trying to pull up the stone, one showing him rubbing his bloody hands, and another showing him wiping the tears from his eyes. That means four idle sequences -- one cyclic and three non-cyclic. All need to be designed using the root position as a launching point for any speech animations called from player interaction:
- Figure 5. Modifications to the usual animation flow sequence to accomodate additional idle sequences.
What the hell does all that mean? Basically, only that each sequence -- whether it's an idle sequence or speech sequence -- has to start and finish in the root position to maintain consistency. The thing we need to keep in mind is that speech can be triggered during the cyclic idle sequence or during one of the other idle sequences and to account for that. Once a speech animation is finished, we always return to the cyclic idle sequence and start again. It can look a little robotic at times, but overall I think it works well.
Here is the text portion of the game given above, as we developed it in 3D with animation and sound. This is from an older video on Google.
Figure 6. Lucca in action.
So that's how we went through the process of developing Lucca from a text character in an interactive fiction game into a 3D animated and speaking NPC model -- a nice combination of writing, modeling, texturing, animating, and voice work. Next time I'll introduce Ignatius, one of the more mysterious and suspicious characters in the game.
Not Your Mother's Integrated Graphics
29 Apr 10
One of the things I noticed when I posted the request for beta testers is that a number of interested people didn't quite have the system specs I believed were needed to run the game smoothly – namely, a dedicated graphics card with a decent amount of video RAM. Systems with integrated graphics chips, at least in my mind, have not traditionally handled fairly intensive 3D games very well, hence the decision to exclude those systems, at least at the start.
Not Your Mother's Integrated Graphics
29 Apr 10
One of the things I noticed when I posted the request for beta testers is that a number of interested people didn't quite have the system specs I believed were needed to run the game smoothly – namely, a dedicated graphics card with a decent amount of video RAM. Systems with integrated graphics chips, at least in my mind, have not traditionally handled fairly intensive 3D games very well, hence the decision to exclude those systems, at least at the start.
That, and I didn't have access to a decent system with an integrated graphics chip to test the game. That has now changed.
I've been wanting to upgrade my little server box for a while now, and with Apple's recent tax-free sales event, I decided to make the leap and bought myself a tax-free Mac Mini. It's a bottom-of-the-line model, although the specs have reached the point where they begin to put my old G5 desktop to shame: 2.26GHz Intel Core 2 Duo with an NVIDIA GeForce 9400M graphics chip. It's a sweet little machine, with more than enough power for my server needs. Plus, it's just an amazing piece of technologic design. It's incredibly compact, and it is absolutely, positively silent. No fan noise, no hard drive clicking. I can hardly believe the thing is powered on. I love the little bugger.
But surely there's no way it could handle the hulking behemoth that is Vespers.
Naturally, this is the first thing I wanted to try once I got the sucker booted up and organized. Doubtless, once the opening sequence started, the frame rate would freeze up and I'd struggle just to quit the application.
Quite the contrary, actually. For the most part, the game seemed to run at least as smoothly – if not better – than my old desktop with the fancy schmancy dedicated ATI graphics card. Frame rates in many cases exceeded what I was getting on the older machine.
A few caveats: I was running the game at a very small screen resolution, and it did struggle off and on during the early stages of play. I'm not sure if that was related to loading the massive pile of textures into memory (which, on the Mini, the chip shares with the main memory) or just from ongoing background processes, but after a couple of minutes of play all the lag disappeared and it ran about as smoothly as I've seen it anywhere.
I'll have to do some retesting and profiling to see what's going on, but the results are pretty encouraging. Apparently, integrated graphics chips have come a long way since I last checked.
So if you're one of those who is still interested in testing, and you have a (relatively recent) system that uses an integrated graphics chip, let me know and we'll see how things go.
Adventures with NPCs Redux: Constantin
26 Apr 10
We continue on with our efforts to bring our NPCs to life, beginning with bits and pieces of text from the IF version of Vespers and ending with a modeled, animated, and voice-acted 3D character. Last time I discussed the development of Matteo, the oldest monk at the monastery; the second character we tackled was Constantin, who had some interesting and unique challenges of his own.
Adventures with NPCs Redux: Constantin
26 Apr 10
We continue on with our efforts to bring our NPCs to life, beginning with bits and pieces of text from the IF version of Vespers and ending with a modeled, animated, and voice-acted 3D character. Last time I discussed the development of Matteo, the oldest monk at the monastery; the second character we tackled was Constantin, who had some interesting and unique challenges of his own.
We started out with a very general picture of Constantin; he's middle-aged, a handyman around the monastery (he was a former blacksmith), and a notably large man with a short temper. Again, we didn't have a lot of text to go on initially aside from a short description (which was actually removed from the game prior to the final release):
An enormous, hulking man, Constantin is taking the lack of food worse than the rest of the brothers. The former blacksmith has taken to religious life quite well and has assumed the responsibilities of almoner and cellarer since those two brothers died.
After some discussion between myself and Jason Devlin (the author), we decided we wanted Constantin to look extremely large, but not quite like a giant; not fat, but certainly heavy and imposing. We presented these ideas to N.R. Bharathae, our lead artist, who came up with his concept for Matteo.
Constantin concept art.
Seemed just right to me. With this as his starting point, N.R. designed Constantin's 3D model and then applied some slick textures. As before, we were going for a more realistic appearance for our characters, and N.R. came through for us again.
Constantin textures.
Constantin starts out the game sitting on a chair in his room, skinning a hare with his knife. So to get him ready for the game, we had to outfit him with the appropriate objects.
The Constantin model.
While N.R. was working on this, we also had the task of finding and recording a voice actor for the part. Trying to match a voice to a character like Constantin was not easy; we needed an actor who could really fit the part of a large, short-tempered man with an appropriately deep voice. The man we found to play the part was Jason Nacey.
Jason didn't have any real experience with voice acting prior to this, but he had been exposed to it through the work of his father. It was actually his father who heard about our voice auditions, and who passed the information along to Jason. Although it seemed a little awkward at first, Jason ended up doing a great job, and I think his voice fits the part perfectly. Here's a shot of Jason alongside Constantin, followed by a short bio he wrote.
Jason and Constantin.
"I have always been fascinated by a voice actors' ability to create a story by the sound, inflection, and timber of their voice. I often spend time driving my wife and 5 kids around in our minivan. We ordered our latest van with a DVD player for the kids. Without the benefit of video on long drives, I am able to really tune into the actors voices, and in this way I really became a student of the professionals like Nathan Lane (Lion King), Jason Lee (The Incredibles) and John Ratzenberger (what hasn't he done?!) to name a few. I have thought for a long time that to be able to take on that challenge would be fun and exciting. It was from my father that I first heard about the auditions for the voice parts for Vespers. Having had no previous experience with any formal voice acting, I went to the audition with no thought of actually landing a part, but I was very excited to just try and maybe, afterwards, be able to get constructive criticism on how I could improve my abilities. I was extremely nervous for the audition, and almost called and canceled so that I would perhaps save myself serious embarrassment. I finally resolved that everyone there would be strangers, and if I was going to stink up the place - dammit - I was going to it LOUDLY! I was elated to find out that I was chosen for the part of Constantin. And I look forward to many more opportunities to have this much fun again." -- Jason Nacey
Finally, there's the work of our animators. We were still familiarizing ourselves with Torque's animation system while working on Constantin, so it took us some time to work out the kinks to produce what we wanted. Unlike Matteo, we wanted Constantin to play a looping idle animation; as mentioned above, when first encountered, Constantin is sitting in his room skinning a hare with his knife. So we needed a system where we could play this looping animation continuously, while also offering us the ability to choose one of two things for his speech animations: (a) interrupt the idle sequence to play a full body sequence in response, or (b) continue the looping idle sequence while playing a mouth/head animation on top of it.
To do this, we designed it so that some speech animations are full body animations (played with setActionThread), while others are blend animations (played with playThread). Then we set up our Sequence Manager to recognize which was which, and when it needed to to stop the idle animation before playing a speech animation.
As an example, here is a short portion taken from the text version of Vespers, with the player's commands in bold caps:
Constantin's Room Constantin is one of the few brothers with anything in his room besides a bed. A few tools lay next to the door in the northwest; remnants of his life as a blacksmith. A smell lingers here: a sour smell.
Brother Constantin sits on the bed, a young hare dangling from his hand. His knife moves swiftly.
>TALK TO CONSTANTIN "What do you have there, Constantin?" you ask, leaning forward.
"Something to eat," he grunts.
>AGAIN "Is there no food left in the cellar?" He flinches slightly.
"No. There is nothing in the cellar."
>AGAIN "Well, be sure to tell us when you are finished. We are all hungry."
"I will."
>ASK CONSTANTIN ABOUT CELLAR "What?" he startles. "I'll get around to taking the lock off. There's no food left down there anyway." His eyes darken as they meet yours. "There's no reason to go down there anymore."
And here is the same portion of the game, as we developed it in 3D with animation and sound:
Hopefully that gives you all some idea how we went through the process of developing Constantin from a character in an interactive fiction game into a 3D animated and speaking NPC model. The final result, I think, is a nice combination of writing, modeling, texturing, animating, and voice work, the combined work of a group of really dedicated and talented people. Next time I'll introduce Lucca, the youngest member of the monastery and a character with challenges of his own.
Adventures with NPCs Redux: Matteo
4 Apr 10
Things have been moving forward lately with our NPC development, which has been a very gratifying experience. Watching a character go from a text description to a fully animated and speaking NPC model is something else. And as we move from one character to the next, incorporating each into the game, the whole project really starts to come to life. It sure as hell beats plugging away night after night on the nuances of text parsing.
Adventures with NPCs Redux: Matteo
4 Apr 10
Things have been moving forward lately with our NPC development, which has been a very gratifying experience. Watching a character go from a text description to a fully animated and speaking NPC model is something else. And as we move from one character to the next, incorporating each into the game, the whole project really starts to come to life. It sure as hell beats plugging away night after night on the nuances of text parsing.
It takes a lot of steps to go from point A to point B, and a number of people to make it happen, so I thought it might be interesting to review the procedure we went through for each NPC in the game. Vespers has six NPCs: five brothers and one village girl. This way, we can introduce each character while providing a little insight into our development process.
Matteo was the first character we tackled, mostly because he has the smallest part in the game. In the text version of the game, however, there are very few detailed descriptions of the characters, so we didn't have a lot to go on initially. The one passage in the game that gives some background on his character (which, interestingly, was later removed for the final release) went as follows:
"Ah, Matteo. He was one of the first. Although he is a few years your senior, he remains obedient and helpful. He loves Saint Cuthbert's, almost as much as you. The loss of the brothers has been especially hard for him. He was as much a father to them as any priest."
So we began with an older, gentle, fatherly figure, and after some discussion with Jason Devlin (the author), we also decided on a person who is shorter and overweight. We presented this to N.R. Bharathae, our lead artist, who came up with his concept for Matteo.
Matteo concept sketch.
Once we had a good starting point, N.R. set to creating and revising the 3D model, and then applying the textures. We were going for a more realistic appearance to our models and, needless to say, we were very excited with the results.
The Matteo model.
The textures for Matteo's face.
While this was going on, I was also working hard on the voice recordings. After a long process of auditions, I went through the difficult tasks of preparing the scripts, setting up and performing the recording sessions, and then splicing and editing each of the lines into separate WAV and OGG files.
Fortunately, we were able to get a really talented actor, Alan Meyer, to do the voice work for Matteo. I asked each of our voice actors for a head shot, since I thought it would be cool to see each of them beside their final in-game NPC model. Here's a shot of Alan alongside Matteo, along with a short bio he wrote.
Alan and Matteo. I can see the resemblance.
"As a voice actor, Alan Meyer enjoyed playing a role in Vespers tremendously. During his three decade acting career Alan has appeared in dozens of plays and films. He taught theater and video production classes at Bonneville High, in Ogden, Utah, for over fifteen years. His website Speakingpart.com features his voice acting demos and current resume."
Finally, bringing him to life was our animator, Shawn Hall. Shawn was new to the Torque system of animation (as was I, of course), so it took us a little while to work out the kinks and the best workflow process. But once we were both comfortable with it, he was able to really breathe life into the model. It's not easy to show here, but Shawn did a great job with a lot of the little details, including blinking, eyebrow movement, and even some lip sync. We ended up using mostly full body animations for Matteo (unlike some of the other NPCs), since we found little need for additional blend animations. (Shawn has since moved on from the project, but this was all the animation Matteo would need in the game.)
The final result, I think, is a great combination of writing, modeling, texturing, animating, and voice work, the combined work of a small group of really dedicated and talented people. Cue the brief video, for those interested (and sorry for the poor quality – if you watch it at 480p it's slightly better):
Hopefully that gives you all some idea how we went through the process of developing Matteo from a character in an interactive fiction game into a 3D animated and speaking NPC model. Next time I'll introduce Constantin, who presented a series of challenges of his own.
Looking Back, Looking Ahead
2 Apr 10
We've been making some good progress lately on Cecilia, the last of the six NPCs to be implemented in the game, so I thought this would be a good opportunity to bring back the old NPC introductions. This was something I started a long time ago — well before starting this blog, back when I was blogging only on GarageGames. The idea was to write an introduction to each of the characters in the game, showing their development from concept drawing to a fully modeled, animated, and voice-acted 3D NPC. I got through the first two characters, Matteo and Constantin, fairly early on. But as animation problems surfaced (and resurfaced), work slowed down. I was able to get to Lucca and Ignatius eventually, but that was about it. I did finally get Drogo implemented after a long delay, but never did get around to his introduction.
Looking Back, Looking Ahead
2 Apr 10
We've been making some good progress lately on Cecilia, the last of the six NPCs to be implemented in the game, so I thought this would be a good opportunity to bring back the old NPC introductions. This was something I started a long time ago — well before starting this blog, back when I was blogging only on GarageGames. The idea was to write an introduction to each of the characters in the game, showing their development from concept drawing to a fully modeled, animated, and voice-acted 3D NPC. I got through the first two characters, Matteo and Constantin, fairly early on. But as animation problems surfaced (and resurfaced), work slowed down. I was able to get to Lucca and Ignatius eventually, but that was about it. I did finally get Drogo implemented after a long delay, but never did get around to his introduction.
At last, all six characters have been implemented, so I can complete that bit of unfinished business and give Drogo and Cecilia the introductions they've been pestering me about.
Instead of just doing those two, and because the earlier introductions were just so damn long ago, I thought it would be a good idea to bring back the entire set and start from the beginning again, with Matteo. Then, at last, we can have all six presented in sequence, as originally planned.
Some of the information is a bit outdated, and as such I may do a wee bit of editing, but for the most part I'll just present the older ones as is before finally getting to the recent ones. It's just one way to introduce each of the characters while providing a little bit of insight into our development process.
I hope you'll enjoy it!
End of March Vespers Update (or, How To Drop A Girl)
31 Mar 10
March comes, March goes. Lion, lamb, all the usual stuff.
End of March Vespers Update (or, How To Drop A Girl)
31 Mar 10
March comes, March goes. Lion, lamb, all the usual stuff.
March is always a busy month, what with GDC and sundry work-related conferences and travels. And this year, of course, there was PAX East. Man, how I wanted to be there for that. It was, by still rare accounts, an amazing show of force by the IF community, and from what I can tell a great time was had by all. It sounds like there was a groundswell of new or renewed interest in IF, which can only be a Good Thing. And, of course, GET LAMP. I can't help but feel like I missed a significant event in IF and the opportunity to meet some great folks, but at the same time I am excited that it occurred and grateful that there are those who could make something like that happen.
Making things happen is a good theme to maintain, so let's do that.
The last of the six NPCs we are bringing to life is Cecilia, the girl who suddenly appears at the monastery and...well, you either know what happens next or you don't, and that's not about to change now. There's a reason I had saved her for last, though, and it's not because she's the easiest.
The main problem with Cecilia is that she doesn't conform to the usual NPC implementation pattern. For most NPCs, each Act (mostly) consists of a simple set of idle animations and an extended set of conversation animations. The character typically stays in one location (Matteo in the tower, Constantin in his room, etc.), doing his own thing, and responding to the occasional player question. Pretty straightforward.
Cecilia, of course, makes things far more difficult and challenging. (I could mention at this point that this is partly why we made her a redhead, but I know far better than to do that.)
The main reason is that there is a portion of Act I where Cecilia acts like an object rather than an NPC per se. Without giving too much away, the idea is that, after she collapses at the front door, the player is supposed to pick her up and carry her to the locutory to be placed on the bed there. That means I have to implement her in two additional forms that are different than the usual NPC: as an inventory object (so she shows up in the visual inventory while being carried), and as an object that Torque calls a "ShapeBaseImage" – an object that mounts to the player and is displayed as part of the HUD in first-person mode, the same way a gun would appear in the camera view in an FPS game.
Cool, but what happens when you hit the "fire" button?
Neither of these is particularly challenging, though; just time consuming, and the implementation requires special code coordination to make sure it handles each of those correctly.
The real challenge occurs when you consider that, while being carried, she should be handled just like any other inventory object. Which means she should be able to be dropped at any time.
Dropping creates all kind of issues in a 3D first-person game. When you drop something, where do you drop it? In front of the player? Directly at the player's feet? Do you want to show the object falling to the ground, or just make it appear on the ground immediately? What happens if the player is standing right in front of another object, and there is no room to drop it? What if the player is standing directly in front of a wall? What if the player wants to drop the object on the bed, but isn't facing the bed at that time?
A closeup of Cecilia as "inventory object". It's dehumanizing, I know.
Another part of the equation is that NPC objects have collision boxes, just like the Player's object has. So when you drop the girl, her collision box immediately interacts with the player's collision box, causing all kinds of havoc. That requires all sorts of workarounds to make sure the collision boxes don't interact, but that, in turn, tends to complicate other matters.
On top of that, rather than just teleporting her static body immediately to the ground near the player (or the bed), I'd like to give the whole process a bit of life by including an animation that shows her hitting the surface and coming to rest in her idle position. That means timing the whole process of dropping, starting the animation, and hitting the floor.
So in the end, we've taken the relatively simple process in IF of dropping an inventory item and proceeded to make it horrendously complicated. Go team!
More on Cecilia to come.
Long Flights Are Good For Something
22 Mar 10
One thing long flights are good for is addressing old issues that you've always meant to fix but never really got around to. So when I found myself on a three-and-a-half hour flight yesterday, I decided it was time to tackle an old parser syntax issue that has been nagging at me for some time.
Long Flights Are Good For Something
22 Mar 10
One thing long flights are good for is addressing old issues that you've always meant to fix but never really got around to. So when I found myself on a three-and-a-half hour flight yesterday, I decided it was time to tackle an old parser syntax issue that has been nagging at me for some time.
My goal with the parser has always been to make it as robust as possible, even if much of the functionality isn't necessarily used in Vespers -- I'd hate to have to add functionality after the fact, like for a future game. So the idea was to develop the parser to provide at least the typical performance one might expect from a TADS or Inform game. Most of the early months of development were spent on engineering the parser, and it was quite the battle. Hard to say for sure, but I'd say I got about 85% of the way there.
One of the missing pieces was being able to parse a command using the syntax VERB CREATURE NOUN. For instance, SHOW CECILIA THE KEYS.
The easier form of the syntax is VERB NOUN 'TO' CREATURE, as in SHOW THE KEYS TO CECILIA. The presence of the preposition (TO) helpfully divides the two tokens in the command. The way I implemented the parser, after first parsing and removing the verb, I scan the remainder of the command until I hit either a preposition or the end of the command; the words collected from that scan compose the token. In the example above, THE KEYS would make up the token that comes before the preposition TO; everything after the preposition (CECILIA) makes up the following token. Then I would proceed to figure out what objects the two tokens were referring to.
The problem occurs when there is no preposition, but I'm expecting two consecutive nouns. So if the command is SHOW CECILIA THE KEYS, the parser would grab the entire phrase CECILIA THE KEYS as a single token. Actually, I automatically remove all occurrences of the definite article THE, so the token would really be CECILIA KEYS, which would be handled the same way as something like GOLD KEYS or SHINY KEYS. So the parser would look for an object called CECILIA KEYS, and then proceed to throw up.
Fixing that to allow the alternative syntax was something I always knew was important and would have to be done, although there aren't many game verbs that require this syntax. Off the top of my head, I can think of SHOW, GIVE, and FEED, although I know there are more. On top of that, it doesn't really come up much in Vespers, except for a couple of times. But it's a good example of a syntax that people often use, and in a text game the parser should really be able to handle it gracefully since, without it, the error message is unlikely to be helpful ("You don't see any such thing." Say what?). Then, naturally, people will point fingers and say "See? This is why we don't have text games anymore."
I knew it was going to be a challenge, mostly because the parser code is a large, unwieldy beast, and on top of that, I haven't really looked at it closely for a good long time. Enter the three-and-a-half hour long flight, and we have a golden opportunity to reorient, refamiliarize, and figure this thing out.
As it turns out, the whole thing needed a grand total of three lines of code.
The way I handled it before, if I was trying to match a NOUN in the syntax and I had a token consisting of a bunch of words from the command to match it to, I would find the closest match and count how many words in the command were matched. If there were leftover words that weren't part of the match, that meant something was wrong and the syntax shouldn't match -- so I aborted that syntax and moved on to the next one. So in the case of the command SHOW CECILIA THE KEYS, the token would be CECILIA KEYS, and I'd be able to match CECILIA with the word KEYS left over. The leftover word would cause the syntax to fail, and we'd move on to try the next syntax for the verb.
Since I already had the code in place to count the number of words in the token that were matched, all I needed to do was reset the number of words in the token to the number of words that were matched. So in the CECILIA KEYS example, the number of words in the token is 2, but the number of words matched is only 1. So I tell the parser that the correct number of words in the token is actually 1 (not 2), and the remainder of the token is kept for the next round of token matching. Add in a quick check to see if the next syntax word is a NOUN or HELD object, and that's all I needed to add.
%nextSynWord = %syntaxWord[%currentSynWordNum+1];
if ((%nextSynWord $= "noun") || (%nextSynWord $= "held")) {
%nouns = %nouns - %numMatchWords;
}
That left plenty of time to watch "Fantastic Mr. Fox", too. Nice flick.
Sweet, Sweet Posters
3 Mar 10
Every once in a while you come across something that reminds you how awesome the intertubes can be. Zazzle is one of those things.
Sweet, Sweet Posters
3 Mar 10
Every once in a while you come across something that reminds you how awesome the intertubes can be. Zazzle is one of those things.
Sure, more people probably know about Cafepress, and this sort of thing has been around for a while already. Making a custom T-shirt or mug with your own artwork is no revelation, for sure. But over the years it has developed into a pretty slick process, and it's pretty cool how easy and fast it is to whip up a prototype of something, order it, and have it delivered to your door. The process has basically become how people imagined it should be. Pick the item you want, upload your artwork, fiddle around with it until it's just right, and order that sucker right up. And the fact that these places allow you to order even a single copy of your item, rather than mandating cartons full of them, opens up the market to just about anyone.
I was going to use CafePress to print some Vespers T-shirts for the crew helping out with the game, but someone recommended I give Zazzle a try instead. They're pretty similar, but there are a few things I like a little better about Zazzle. So I went with them, and I had a few shirts printed up. Small "ORS" logo on the front breast, larger Vespers logo on the back with the blood stain. Simple design, easy to set up, bing, bang, boom. Vespers shirts for all. Yay Zazzle.
You know you want one. Just say the word.
Yeah, I feel a little goofy wearing this around, but hey, it's my own freaking shirt, you know? (Funny story about the tag line. I think it was Jason, the game's author, who felt we needed to have a tag line to go along with the blood stain logo, but none of us could come up with something that didn't sound embarrassingly bad. He finally came up with "Say your prayers" which, I have to say, is both incredibly corny and perfectly brilliant. Get it? Say your prayers? See the double meaning? Awesome, right? No? Meh, never mind.)
By the way, if anyone out there feels the aching desire (without the accompanying embarrassment) to wear one of these around town, let me know and I can make it available on the Zazzle site. Ponder for a moment how much coolness awaits you.
Anyway, this isn't about the shirt. It's about the posters. Ah, the sweet, sweet posters.
One of the cool things I always liked about Jason's Vespers is how many of the items in the church morph over time as the monastery sinks into evil darkness. One of the best: the frescoes painted on the church ceiling. They aren't described in much detail in the game, starting out as follows:
>EXAMINE FRESCO
The soaring vaults are as vast and open as the arms of God. Frescoes depict the fall of Satan, with angels singing as they cut down the wicked.
That left us a lot of room to interpret, but you get the picture. As the game progresses, the image changes, reflecting the worsening struggle between good and evil, angels and demons. So for instance, at some point in the middle of the game (not really a spoiler):
>EXAMINE FRESCO
The Fallen are overrunning the angels, climbing through holes in the ground and spreading across the Earth. An angel's eyes meet yours and do not break. He is coming.
So this presented an opportunity and challenge for us in depicting the fresco and the changes that occur over time. Part of the problem is that we couldn't realistically put the frescoes on the church ceiling, since it's just too high up to see very well in the game. So we came up with an alternative, which was to have the frescoes painted on the walls of the church foyer.
Behold, the fresco. Click to enlarge.
Anyway, the big challenge, of course, was to find someone who could actually, you know, make a fresco. I mean, that's not easy. People don't make frescoes very often these days. You don't want someone just whipping together a little somethin-somethin and calling that a fresco. It has to be at least partially convincing. If I had the big AAA budget, we'd be looking for someone to research the artwork of the time in order to make a historically accurate rendering. Since it was just me working with the C- budget, I did most of the (hack) research on my own–using works by Giotto and Signorelli as a guide–and gave the information to a few prospective candidates from the most excellent ConceptArt.org, crossing my fingers.
The call was answered, quite impressively I would say, by Régis Moulun, a French artist. Here's his gallery site, if you're interested.
The art majors out there may look at these (eventually, when the time comes) and argue about the stylistic accuracy, but in my decidedly unartistic view, the frescoes he created simply kick ass.
Not to give too much away, but there are a half dozen of them. The one you can see in the image above is the first fresco, the one described as "angels singing as they cut down the wicked." It's beautiful, but it's the tamest of the lot. They get progressively more disturbing, and I love it. Here's a better view of the first fresco in full, with an additional shot of some of the close-up detail.
Weep at the beauty of the first fresco. (Click to enlarge)
A closeup shot. (Click for a bigger closeup)
So like, these are really nice pieces, the kind I think would look great up on a wall. Slapping up a set of the original images might look a little odd, though, but that's where the whole poster idea comes in. A little creative clipping, some small, well-placed logos, and a little Zazzle, and we have ourselves a pretty nice set of posters. To wit:
Your wall is begging you for this. And the other five.
We're currently doing some renovations to our house, and when it's finished we'll have a new office with, I'm excited to say, a lot of empty wall space. I've got all six of these things printed up and ready for framing. I'm really looking forward to seeing them all framed, hanging side-by-side. Is that excessively geeky?
Now, I could show you the other five frescoes, but that wouldn't be any fun, would it? Suffice it to say that I love the first fresco, and it's probably my least favorite of the set. But if there are enough requests, sure, I can show them. And if people think this is something they might be interested in, it might make a nice gift, say, for those who pre-order (when that time comes). What do you think? Posters, anyone?
In Backups I (Should) Trust
22 Jan 10
I never was much of a backup person until I started on the Vespers project. As things progressed, I realized how much content there was to manage, and how important it was going to be to protect it from loss. So somewhere along the way I became a backup fanatic. By my count, I believe I now have somewhere around six active backups of my data, some full backups, some partial. Let me see if I can remember them all.
In Backups I (Should) Trust
22 Jan 10
I never was much of a backup person until I started on the Vespers project. As things progressed, I realized how much content there was to manage, and how important it was going to be to protect it from loss. So somewhere along the way I became a backup fanatic. By my count, I believe I now have somewhere around six active backups of my data, some full backups, some partial. Let me see if I can remember them all.
My main backup is a clone of my desktop development machine. I use an awesome program called SuperDuper! for this. It basically just makes an exact clone of my computer's internal drive onto a secondary internal drive. I have that running nightly, so at any point in time I have an exact clone ready to go, losing at most a day's worth of work.
In addition to that, I also use Apple's Time Machine software to create hourly backups of the main internal drive to a separate partition on the secondary internal drive. So if I somehow do lose a day's work and it's something I really need, I can access the Time Machine backup and get what I need. So in this case I would lose, at most, an hour's worth of work. Not that I think I'll really need a backup of that frequency, but that's how Time Machine is set up, and that's good to know.
Those are two pretty good backups to have, and that alone would constitute a decent backup system (except for the fact that they both backup to a secondary internal drive). For Vespers data specifically (and really, that's the stuff I care about the most), I also create a few mirrors.
I use another nice program called ChronoSync to create scheduled nightly synchronizations of Vespers files to other drives. One copy is kept on my external FTP file server (the one my artists use for uploading and downloading), and another on a separate external drive I had hanging around looking for something to do. I also keep an up-to-date copy of the latest files on my remote MobileMe file space, so I'll always have an off-site copy of things available in case of disaster.
Because I often work remotely on my laptop, it's also nice to have a copy of the most up-to-date build readily available. So for this I use the excellent DropBox. That keeps a local copy of the latest build on my laptop, which is a mirror of the version on my desktop. So any time I make changes to the desktop version, it's automatically updated on my laptop. It's mirrored through a version stored on the DropBox servers, so there is also always an off-site copy available. I could easily do the same thing with my existing MobileMe storage, but DropBox is just exceptionally cool, and works a bit better (and faster) than MobileMe.
Of course, that's kind of overkill. But once you get into backup solutions, it can get a little addicting. Once the home renovations are done and I'm back in the new office space, I'll probably consolidate these a bit, but since they're all managed automatically with scheduled sync's, it's not like it interferes with anything or is troublesome in any way. It's good peace of mind.
The interesting thing comes when the backups are put to the test, as I am experiencing today.
When I woke up today, for some reason my main desktop machine was running, when it should have been asleep after the previous night's backup routine. That's never a good sign. It turns out there was an error during the cloning process, with a dialog box telling me that the main internal drive was full. I knew that there should be somewhere around 20-25 Gb of free space still available, so this was perplexing. After some poking around, it did appear that the main internal drive was being interpreted as completely full, for entirely unknown reasons. Where those available 20-25 Gb of space went is a complete mystery. And although the machine still appeared to be functioning normally, some weird issues started popping up -- for instance, I couldn't open my e-mail program since it could no longer find the designated "temp" folder. I ran some disk utility programs on the main internal drive, but no errors or abnormalities could be found.
I rebooted into the clone, and all appeared as it should. It still had the appropriate open space on the drive, and e-mail was working fine. So it would seem like the best option would be to revert to the clone. Who knows what other weird things will pop up with the main internal drive? And besides, I don't know how I would go about finding where the missing space went and how to get it back.
Still, that would mean erasing the main internal drive and repopulating it from the clone. Cloning back from the clone, so to speak.
I'm not sure why, but that makes me a little uneasy. It shouldn't—in fact, that's entirely what the clone is there for. But I guess I'm just programmed to question what might happen when you lose the original and start working from a copy of a copy. It's one thing to lose a file, or a folder of files, and to just recover a new set from a backup. It's another to restore a complete system from a clone, or at least it seems that way. Still, it's nice to have options.
Kind of interesting to think that my DirecTV receiver's hard drive failed over the weekend, and now this. We'll see if things really do happen in threes.
Riding The Wave
17 Jan 10
Things have been relatively quiet here on the Brew lately, particularly with respect to Vespers. I don't generally post very often, averaging about one blog per week, but even that is being stretched lately, and this is the first blog of the new year. Oftentimes silence reflects little to report from lack of progress, but in this case it's actually a Pretty Good Thing.
Riding The Wave
17 Jan 10
Things have been relatively quiet here on the Brew lately, particularly with respect to Vespers. I don't generally post very often, averaging about one blog per week, but even that is being stretched lately, and this is the first blog of the new year. Oftentimes silence reflects little to report from lack of progress, but in this case it's actually a Pretty Good Thing.
Game development often goes in fits and spurts, especially if you're a small (or solo) team. This has been especially true with Vespers, particularly on the animation front. N.R. has been steadily productive over time with all of the models and 2D art, which has helped us maintain at least some momentum over time. But, as I've blogged many times, it's the animation work that has held us back for so long.
The two main reasons for this are (a) it takes time and effort to orient new animators to the project and bring them up to speed, and (b) for a variety of reasons, animators only seem to stay with the project for a short period of time, forcing me to find new ones and then go through the orientation process again and again. That's been mighty frustrating. But with each new animator comes a renewed sense of hope and purpose, and so we end up with this seemingly endless cycle of disappointment and hope.
And so, as we start yet another year on this project, we enter the next cycle of optimism and anticipation. My latest call for character animators was met with a nice response, and I was able to work it out so that we actually have three animators currently working on different parts of the game. What's especially nice is that two of them have good experience with the Torque system, so I've been able to skip that part of the orientation with them. While it's exciting, it has also meant a good deal of work getting them all up to speed with the project, and getting them the necessary materials so they can start working on things.
So I have some very experienced hands working right now on finishing up the animations for Act I, which means making some final adjustments to Drogo's animations and getting things started on Cecilia's. The work on Cecilia is a lot more complicated and challenging than the work on the other characters, for a number of reasons, so it will be nice to finally get that out of the way. And since there are three animators, we're at last beginning to tackle some of the first animations for Act II which, even though we're not yet finished with Act I, is an exciting and rewarding feeling.
In the meantime, N.R. continues to plug away at the remaining content, working through the list of objects for Act II and beyond. One big milestone was reached this month as he finished up the last of the stained glass windows, which is huge. Because the four windows change six times over the course of the game, 24 different designs were required, eating up a big chunk of his development time. Now that that's out of the way, he can concentrate on the numerous other church objects that change over time, as well as the objects in the cellar and the other objects from later in the game. One interesting challenge was how to design a lock for the calefactory door for Act II -- given the design of the doors, with the ring handle in the center of the door, it wasn't a simple matter to come up with a makeshift lock that Constantin could quickly put together and look like a convincing means of keeping the door from opening. I think the design he came up with should do the job well.
So if development goes in waves, I'm definitely riding the wave right now. Still lots left to do, but we're creeping ever closer to the finish of Act I and the demo, which means we'll be open for some testing soon. Very soon.
Umberto or Geraldine?
30 Dec 09
One of the interesting things about working on Vespers is that I've become so intimate with the original text and code that I probably know more about the game at this point than even the author, Jason Devlin. Often, I'll come across an issue or question about the text game, and I'll pop off an e-mail to Jason to see what he thinks we should do. The irony is that I've been so engrossed in every detail of the story for so long that I'm probably better able to address these things than Jason, who likely hasn't even thought about the game in 3 or 4 years. (Mental note: really have to finish game soon.)
Umberto or Geraldine?
30 Dec 09
One of the interesting things about working on Vespers is that I've become so intimate with the original text and code that I probably know more about the game at this point than even the author, Jason Devlin. Often, I'll come across an issue or question about the text game, and I'll pop off an e-mail to Jason to see what he thinks we should do. The irony is that I've been so engrossed in every detail of the story for so long that I'm probably better able to address these things than Jason, who likely hasn't even thought about the game in 3 or 4 years. (Mental note: really have to finish game soon.)
Throughout development, but particularly when Jason released the text game (and also when we started production), there have been many people drawing close comparisons between Vespers and Umberto Eco's famous novel, The Name of the Rose, which I read back in the late 1980s. I can see that, at least on the surface; it was probably the first story I thought about after I initially played the game a few years back. But really, if you try to make a list of the similarities, I don't think you get very far.
- Italian monastery setting in the middle ages
- A monk as the protagonist, whose life becomes threatened
- Several people die as the story unfolds
And that's about all I got. Granted, those are fairly big ticket items, but they really don't scratch the surface much. And I think it's really just #1 that draws most people to make this comparison. But whereas The Name of the Rose is predominantly an intellectual, historical murder mystery that focuses on the scholastic method and the power of deductive reasoning, Vespers is more of a (for lack of a better description) suspense/thriller that explores the personal relationship between good and evil, and the roles of sin and virtue.
Contrast that with the graphical adventure game, The Abbey (also called Murder in the Abbey). I've played through about a quarter of this game (for research purposes, I swear), and it's hard to imagine a game being more closely linked with The Name of the Rose than this one. The setting, the protagonists (including the young monk sidekick), the subject, the objective, all bear a far closer resemblance to Eco's novel than Vespers does. I'm guessing that the story progressively deviates from Rose as the game advances. I don't know if I'll ever get through it, but if I do I'll have to post some thoughts on it.
Year of Wonders (© Viking Press, probably)
On the other hand, I just finished reading Year of Wonders, the international bestselling 2001 novel by Geraldine Brooks. Wonderful book, by the way, I recommend it. It's a historical fiction novel about the small village of Eyam in Derbyshire, which quarantined itself in the 1600's to protect against the spread of the Black Plague. Reading this novel probably would not remind people much of Vespers, but there are some definite similarities in the themes.
- Setting in the middle ages during the Black Plague
- Group involving the protagonist quarantining itself to prevent the spread of the Plague
- Many people die as the story progresses, some by Plague, some murdered
- Story explores the personal role of religion, and the individual struggles between good and evil, and sin and virtue
Granted, that's still a pretty superficial analysis, and few people would likely see a very close resemblance between these two stories, but it still (to me at least) comes across as a much more supportable and convincing comparison than with Rose.
I suspect that the population of people who have played Vespers and read Year of Wonders is probably much smaller than those who have played Vespers and read Rose (or saw the Sean Connery movie, more likely), so we're not likely to read a critique that delves into the themes of each. But I thought it was an interesting thing to point out after having read the Brooks novel, and never having been satisfied by the past comparisons with the Eco novel.
2009: A Shecky Greene Kind of Year
22 Dec 09
For Vespers, I'd say 2009 was a mixed bag. We started out with some nice momentum, on many fronts, and it lasted about half the year. N.R., as usual, was a model of consistency, churning out an impressive amount of material. He completed all of the models and textures for Act I, which was a nice accomplishment, in addition to all of our GUI and logo work. He's already started chipping away at the additional models needed for Act II and beyond, with much of the work already done. We also got our web site up and running, and although it needs additional content, it's good to have most of the structure already in place, with the connection to this blog. The forums are also ready to go, for the most part, but I'll wait on opening those up until we start the alpha testing sometime early in 2010. And as for the animation, we started out great with our trio of interns, managing to get through most of the Act I animation work for the NPCs (and even the cat). We even started planning out the first cutscene, storyboards and all.
2009: A Shecky Greene Kind of Year
22 Dec 09
For Vespers, I'd say 2009 was a mixed bag. We started out with some nice momentum, on many fronts, and it lasted about half the year. N.R., as usual, was a model of consistency, churning out an impressive amount of material. He completed all of the models and textures for Act I, which was a nice accomplishment, in addition to all of our GUI and logo work. He's already started chipping away at the additional models needed for Act II and beyond, with much of the work already done. We also got our web site up and running, and although it needs additional content, it's good to have most of the structure already in place, with the connection to this blog. The forums are also ready to go, for the most part, but I'll wait on opening those up until we start the alpha testing sometime early in 2010. And as for the animation, we started out great with our trio of interns, managing to get through most of the Act I animation work for the NPCs (and even the cat). We even started planning out the first cutscene, storyboards and all.
Actually, when I think back on 2009 it kind of reminds me of an old board game I used to have as a kid, called "Win, Place, & Show". It was a game about horse racing, which I suppose just proves that there's a board game out there about everything. And of course, through the magic of the intertubes, you too can experience one of the memories of my childhood.
Shecky fading down the stretch, kinda like 2009 did.
The game involved a combination of skill and luck, and was mostly guided by the power and characteristics of your horse as represented by a set of numbers, one for each turn in the game. Some horses were slow or fast starters, some picked up steam towards the end, and some faded out miserably. But you never knew how many turns were needed to complete the race, since this depended largely on the roll of the dice. So sometimes you were lucky and reached the finish line before your horse petered out, while other times you were unlucky and you never got the chance to kick it in at the end.
Shecky's stats at the '73 Derby, according to Win, Place, & Show
2009 was kind of like Shecky Greene at the 1973 Kentucky Derby. Middle of the pack odds, lots of power up front, but not much on the back end. Certainly no match for Secretariat. I'm sure the WP&S folks produced their numbers by reviewing the race and estimating the values for each turn based on how it went. Seeing that Shecky started out great and led the race for much of the way, I can see where they get these numbers. In the end, though, as reflected in the numbers, Shecky faded down the stretch and finished a distant but respectable 6th. (Lesson learned—Shecky: fine name for a comedian, not so much for a thoroughbred.)
So, as was the case with equine Shecky, momentum was not an easy thing to maintain as the Secretariats and Machinariums blew past us en route to spectacular finishes. Right around July things started slowing down, and it was tough to get things going again. I can think of a good number of things that contributed to this: vacations in July and August, preparation for the Austin GDC talk, the slow dissolution of the animation intern group and, finally, the house project.
Yeah, the house project. The wife and I decided it was finally time to do some significant renovations to our house, and we ended up having to move out while the work is being done. So we've been living in a small apartment while the contractors tear the living hell out of our house. That's had a significant impact on progress, particularly since my server is temporarily down and it's tough to get much done on my displaced dev machine.
I was also sidetracked for a few weeks while pondering the move from TGE (Torque Game Engine) to TGEA (TGE Advanced), which would provide some improvements and additional options, particularly on the graphics side. In the end, it would require far too much work to port everything over, as it became clear early on that many features broke in the new engine despite it being a close relative.
Original Shecky, ca. 1981.
Nevertheless, we forge ahead into 2010. The animation interns have been replaced with two promising Torque veterans, and we're already making some progress on the last of the Act I animations. N.R. is just about done with the last of the stained glass windows—no small feat to be sure—and not long after that we should be done with all of the church items, which would be a significant milestone. With just a few more animations and some code contortions, we should have everything set for the demo, and at that point we'll be ready for some serious alpha testing. Hard to say when exactly that will be, but I'm hoping it will be before Spring. Interested testers, keep me in mind—I'll be needing you soon!
Hope everyone has a great holiday season and a happy, healthy, successful 2010.
Touché, aaronius
23 Nov 09
Occasionally I surf around the IFDB looking for goodies. I really like the way it is set up, as it takes a number of cues from other community sites that encourage engagement and social interaction. Often I'll find myself weaving my way through games, reviews, and lists before realizing how much time has passed, and typically I'll come out with a couple of new games to add to the play list. I also absolutely love how it is so smoothly integrated with Zoom (and others, like iPhone Frotz), which so effectively feeds the immediate gratification beast. Anyway, I digress.
Touché, aaronius
23 Nov 09
Occasionally I surf around the IFDB looking for goodies. I really like the way it is set up, as it takes a number of cues from other community sites that encourage engagement and social interaction. Often I'll find myself weaving my way through games, reviews, and lists before realizing how much time has passed, and typically I'll come out with a couple of new games to add to the play list. I also absolutely love how it is so smoothly integrated with Zoom (and others, like iPhone Frotz), which so effectively feeds the immediate gratification beast. Anyway, I digress.
I was flipping through some IFDB pages the other day, looking for some choice information on this year's IFComp winner, Rover's Day Out, when I noticed that it had already made someone's online IFDB poll:
"Games with Impossible-to-film moments", by aaronius.
Okay, I get it. See, Aaron, now you're just gloating. I know you finished Blue Lacuna, all ten wonderous and intricate chapters, light years before Vespers is even close to hitting alpha—and on top of that it's a fantastic, groundbreaking piece. But this, this is just rubbing it in.
The poll?
I'm looking for games that demonstrate the power of text-based games. Games with sentences that would make developers of 3D games weep, like "The army of ten million robots marched over the liquid landscape," or "She concealed her anger perfectly."
Oh I weep, Aaron. Something as relatively tame as Vespers has me weeping almost daily. Sentences, passages—entire sequences. Just the avalanche scene alone is enough to keep me up at night. Must you see me weep more?
Honestly, though, I can't imagine it is too challenging to find IF with exasperatingly difficult-to-implement-in-3D passages, and plenty that are designed in such a way that translation into 3D would not just be onerous, but essentially pointless. I doubt there are many people who fail to see the intrinsic advantages of the written word for (at least) certain aspects of storytelling. The translation of books into movies is an obvious analogy, and I'm sure Peter Jackson (Lord of the Rings), Chris Columbus (Harry Potter), and countless other directors had their fair share of sleepless, weeping nights. Certainly this would extend to the gaming world, at least for those demented enough to consider translating an IF game into 3D.
Take even something as (relatively) simple as dialogue: despite the fact that NPC conversation still has glaring limitations in the text-based world, it still far exceeds anything being done in 3D games for many reasons, not the least of which is the inability to delve anywhere below the shallow surface of expression, thought, and emotion. Non-verbal communication of all kinds, from facial expressions to internal thoughts to detached narrator descriptions, can convey sophisticated and subtle information far more easily and deftly than anything currently available in 3D, where there is already little latitude or patience for subtlety. After all, in 3D, you might not be able to tell if what you just saw was a subtle gesture or merely a graphical glitch.
Even what might be thought of as a simple physical gesture can be added almost as an afterthought in text, but cause turmoil in the 3D world. Take this brief passage from Vespers, when the player first encounters Ignatius:
Brother Ignatius sits in one of the pews near the front, staring intently at the candles.
>TALK TO IGNATIUS "How are you, Ignatius?" you ask, laying your hand on his shoulder.
He startles, whirling around, his bad eye twitching and shuddering. "Oh, father. You spooked me." He shakes his head. "I'm sorry, what did you ask?"
There is plenty of information conveyed in what seems like a few insignificant physical actions described in that passage—the touching of the shoulder communicating something about the relationship between the two; the whirling, twitching, and shuddering communicating something about the NPC'S mental state. But in a pure 3D world, even simple actions like those become problematic because of the introduction of space. Where might the player be standing when he encounters Ignatius? How could we make sure the player's hand actually touches the NPC's shoulder? How do we ensure that the NPC whirls around to directly face the player instead of looking the wrong way? Missing on either of those is potentially worse than not including them at all. There are certainly workarounds for those, but they require additional planning and work for arguably less reward than something that is done almost effortlessly in text.
Of course, that's part of the curse of taking an established text game and adapting it into 3D; the game is already designed for a particular medium, and does its best to utilize the established techniques and strategies available to it—strategies which don't always translate well to other media. A graphical translation (even if it is a hybrid) will undoubtedly highlight, maybe even accentuate, the limitations of the graphical approach within that context.
Still, the point of the Vespers experiment is not to see if we can provide in 3D the same or better Vespers gaming experience than already available in text. This is primarily to see if, generally speaking, the text interface of IF and the graphical interface of first-person 3D have the potential to live together and synergize, maybe becoming something more than each alone. A true (and perhaps best) test of this hybrid 3D/IF approach would be a game designed from the ground up for this medium. Could it be that 3D/IF has particular strategies, not yet discovered or explored, that would provide unique opportunities for expression and storytelling? In ways previously unavailable, or available to only a limited extent, in either medium alone? I have no idea. I really hope to find that out eventually.
But for now: touché, my friend.
Long Live the Animator
11 Nov 09
You may have noticed (if you'll allow me the fantasy that anyone is paying attention) that it has been a while since the last Vespers update. This is for many reasons, of course. It might just be easiest to say that it's because there hasn't been a whole lot to report. I wish that wasn't the case, but so it goes.
Long Live the Animator
11 Nov 09
You may have noticed (if you'll allow me the fantasy that anyone is paying attention) that it has been a while since the last Vespers update. This is for many reasons, of course. It might just be easiest to say that it's because there hasn't been a whole lot to report. I wish that wasn't the case, but so it goes.
Most of it, as usual, originates from the animation side of things. What began as a promising venture with three local animation students eventually fizzled out. One of them made a little bit of progress over a long period of time, but couldn't get much further due to classes and other obligations. Another never really got off the ground. The third did actually get a lot of quality work done in the time we worked together, but life issues with women and career eventually derailed that train, and he faded into obscurity. It was, to be sure, a useful path to follow, as we now have all of our character models essentially working the way they should. But a game like this has a lot of animations to be done, and we're only a fraction of the way there.
Animation is clearly the bottleneck that is keeping this project from making any serious advances. It's frustrating, because I keep ending up in the same place and it's hard to keep the wheels from spinning. As it turns out, in what is surely a surprise to nobody except perhaps me, a game with a lot of expressive character animations might not be the best project for a small indie group to tackle. Bad animation just won't cut it, but good animation is hard to find if you're not walking around wagging fistfuls of dollars in people's faces. Apparently, the prospect of even some payment -- granted, well below market value, but not exactly pocket change -- isn't itself enough incentive to maintain the interest of a decent animator for very long.
I remember joking years ago, as another animator drifted into the void, that if I had just sat down and taught myself animation over that same period of time, I'd at least be in position by then to be doing the animations myself. Funny thing is, if I really had done that, I'd have a few years of animation experience under my belt by now. Assuming, of course, that I hadn't already left myself for another project.
Not to worry, though, as we do have a new animator joining the project, Daniel, who is luckily already well-versed in the mystical ways of Torque. That means he has been able to jump right into the project without a long period of adjustment, which is extremely nice. So hopefully we'll have some new material coming through soon, and we can get this thing back on track and moving forward again.
New Host, New Sites
23 Sep 09
For a little while now I've been setting up a website for Orange River Studio and Vespers, and I've reached the point where it's pretty much ready to go live. But that also gave me the opportunity to switch from Blogger to WordPress for this blog, and after some testing I think it's time to make the switch. So the new URL for The Monk's Brew is now http://orangeriverstudio.com/monksbrew, although I've tried to set things up so that the feeds transfer over seamlessly. So there shouldn't be any need to re-subscribe to the feed, and most links should transfer you over automatically. I'm still learning about this whole process, though, so I wouldn't be surprised if I missed something. If anyone discovers this is the case, by all means let me know.
New Host, New Sites
23 Sep 09
For a little while now I've been setting up a website for Orange River Studio and Vespers, and I've reached the point where it's pretty much ready to go live. But that also gave me the opportunity to switch from Blogger to WordPress for this blog, and after some testing I think it's time to make the switch. So the new URL for The Monk's Brew is now http://orangeriverstudio.com/monksbrew, although I've tried to set things up so that the feeds transfer over seamlessly. So there shouldn't be any need to re-subscribe to the feed, and most links should transfer you over automatically. I'm still learning about this whole process, though, so I wouldn't be surprised if I missed something. If anyone discovers this is the case, by all means let me know.
Although Blogger is nice, I'm really liking WordPress. I'm very impressed with how powerful it is, while still being very easy to learn and use.
The new web site for ORS and Vespers is just http://orangeriverstudio.com/, although http://vespers3d.com/ will also take you there. I had a lot of help creating the site, which was done with Joomla. There is definitely a learning curve with Joomla, but it's beginning to grow on me.
It's still very much a work in progress, and I'll be filling in content as we go and giving updates and announcements about it from time to time. I'll also have forums up and running soon, as we make more progress with the game. Any comments or suggestions for the site are welcome and appreciated!
Wrapping Up At the GDC Austin
18 Sep 09
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.
Wrapping Up At the GDC Austin
18 Sep 09
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
1 Jul 09
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.
The End of June Vespers Thing
1 Jul 09
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.
The One Thing He Forgot To Mention
21 May 09
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.
The One Thing He Forgot To Mention
21 May 09
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
5 Apr 09
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.
The Early April Vespers Thing
5 Apr 09
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.
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.
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
17 Feb 09
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).
Targeting Older Systems
17 Feb 09
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
1 Feb 09
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.
The End of January Vespers Thing
1 Feb 09
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.
He also incorporated a sweet ribbon design with a medieval image he obtained and utilized in the Main Menu GUI.
(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.
(Click for larger version)
(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
25 Jan 09
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:
Curse My Expensive Font Tastes
25 Jan 09
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.
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.
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."
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.
Curse my expensive font tastes.
The End of December Vespers Thing (Or, Back After A December Hiatus)
29 Dec 08
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.
The End of December Vespers Thing (Or, Back After A December Hiatus)
29 Dec 08
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
30 Nov 08
(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
2 Nov 08
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.
The End of October Vespers Thing
2 Nov 08
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
30 Sep 08
Another month has come and gone, which means it's time for a quick Vespers update.
The End of September Vespers Thing
30 Sep 08
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)
2 Sep 08
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.
Holidays Are Good For Gaming (And Coding)
2 Sep 08
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
31 Aug 08
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.
Orange River Studio, LLC
31 Aug 08
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?
21 Aug 08
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.
Vespers on the iPhone...for real?
21 Aug 08
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
15 Aug 08
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
4 Aug 08
Such is the life of an indie developer, or at least it seems to be when it comes to character animation.
One Step Forward, One Step Back
4 Aug 08
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*
31 Jul 08
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.
An Interview With SPA*
31 Jul 08
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.
You Got Turn-Based Chocolate In My Real-Time Peanut Butter
28 Jul 08
The whole idea behind this Vespers project thingy is to take a rich textual world created in interactive fiction and extrude it, so to speak, into three visual dimensions. As I've discovered, a whole mess of issues arise when moving from the predominantly discrete world of IF to the largely continuous world of 3D. That applies, of course, to space: in IF, space is divided into discrete locations, with little to no functional representation of spacial relationships within those locations, while in 3D, space is represented on a more familiar continuous scale. Likewise, it applies to time: rare exceptions aside, IF is turn-based with discrete time steps, while first-person 3D games are real-time and continuous.
You Got Turn-Based Chocolate In My Real-Time Peanut Butter
28 Jul 08
The whole idea behind this Vespers project thingy is to take a rich textual world created in interactive fiction and extrude it, so to speak, into three visual dimensions. As I've discovered, a whole mess of issues arise when moving from the predominantly discrete world of IF to the largely continuous world of 3D. That applies, of course, to space: in IF, space is divided into discrete locations, with little to no functional representation of spacial relationships within those locations, while in 3D, space is represented on a more familiar continuous scale. Likewise, it applies to time: rare exceptions aside, IF is turn-based with discrete time steps, while first-person 3D games are real-time and continuous.
The question is, can a game really be both at the same time?
In terms of space, that's not really a difficult stretch. Most locations in IF are just discrete representations of a location in 3D; a kitchen, a bedroom, a church can all be defined by walls and doorways in 3D to produce the same effect as in IF. Outdoor or more abstract locations can be a little trickier, but through the use of invisible, arbitrary borders one can functionally define locations such as "outside the calefactory", "base of the bell tower", or "garden", to produce the same effect. Dealing with spatial relationships within locations has its implementation challenges, but nothing that can't be addressed by a few ground rules that can be tweaked based on playtesting and feedback.
Time, however, is a bit less straightforward.
The turn-based nature of IF is something that is tightly integrated into game design and gameplay mechanics. It's probably fair to say that this is, at least in part, a reflection of the history of the genre, going to back to the command-line interface and early computational limitations. It's also probably related to the nature of the medium and interface; reading and typing text, and thinking through sometimes complex puzzles, is better suited to a more relaxed, turn-based interface. It creates a challenge for authors trying to model time-limited situations in their IF games, with the typical solution being a turn counter and forcing the player to resolve an issue within X number of turns. This can work to create a sense of urgency in players, although in some cases it can come across as an artificial limitation.
Some authors have tried using IF systems that operate in real-time; although I don't recall trying any of these myself, my sense is that the scarcity of these games is a reflection of the popularity of this approach.
Which leads, I guess, to the next question: if that's the case, why try to do something like that with Vespers?
The answer is that I'm not. Instead of being truly turn-based or truly real-time, Vespers will actually be something of a hybrid, although in practice it will play closer to a turn-based game. The player can move in real-time, but for the most part it will resemble moving about within a world where time is essentially in an idle loop, advancing predominantly (but not entirely) upon player input. That input could be the entry of a command (like in traditional IF), or it could be the result of movement (such as entry into a new location).
As an example, take the interaction with NPCs. When the player first encounters Lucca, for instance, he is on the floor in Matteo's room, scratching at a flagstone in the floor. If the player does not interact with Lucca, he will just continue to do what he is doing, maintaining his "idle" state of scratching at the stone. We've created a series of animations for Lucca during these "idle" times -- scratching at the floor, sitting up to rub his sore hands, wiping the tears in his eyes, and so on. These animations play at random intervals to give the appearance of a living, active character, even though he is essentially just waiting for either (a) the player to interact with him, or (b) some other game event to trigger his next action or task. If the player does interact with him, once the interaction is finished he simply goes back to doing what he was doing, scratching at the floor.
The result is a game world that is predominantly reactive, but it remains to be seen if this comes across as a little too passive. Note, however, that the world won't be 100% reactive in this sense; there are still some situations where we cannot always wait for the player before advancing time.
The most obvious example of this is an action sequence; in Vespers, for instance, there is the tense scene with the wolves in the garden. In the IF game, the player is given a handful of turns to work out a solution to the mess -- but how to implement this in pseudo-real-time? Forcing players to think and type fast would not be an ideal solution. Instead, the solution will be to implement a surrogate for the "turn". The surrogate will take into account all possible actions (and inactions) of the player, including the typing of commands and any movement.
There are a couple of tricky situations with this approach. For instance, with respect to player movement, how much movement should represent a "turn"? Then there is the command line entry window: should the advancement of time be suspended while waiting for the player to finish typing? Should a time limit be placed on text entry? Or should text entry be cancelled if no keys are pressed after a certain period of time? Finally, there is the issue of player inaction, and whether time should advance or loop continuously while the player sits idle.
These are all issues that need to be worked out through playtesting and then tweaked as needed. In the end, however, the result will be a game that has elements of both turn-based and real-time gameplay, although functionally it will probably be closer to the former than the latter.
The most interesting part of the experiment will be to see which parts of the system work and which do not, and then using that information to refine the mechanics once we move beyond Vespers and on to the next project.
A Short Review of Vespers
7 Jul 08
Emily Short has finally had the chance to play the original IF version of Vespers, and has a nice review of it up on her blog.
A Short Review of Vespers
7 Jul 08
Emily Short has finally had the chance to play the original IF version of Vespers, and has a nice review of it up on her blog.
Short, of course, has tremendous experience playing, writing, and writing about a wide range of IF pieces, and her reviews are insightful and well-informed. I was a bit surprised to learn a while back that she had never played Vespers, and I wondered if she would get around to it one day. Gladly, that day has come. Her review is a good read, focusing largely on the game's effective use of plot construction:
"To my surprise, what I found most interesting about Vespers was its construction, its success at arranging events and making characters take action; it has a lot of plot, but avoids the excessively linear feel of many high-plot-content games. The way it works is mostly neat sleight-of-hand."
In the comments, I prompted her to say a few words about the game's conversation system and its multiple endings, which brought up some interesting points about the role of coercion in the game, its relationship to sin, and its impact on both the player and the protagonist (the Abbot). As well as I know the game at this point, I have to say I learned a bit more about it today.
Being Indie, Being Resourceful
30 May 08
Being indie can definitely be tough sometimes. I've often said that indie game projects are kind of like fish eggs: thousands are laid but few manage to survive to adulthood. Content for a 2D or 3D game, whether it's artwork, music, voicework, or animation, can be a real problem for a small team on a shoestring budget. It's no secret that content, specifically character animation, has been the biggest challenge for Vespers.
Being Indie, Being Resourceful
30 May 08
Being indie can definitely be tough sometimes. I've often said that indie game projects are kind of like fish eggs: thousands are laid but few manage to survive to adulthood. Content for a 2D or 3D game, whether it's artwork, music, voicework, or animation, can be a real problem for a small team on a shoestring budget. It's no secret that content, specifically character animation, has been the biggest challenge for Vespers.
Sometimes, it takes a little creative thinking to figure out ways to stretch those limited resources.
A while back, when I was looking for help with voiceover work, one idea I had was to try tapping into some good but inexpensive local talent -- theater students at the University of Utah, where I work. The casting call I posted ended up being picked up by a local talent company, which brought in a lot of additional talent, but the end result was exactly what I needed: great people with great voices who enjoyed working on a fun project for what essentially amounted to peanuts.
Animation, however, is a different beast that requires a bit more of a commitment, so I was never very keen on trying a similar approach. Nevertheless, recently I learned that the University of Utah also has a new interdisciplinary program for undergraduates called Entertainment Arts & Engineering, which is a joint program between the School of Computing and the College of Fine Arts. It's basically a curriculum to prepare students for careers in the digital media and entertainment industry, specifically for videogames, digital animation, and computer-generated special effects. How enticing.
So I contacted one of the program directors and told him about Vespers, to see if it might be possible to work something out with a few of the animation students who might be looking for some experience and a chance to showcase their talent. He circulated it among the faculty, and before long I had an informal face-to-face with one of the teaching faculty who specializes in graphics and animation, and has worked in the computer graphics industry since 1985.
The meeting went very well. He seemed to like the idea behind Vespers, and thought it would be a good opportunity for some of his students, many of whom he thinks would really appreciate the chance to work on something like this.
What I found just amazingly generous is that he essentially volunteered to be something of a faculty representative for the students, and take on the tasks of finding interested students, teaching them the pipeline, providing help when needed, and holding them to the task. It's difficult to overstate the value of someone in this position; having a person that knows all the details about the animation, exporting, and file preparation process, and who also knows the students and is in a position to manage and organize them, is worth more than I can imagine. I'm still just astonished that he is willing to take on this effort.
It will still be some time before things get rolling, though. The biggest issue is that we've done all of our models and animations to this point in 3DS Max, and he and the students basically work only in Maya. So first there is the issue of converting our character models to Maya format, which is not nearly as simple as it should be. Then there's the task of getting him familiar with creating and exporting animations from Maya to files that work with the Torque Game Engine, which is a quirky process that anyone familiar with TGE will tell you requires some time to learn. Once we reach that point, he can then be in a position to get the students up to speed, and so far there are at least a handful who have expressed interest in working on the project.
I'm really excited about the arrangement, and if things work out it could be the real boost this project needs. I'd also like to think that it could lead to other projects down the line, since it seems to fill a need on both ends. We'll see how it goes.
Nineteen Years Later, The Record Is Still Skipping
23 May 08
Yesterday was a birthday, of sorts; it was the birthday of The Grumpy Gamer, the blog site belonging to Ron Gilbert (of Monkey Island fame) for his "often incoherent and bitter ramblings about the Game Industry." Four years ago yesterday he posted his first blog, a reprint of an article he wrote in 1989 which, he says, became the foundation for the design of Monkey Island. And at the time of its reprint, in 2004, Gilbert made the proclamation that "Adventure Games are officially dead."
Nineteen Years Later, The Record Is Still Skipping
23 May 08
Yesterday was a birthday, of sorts; it was the birthday of The Grumpy Gamer, the blog site belonging to Ron Gilbert (of Monkey Island fame) for his "often incoherent and bitter ramblings about the Game Industry." Four years ago yesterday he posted his first blog, a reprint of an article he wrote in 1989 which, he says, became the foundation for the design of Monkey Island. And at the time of its reprint, in 2004, Gilbert made the proclamation that "Adventure Games are officially dead."
What I find fascinating is that the article, titled "Why Adventure Games Suck (And What We Can Do About It)", discusses so many of the ongoing issues surrounding storytelling in games that people like me continue to blather about nearly two decades later. This is going all the way back to 1989. Infocom still (barely) existed, and Interplay's Neuromancer was the adventure game of the year.
Apparently, the more things change, the more they really do stay the same.
Rather than just reproducing the whole article verbatim, I thought it would be more interesting to highlight some of the important passages that I think remain relevant and continue to be debated to this day.
The element that brings adventure games to life for me is the stories around which they are woven. When done right, it is a form of storytelling that can be engrossing in a way that only interaction can bring. The key here is "done right", which it seldom is.
We continue to talk about the great advantages that interaction can provide, yet it still seems like we don't have a good handle on what those advantages really are, or how to best take advantage of them. And I'm not so sure, all these years later, that we could yet define what "done right" actually is. We might be able to point at a few good examples, but I suppose it's just another one of those things like porn: it's tough to define it, but you know it when you see it.
They are interactive, but they are not movies...Movies came from stage plays, but the references are long lost and movies have come into their own. The same thing needs to happen to story games.
Nearly twenty years later...but have story-based games really separated themselves from other media like movies? We still hear this same point being made over and over again. The same thing does need to happen to story games. When will it?
In a story game, the player is given the freedom to explore the story. But the player doesn’t always do what the designer intended, and this causes problems. It is hard to create a cohesive plot when you have no idea what part of the story the player will trip over next. This problem calls for a special kind of storytelling, and we have just begun to scratch the surface of this art form.
I, like many others, have made this point in the past -- and of course, back when I did, I'm sure I thought I was all too clever for bringing it up. We continue to gnash our teeth over how to deal with player choice and freedom within a traditionally linear environment. But it's fascinating that, nearly two decades ago, we were just beginning to scratch the surface. If I hadn't read this piece, I probably would have described the current state of affairs the same way. We're still scratching away, and it's tough to know if we're any deeper than we were back in 1989.
Nothing is more frustrating than wandering around wondering what you should be doing and if what you have been doing is going to get you anywhere.
This is clearly true, and as true today as it was back then. I bring it up only because this was one of the criticisms I saw repeatedly for the text version of Vespers, at least at the very beginning of the game. It takes a little while before the seminal event takes place in the game, and some players griped about not knowing what they were supposed to be doing from the start. It's one of those things I'm a little nervous about for the 3D game. I'll have to see what the initial feedback is like, when the time comes.
It is bad design to put puzzles and situations into a game that require a player to die in order to learn what not to do next time. This is not to say that all death situations should be designed out. Danger is inherent in drama, but danger should be survivable if the player is clever.
This is another one of the main complaints about Vespers -- death is a part of the game, and I'm not sure how clever you need to be to avoid it completely. I do agree that death or danger should be allowable, as long as it can be avoided through careful thought and consideration. We'll see how it goes over in the 3D game.
One of the most important keys to drama is timing. Anyone who has designed a story game knows that the player rarely does anything at the right time or in the right order...Give the player some slack when doing time-based puzzles.
Couple of interesting points here. First, he's right about drama and timing -- that's got to be one of the most difficult things to try and incorporate into a story game. It probably relates back to his point about players tending to do things other than what the designer intended, and that we just need to figure out how to deal with storytelling in this kind of interactive medium. But second, it's also interesting to consider the point about time-based puzzles, particularly since the IF version of Vespers is inherently turn-based, while the 3D game is more real-time (although actually it's more of a hybrid). Vespers does include what would be considered time-based puzzles, but that has been one of the challenges when adapting the game to 3D: how to deal with time-based puzzles that were originally turn-based, but are now essentially real-time. I still don't know how well those puzzles will be implemented and received.
The object of these games is to have fun. Figure out what the player is trying to do. If it is what the game wants, then help the player along and let it happen. The most common place this fails is in playing a meta-game called “second guess the parser.” If there is an object on the screen that looks like a box, but the parser is waiting for it to be called a mailbox, the player is going to spend a lot of time trying to get the game to do a task that should be transparent...On one occasion, I don’t know how much time I spent trying to tie a string on the end of a stick. I finally gave up, not knowing if I was wording the sentence wrong or if it was not part of the design. As it turned out, I was wording it wrong.
I point this out only because I think this is one area where IF has really advanced. I think most authors -- at least who have done more than just dabbled in IF -- have taken this gripe to heart and in my experience it's more of the exception rather than the rule to come upon a "guess the verb" or "guess the noun" problem. I think this is something that has kept a certain number of people away from IF for a long time, but I think those people would be pleasantly surprised at how infrequent this issue has become.
If I could have my way, I’d design games that were meant to be played in four to five hours. The games would be of the same scope that I currently design, I’d just remove the silly time-wasting puzzles and take the player for an intense ride. The experience they would leave with would be much more entertaining and a lot less frustrating. The games would still be challenging, but not at the expense of the players patience.
I find it interesting that he brought this up almost twenty years ago, but the shorter-style game really wasn't given much consideration (at least in the mainstream) until more recently -- Penny Arcade's new episodic game being one example, and the casual game market being another. That said, the IF Comp has existed for many years now, and those games are intended to be completed in two hours or less (Vespers being one of them) and I think players have come to really appreciate that. I think Vespers game play is probably more like 3-4 hours, but what Gilbert describes is exactly what I am aiming for with this game: a short but intense ride that avoids a lot of the typical trudge work in games.
If any type of game is going to bridge the gap between games and storytelling, it is most likely going to be adventure games. They will become less puzzle solving and more story telling, it is the blueprint the future will be made from. The thing we cannot forget is that we are here to entertain, and for most people, entertainment does not consist of nights and weekends filled with frustration.
Well, he's certainly right about all of that. I'm just wondering when that beautiful future will finally arrive!
First Fresco Finished
20 May 08
One of the things that I thought Jason did really well when he created Vespers was the creation of a very vivid image of the monastery church, an image which rots and decays over the course of the game as the abbot and monastery descend into darkness. One of the real challenges for us as we adapt the game to a 3D environment is the visual representation of this decay.
First Fresco Finished
20 May 08
One of the things that I thought Jason did really well when he created Vespers was the creation of a very vivid image of the monastery church, an image which rots and decays over the course of the game as the abbot and monastery descend into darkness. One of the real challenges for us as we adapt the game to a 3D environment is the visual representation of this decay.
Perhaps the biggest challenge in this regard is one of the game's best depictions of this fall from grace: the frescoes on the ceiling of the church. The frescoes are extremely difficult for a number of reasons --
- the frescoes are on the ceiling of the church, which is supposed to be high above the player. And as the church is modeled now, the ceiling really is pretty high up -- high enough that the player would have a lot of trouble seeing the frescoes all the way up there.
- Jason did a remarkable job describing them simply and plainly, which was quite effective in the game, but it didn't provide us with a gret deal of guidance.
- frescoes of that age have a distinct appearance which is complex and difficult to replicate, which requires an artist with a great deal of talent.
After some consideration, we decided to put the frescoes on the walls in the front foyer of the church, rather than on the ceiling. The foyer also contains the font, another object in the game that rots as the narrative progresses, so it fits right in. And the nice thing about the foyer is that it provides a nice frame for highlighting the frescoes, to help make sure the player notices and explores them.
The frescoes in the game start out with the following rather succint description:
"Frescoes depict the fall of Satan, with angels singing as they cut down the wicked."
That's about it. Fortunately, I think we found the right artist for the job. After placing an ad online and reviewing the work of those who responded, I decided to go with Régis Moulun, an artist from France with an impressive body of work. So far, I'm really happy with how he's approached the work. We decided to go with more of a Renaissance style to the fresco, based loosely on the works of Signorelli and Giotto, even though an earlier style might have been more appropriate.
Recently, Régis finished his work on the opening fresco, and he's done a great job of it. I thought it would be nice to post a shot of it, as well as a screenshot of it in game. Click the images for a larger view. Enjoy...
Vespers: The Power of the Bool
23 Apr 08
One of the things that has always been nagging at me since starting development on Vespers is game performance. We haven't really been developing with frame rate in mind, our thought being that we would leave optimization until we had most of the content plugged in. Most of that optimization would come from the graphics end -- LOD, portals and zones, textures, things like that -- but that's a lot of work for the artist to do, and it's not terribly exciting work at that.
Vespers: The Power of the Bool
23 Apr 08
One of the things that has always been nagging at me since starting development on Vespers is game performance. We haven't really been developing with frame rate in mind, our thought being that we would leave optimization until we had most of the content plugged in. Most of that optimization would come from the graphics end -- LOD, portals and zones, textures, things like that -- but that's a lot of work for the artist to do, and it's not terribly exciting work at that.
Still, after trying out the game on a number of different systems, I was not very happy with performance even at this unoptimized stage. Frame rates on the better systems would rarely get to 30fps, even at lower screen resolutions. And in far too many areas, rates were commonly in the teens. In some places with a lot of objects in the field of view, rates would bottom out at 10 or less. Rates in the teens give a pretty choppy performance; rates around 10 are just unacceptable. And on one system, with a lower end graphics card, the game was completely unplayable with rates unable to get above 5.
So recently we started addressing optimization, first by adding some LOD to objects and buildings, and then tackling portals. Unfortunately, portals turned out to be an unwieldy beast that we just could not master. Setting up portals and getting them to work in the Torque Engine can be very tricky, especially for complex models like our monastery buildings -- any tiny little misalignment, visible or not, and you're out of luck. At this point, finding those misalignments would be like trying to find an unknown number of needles in a series of very large haystacks.
So I turned my attention elsewhere, and implemented code to replicate (for the most part) the function of portals and zones. It works well, producing nice frame rate boosts on most systems. Whereas before I was sludging along with rates in the teens and twenties, now I'm getting rates in the thirties and forties, and often more than that. I'm very happy with that.
But there was still one thing bugging me: these performance improvements were seen on my desktop (a PowerPC Mac G5) and on my laptop (an Intel Mac), but only on the laptop when running under WindowsXP. If I ran the game on the laptop under Mac OS X, I was still getting the same crappy frame rates as before. How could that be? Same laptop, same hardware, but under one operating system it runs fine, while under the other it runs crappy.
The desktop also runs Mac OS X, and both the desktop and the laptop have graphics cards with 256MB of VRAM. So I didn't think it could be the operating system itself, or a lack of VRAM on the laptop. I thought it had something to do with the Torque Game Engine code, something specific to the graphics rendering on different platforms and CPUs, probably related to the rendering of buildings like the monastery. I went through round after round of testing, using various tools to analyze the code to see where the slowdowns occurred. Long, boring, frustrating work.
The only conclusion I came to is that the laptop was probably tricking the Mac OS into thinking the video card had run out of VRAM, even though it probably hadn't. And this was likely related to Apple's ATI graphics driver on the laptop, which is different than the ATI driver I use on the desktop (and different, of course, from the one used by XP on the laptop). A driver issue like that is a bummer, since there's not a lot I can do about that. I was not very happy with that.
The only other thing I thought of trying was to mess with some of the global preference variables in the Torque Engine, to see if I could somehow improve performance on the laptop without sacrificing too much on the graphics end. There are a huge number of preference variables available -- stuff related to interiors, lighting and shadows, terrain rendering, and OpenGL performance. The latter struck me as potentially useful, as it would probably be related to the driver. So I started looking at those more carefully, and I saw this one:
$pref::openGL::allowCompression = 0
That seemed interesting. Allow compression...likely related to texture compression. Textures can take up a lot of VRAM, especially if you use lots of them, and lots of large ones -- like my artist enjoys doing. It makes for prettier graphics, but it rapidly eats up memory on the graphics card. And even though I didn't seem to be running out of VRAM, on the laptop it seemed like the system was being tricked into thinking so, which would certainly cause these types of slowdowns. But what could this one little boolean variable do? I set it to 1, and gave it a try.
Amazingly, frame rates in general tripled, and often more than that. Whereas before I was getting annoying, choppy gameplay with rates in the low teens, now I was seeing smoothness with rates in the thirties and forties, sometimes more. And, as far as I can tell, no discernable change in the appearance of the graphics.
Even better, the game now runs on the older system with the lower-end card -- and runs well, with rates in the twenties and thirties, even at larger screen resolutions. I never thought I'd see it running on that machine at all, much less running well.
It's not a solution to the overall problem, which is likely related to Apple's ATI drivers. But still, it's an amazing improvement that appears to come at little to no cost.
And all due to one little boolean. A completely undocumented boolean, I might add.
Vespers: Adventures with NPCs, Part IV
20 Mar 08
This is the fourth installment of my blog series introducing the six NPCs in Vespers, detailing the development process from text to functioning 3D characters. The three previous installments can be found at Part I, Part II, and Part III.
Once again it's time to resume my efforts to bring our NPCs to life, beginning with bits and pieces of text from the IF version of Vespers and ending with a modeled, animated, and voice-acted 3D character. It's been a while since my last entry, which described Lucca, the youngest monk at St. Cuthbert's. This time I discuss the development of Ignatius, perhaps the most mysterious of the brothers at the monastery, and the one most distrusting of the Abbot at the start of the game.
Ignatius: From Concept to Character
Each of the characters in the game has their own challenges, and Ignatius is no exception. In addition to his bad eye, Ignatius has to have a particularly suspicious appearance, which can sometimes be difficult to model in a convincing way. Again, we didn't have a lot to go on initially from the text version of Vespers, aside from a short description:
"A fiery man, whose devotion to God is rivalled only by his devotion to protecting
God's people, Brother Ignatius was a soldier before joining Saint Cuthbert's.
After losing an eye against the Turks in Nicaea, he came back to Italy, and
started fighting for God in the only way he could now: with prayer."
Aside from a middle-aged, slender built man of above-average height, Jason Devlin (the game's author) and I didn't have a lot to give N.R. Bharathae, our lead artist, to go by. Nevertheless, N.R. did a great job capturing his appearance with his initial concept:
This looked like a perfect starting point. Using this, N.R. designed Ignatius's 3D model and then applied some of his amazing textures -- where he gets these from, I have no idea. As with the others, we were going for a more realistic appearance for our characters, and I think N.R. really outdid himself this time...
As with the other characters, while N.R. modeled we continued in our task of finding and recording a voice actor for the part. Matching a voice for a middle-aged man would not be as difficult as for some other parts, but the real challenge was finding someone who could play the part convincingly, given that Ignatius needs to be portrayed as dark and suspicious. The man we found to play the part was Bob Richardson.
Here's a shot of Bob alongside with his character, as well as a short bio and a shot I took during his recording session:
"Bob Richardson is the father of three gallant sons, one princess daughter, and two wonderful step-daughters. He has been involved in acting for about 40 years, although not in anything you've probably ever seen before. Starting in the theater at age 11 and moving to film and video productions about 10 years ago (mostly local projects), he studied Theater and Cinematic Arts at BYU for a while and now continues to dabble in entertainment as time and schedule permit. He has developed a wide variety of vocal talents; being able to speak with a variety of dialects, accents, and caricatures (He does an amazing Yoda). He has sung bass in a number of choirs and small ensembles. Bob's primary occupation is in financial services, but he also does some contract technical support on the side. His hobbies include riding his Honda Goldwing, SCUBA diving, and playing a few FRP computer games." -- B.R.
Ignatius also marked the debut of two new animators, James Allan and Marc Schwegler. Both of these guys generously offered their help after seeing my last blog, when I was lamenting the loss of yet another animator. Thankfully, both James and Marc are Torque Game Engine pros, so we didn't have to go through the painful process of reviewing the entire exporting process, and we've been able to make some good progress on the character animations.
There was nothing particularly new for us about the process of animating Ignatius, since by this time we had covered most of the approaches with the previous characters. When the game begins, Ignatius is sitting in the church, staring intently at the candles and praying, so much so that the player surprises him when he speaks. In the text game, Jason had Ignatius sitting in the pews; later, we realized that pews didn't exist until much later in history, and we switched instead to choir stalls.
Here is a short portion taken from the beginning of the text version of Vespers, with the player's commands in bold caps:
Church (in the pews)
Cedar pews line the path from the chancel in the north to the cloister to the
south, their surfaces cold. The ceiling towers above you, its frescoes dim in the
candlelight.
The Saints smile cheerfully down upon you from their colorful windows.
The font glows warmly in the candlelight, not a ripple on its water's surface.
Brother Ignatius sits in one of the pews near the front, staring intently at the
candles.
>EXAMINE IGNATIUS
The scar through his left eye having left him half-blind, Ignatius makes up for it
by staring twice as hard at the candles with his good eye. The eye refuses to blink.
>TALK TO IGNATIUS
"How are you, Ignatius?" you ask, laying your hand on his shoulder.
He startles, whirling around, his bad eye twitching and shuddering. "Oh, father.
You spooked me." He shakes his head. "I'm sorry, what did you ask."
>AGAIN
"I was just wondering how you were doing."
"Oh, fine." He relaxes, turning back to the candles. "Just fine."
>AGAIN
"Shhh, father." He holds a finger to his lips. "I am trying to pray."
We thought to have Ignatius idle using a cyclic sequence, showing him very subtly rocking back and forth as he prayed, with a very slight movement of the fingers of one hand rubbing together. We also wanted to implement his eye twitch as a separate animation sequence, one we could call at random intervals separate from other currently playing sequences.
With the arrival of our two new animators, we also went about making some changes in the way we designed the characters. We went back to a biped skeleton for greater compatibility and simplicity, for one. In addition, James wanted to take our animations a step further by including more realistic lip sync, so Ignatius also marks the debut of this feature. At first I was a little hesitant to include this much detail in our characters, but James convinced me that it would be worth it for a game like this. Plus, with some of the software he uses to generate the lip sync animations, it actually turns out to be less work than I had imagined, and the results are really smooth and natural. The process of creating these sequences is really fascinating to me, so more on this in a future blog.
Here is the same portion of the game as above, as we developed it in 3D with animation and sound, along with a few other sequences mixed in afterward.
So that's how we went through the process of developing Ignatius from a text character in an interactive fiction game into a 3D animated and speaking NPC model -- a good combination of writing, modeling, texturing, animating, and voice work. That now covers four of the six characters in game -- only two left! Next time, I'll cover the development of Drogo, one of the most difficult characters to capture for a variety of reasons.
Thanks for reading...
Vespers Update 2/18
18 Feb 08
Time for another update, the first since starting this blog. There has been some progress in a few areas, although perhaps not enough to warrant one of my more extensive blogs like on GarageGames.
Vespers Update 2/18
18 Feb 08
Time for another update, the first since starting this blog. There has been some progress in a few areas, although perhaps not enough to warrant one of my more extensive blogs like on GarageGames.
Characters and Animation
Happily, we've finally replaced our previous animator, who left us for more prosperous opportunities. In his place we now have two individuals helping with the character animations, James and Matt, which I hardly have to say is a real gift. Progress on the new characters has been slow so far as we get those two up to speed and comfortable with the art flow. We've also made a few adjustments to what we were doing previously; in addition to entirely new character rigs, we've also been experimenting with a system to provide some pretty nifty lip syncing to go with the voices.
The lip sync process uses a software program called Magpie Pro, which takes the rigged model from 3ds Max and an audio file, analyzes the audio, and generates a text data file that contains all of the keyframe information for setting the model to the accompanying audio. That data file can then be read into 3ds Max, which creates and sets all of the necessary keyframes. It takes a lot of up-front work to rig the model's mouth so that you can create each of the necessary phonemes, but once that's done it's a relatively easy process to generate the data files and import them into Max.
This level of lip syncing may end up being more work than it's worth, but the results so far are pretty impressive and I think it will add to the immersiveness of the game. I'm really looking forward to seeing it in action.
So right now we have Marc working on Ignatius, and James working on Drogo, which should keep me pretty busy in the coming weeks. Both characters are fully rigged, including the facial rigs, and the Ignatius data from Magpie is all ready to go. I'm hoping to see some big progress very soon.
Models
N.R. has been slaving away for us recently, with some pretty awesome results. He's been finishing up the last batch of primary objects to populate the monastery, focusing mostly on the kitchen and dormitory.
Some of his latest work has been a new version of the bed, complete with straw mattress, as well as Constantin's tools and keys. In the text game, the tools actually consisted only of a hammer and some nails, but we decided to expand them a bit to a hammer, tongs, and punch.
The punch can functionally take the place of the nails in the game. We decided to implement all three of the tools as one object to simplify things, although the player can refer to them individually, if desired.
We have a few more objects to create for the kitchen to make it more recognizable -- some pots and pans, some plates to place on the shelves, and some empty hooks for the ceiling. Once these objects are done, that would finish most of the important scenery objects in the game, which would be a nice accomplishment. We'll still need a few more environmental additions to give the place more atmosphere, but the majority of the object work will be done.
In the meantime, N.R. is focusing his attention on the monastery, and trying to portalize the interiors to help optimize performance. Portal construction, as it turns out, is one of the more cruel practical jokes the world of Torque plays on its artists. It's a very complicated and time-consuming process, not to mention fussy and hypersensitive. Breath incorrectly while you're creating portals, and either the exporter will throw up on you or the game engine will laugh in your face. I think it's definitely testing N.R.'s patience. It's unfortunate that it's such a critical part of our model, but if we can get it working I think it will really boost our framerates. I'm keeping my fingers crossed.
Code
Not a whole lot new on the code front. I've mostly been installing more verbs lately, verbs like EAT, DRINK, LOCK, and UNLOCK. New verbs are fairly easy to implement, although the code for performing the actions on specific objects can get a little complicated when they involve playing animations (like for LOCK and UNLOCK) or switching models (like for EAT).
The other significant piece of code that I implemented recently is the "implied take" process. It's commonplace in IF games to allow the player to perform actions on objects without first possessing the object -- in such cases, the engine performs an "implied take". Basically, if the player tries to perform an act that requires possession of the object, the engine will insert a "TAKE" command prior to performing the action. So for instance, if the player tries to UNLOCK HATCH WITH KEYS while the keys are sitting on the floor next to him, the typical IF engine will first perform a TAKE KEYS command before performing the UNLOCK action (if the TAKE action is successful). Most engines will respond with a line such as "(first taking the keys)" or some such message, so this is how I implemented it.
It turns out to be a fairly complicated process. In most cases like this, I would just generate a "TAKE OBJECT" command and run it through the parser, but because of issues that deal with text output (for delivering the appropriate message) and remembering the previous command entered, this would cause problems with my parser. So instead I had to create a separate "implied take" function, and shoehorn it into the existing code.
It wasn't pretty, but on the bright side it did allow me to discover and fix a few previously unknown bugs in the parser. It's working now, but I haven't tested it extensively. Hopefully I didn't end up breaking something else.
There's also the issue of other "implied" verbs, which I haven't tackled yet. I know that opening doors can also trigger an "implied unlock" command, as is done in the game "All Things Devours" (which I highly recommend), for example. I'm not sure how many other implied verbs there are, so it will probably take a bit of searching around.
That's about all for now. Hopefully soon I'll be able to give a more extensive update on our character development, and with any luck perhaps a report on our successful implementation of portals.
Implementing an IF interface in 3D
12 Feb 08
Most of today's graphical adventure games eschew text input and output for more streamlined, symbolic interfaces and visual feedback. The typical IF game is somewhat unique these days in that it relies entirely on text for both purposes. There are advantages and disadvantages to each interface type, but what I want to know is, could a hybrid IF-like interface work in a 3D graphical game?
Implementing an IF interface in 3D
12 Feb 08
Most of today's graphical adventure games eschew text input and output for more streamlined, symbolic interfaces and visual feedback. The typical IF game is somewhat unique these days in that it relies entirely on text for both purposes. There are advantages and disadvantages to each interface type, but what I want to know is, could a hybrid IF-like interface work in a 3D graphical game?
Rather than going into the why, I thought I'd discuss the what, so at least you'll have an idea what I'm talking about and how it might work. Cue the screen shot.
This is a shot of the kitchen, which is still a work in progress. The cupboard is to the left, a table is straight ahead, and a locked hatch in the floor is in the back to the right. At the bottom of the screen is the text output window. Here's a close-up:
The box above the text output window is the command entry window. It pops up when you hit the SPACE bar. You can still move the camera around and click on objects while it's open, although all keypresses are sent to the entry window while it's open.
I wanted to design the interface so that people comfortable with IF could play the game almost entirely with text entry, if they so prefer, even though I don't expect that to be the case. The main exception is movement; there are no text commands directly related to movement, such as compass directions, IN/OUT, UP/DOWN, and so on. These are all performed via the typical FPS-style W-A-S-D setup, with the mouse used for camera panning. But aside from that, most other commands can be entered through the command entry window.
The parser was designed to be comparable to other common parsers, like those from Inform or TADS. It can handle things like actions on multiple objects ("Take the food and the keys"), disambiguation ("Which door did you mean, the bedroom door or the locutory door?"), and completion ("What do you want to unlock the hatch with?"), although I suspect the ability to select objects visually will eliminate much of the need for these. Common abbreviations are supported, such as X for examine, G for again, I for inventory, and so on, although these actions can also be performed by pressing the appropriate key, without having to bring up the command entry window. So "I" will bring up the inventory window, without having to hit SPACE-"I"-ENTER.
Speaking of the inventory, it is implemented graphically as well as through text. The common text presentation is preserved for those comfortable with it, but it is also presented as a separate window:
The items in the inventory are selectable with the mouse, which will then allow you to perform actions on them. So, if you click on the keys to select them (as above), and then hit the "X" key, that would be the equivalent of bringing up the command entry window and typing EXAMINE KEYS.
Despite the inclusion of (and emphasis on) a text input interface, point-and-click is provided and is very useful. Clicking on objects to select them results in the object becoming highlighted visually, as with the cupboard door below:
Once an object is selected, it can then be acted upon either through single-key commands (such as X for EXAMINE, or O for OPEN) or through the command entry window. In the case of the latter, the act of selecting an object allows the player to exclude the object from the text command -- it is automatically assumed to be the object acted upon. So in the example above, with the cupboard door selected, the player could just bring up the command window and enter OPEN, which would be interpreted as OPEN CUPBOARD DOOR.
The same applies for commands requiring two objects, such as unlocking the kitchen hatch:
By selecting the lock, the command can be abbreviated to just UNLOCK WITH KEY, and the parser will interpret the command as UNLOCK LOCK WITH KEY. Likewise, if the inventory screen was open and the key was selected, the player could type UNLOCK LOCK, and the parser would interpret that the same way.
As alluded to in the image above, there are other ways to simplify the performance of actions. The middle mouse button (usually a clickable mouse wheel) can be set to perform one of a list of common actions. Scrolling the mouse wheel flips between the different options, which right now are LOOK, TAKE, EXAMINE, and INVENTORY. Each rotation of the wheel is the equivalent of entering the command "SET MIDDLE MOUSE BUTTON TO < action >" in the entry window, so this could also be done directly via text. Then clicking the middle mouse button performs the action. I typically have it set to TAKE, so I just need to click on an object with the left mouse button to select it, followed by the middle mouse button to TAKE it.
The other customizable key is the TAB key. By default this is set to INVENTORY, but it can also be set to one of the commands above as well using the "SET TAB TO < action >" command.
Aside from the middle mouse button mentioned above, the mouse is reserved for selecting objects (left mouse button) and camera panning (right mouse button click and drag).
It's a lot to remember, no question. I think it will be perceived as a barrier by many people, particularly newcomers. But I do think the basics are fairly straightforward. Most of the shortcuts will probably take some time for players to remember and become comfortable with them, but once they do I think players will be surprised how streamlined most commands are, while still allowing for more advanced command input with the entry window -- which itself can be faster than in traditional IF.
Of course, this is still very much a work in progress, so it will undoubtedly change over time. I thought it would be useful to show how I've approached incorporating an IF-like interface into a 3D world, for future discussions as well as to solicit opinions and suggestions. Both are welcome and appreciated.
A Verb Analysis in IF
9 Feb 08
While preparing some blogs to discuss things like my decision to use a text parser for command input, the oversimplification of the adventure game interface, and a demonstration of our hybrid interface, I started thinking about all of the different verbs used when playing interactive fiction. Because when you really get down to it, the real heart of an adventure game -- aside from the salient features like writing, story, and characters -- is arguably the verbs.
A Verb Analysis in IF
9 Feb 08
While preparing some blogs to discuss things like my decision to use a text parser for command input, the oversimplification of the adventure game interface, and a demonstration of our hybrid interface, I started thinking about all of the different verbs used when playing interactive fiction. Because when you really get down to it, the real heart of an adventure game -- aside from the salient features like writing, story, and characters -- is arguably the verbs.
My impression is that the vast majority of commands in IF are limited to a few categories, like movement or examining. But once you get beyond those common actions, you find the jucier verbs, the ones that seem to have a larger impact on advancing the game and the story. Verbs like PUSH, PUT, WEAR, TURN, or BREAK. And then the rare verbs, the ones that are used maybe once or twice in a game, but have a specific purpose and impact. Like DISLODGE, SUMMON, or ARREST.
But how often are these verbs used in a typical game, and how many of these jucier verbs are there, really?
That's actually a complicated question, for a number of reasons. The main issue is that the frequency of verb use is highly dependent on individual game design, as well as the person playing the game. The frequency of verb use is very different when you compare an experienced IF player with an inexperienced one, and playing style is important, too (I tend to overuse LOOK, EXAMINE, and INVENTORY, for instance -- who knows why, I think it just gives me a sense of "buying time," so to speak, which is silly since IF is turn-based). And it's also very different if you compare a relatively short game, such as those in the annual IF Comp, with a more full-length game.
But in an attempt to initially explore this question, I've decided to take the relatively easy and straightforward route: I downloaded the published walkthroughs for three games entered into the IF Comp in the recent past, and compiled a breakdown of the verbs required for each. Note that these walkthroughs are not necessarily fast solutions -- they include commands that are technically unnecessary for solving the game, but which provide a more complete experience of the game for players who follow them. Still, these are by no means game transcripts, so they don't really reflect the typical use of verbs that one might expect from players. As such, I expect there is a significant underrepresentation of verbs such as EXAMINE, LOOK, SEARCH, ASK, and INVENTORY, among others.
The three games I decided to look at are Floatpoint (by Emily Short), The Elysium Enigma (by Eric Eve), and Tales of the Traveling Swordsman (by Mike Snyder). Below are the breakdowns from each of these games. In order to avoid any spoilers, I chose to leave the graphs unlabeled, and to erase the labels of the least common verbs. I have also grouped together all movement verbs into one group, which includes the compass directions, plus verbs like IN, OUT, ENTER, EXIT, and UP and DOWN.
What to take from all of this?
Well, not a lot, really, given that it's a very small, very biased sample. That said, I think it's no surprise that movement commands and EXAMINE make up a huge chunk of the verbs. But it's interesting that, once you get beyond that, it can be pretty variable, which I think is largely a reflection on game design. It's pretty fascinating that if you look at the top 10 verbs beyond movement and EXAMINE, they are quite different between games.
What I find most interesting from this is the surprisingly large number of verbs included in the walkthroughs for these games. The totals ranged from 34 up to 65. Granted, not all of these are verbs (such as the responses YES and NO), but it's still a surprising range of input. And that doesn't necessarily account for synonyms.
Of course, many of these verbs act on specific objects, and many of those actions are, generally speaking, the only important actions one could perform on those objects. So in theory many of these verbs could be replaced with the generic "use" verb, or a simple context-sensitive menu, as is often done these days in graphical adventure games to simplify the interface. It's more efficient, and players don't have to think about what specific action they want to perform. Plus, it eliminates any "guess the verb" frustrations.
Still, many of these verbs don't act on objects, and provide a deeper level of interaction with the game world. And I think there is definitely something to be said about forcing the player to think about -- and explicitly state -- what he or she wants to do next. Figuring out what to do, not just how to do it, can be part of the challenge of an adventure game, and I think it's something that is missing from today's simplified interfaces.
Many people might respond with a "good riddance", and perhaps that's how most people feel since the market has shown that the simplified interface has been quite successful. But just as I believe there is a role for text output in a graphical adventure game, I also believe there is still a role for text command input, to potentially broaden and deepen the player's experience.
I should state that, with Vespers, we really will have more of a hybrid interface. Movement, of course, will be handled as with many typical FPS games, and many other common commands will be able to be entered quickly, either via the mouse or a single key. That will eliminate a lot of the typing, but it will certainly leave a considerable amount.
Will people see it as a benefit or a barrier? Who knows. That's all part of the experiment. It's one of the things I like about being an indie -- you're not just forced to design to the lowest common denominator.
Oh, and I suppose you might be wondering about the text version of Vespers. Here's the breakdown. Fewer verbs required than some other games, but still a pretty good number. Plus, the walkthrough leaves out a few verbs, and there are also three different walkthroughs, so others might be slightly different.
Al Lowe on adventure puzzles...and text?
6 Feb 08
Rock, Paper, Shotgun has posted a nice interview with Al Lowe, the creator of the famous Leisure Suit Larry series of games from Sierra. I recommend checking it out, as Al provides a nice perspective on those old Sierra games and the current adventure game market.
Al Lowe on adventure puzzles...and text?
6 Feb 08
Rock, Paper, Shotgun has posted a nice interview with Al Lowe, the creator of the famous Leisure Suit Larry series of games from Sierra. I recommend checking it out, as Al provides a nice perspective on those old Sierra games and the current adventure game market.
In it, Al makes an interesting observation that I think is important to reflect upon:
RPS: I’ve noticed that we seem to have lost our patience with puzzles. Developers seem to be frightened of a player getting stuck. Why do you think this happened?AL: I have a definite thought on this. I hesitate to share it as I don’t want it to come out sounding the wrong way, but I believe that in the early 80s, you had to be ridiculously determined just to make those damned computers work. It was near impossible. Set high mem. Deal with QEMM. Customize boot up settings. Hell, I had a whole subdirectory full of autoexec.bat and config.sys files…
RPS: [Large groan as the hideous memories came flooding back]
AL: … I would save off the current pair of files into a subdirectory and copy up another pair so I reboot, all just to run a game. I probably had ten different set-ups. Just geeky shit like that drove people crazy. So puzzle solving was a requirement just to get the damned things to work. And therefore puzzle solving in games fell right into place. It’s what you were already doing. And the parser? It was just like the DOS prompt. You got a flashing cursor and that’s all. If you didn’t know what to type, you had to try things until something worked. Our games were that way. The cursor would flash and you’d think, “What am I supposed to do now?” I remember a conversation once where we speculated, “Won’t it be wonderful when 10% of American households have a computer? Think how great sales will be?” Well, now it’s well over 50% and the people that we added aren’t the people who subscribe to Games Magazine, or solve New York Times crossword puzzles, or watch PBS or BBC America. They’re the people who watch Fox! Their demands for entertainment didn’t include slapping your forehead over and over while you tried to figure out what to do next. They wanted some action… and wanted it now!
An interesting point, for certain, but I think you could apply this answer not just to the question, "Why might players be less tolerant of puzzles?" but also, "Why might players be less tolerant of text-based input in games?"
I think it's a great point that, back in the 80s (and even into the early 90s), the graphical user interface wasn't nearly as ubiquitous as it is now. Heck, I can attest that even the University of Utah hospital in 1997 was still using a DOS-based computer system -- no graphical interface at all. People were used to operating with text. Like Al says, you got a flashing cursor and that's all, and "if you didn't know what to type, you had to try things until something worked." Text was how we communicated, whether with games or with operating systems.
I think there are probably a few things operating here:
1. Perhaps, as the graphical interface became more widespread, people became less tolerant of having to use the keyboard. You could accomplish most things with the mouse, in a much simpler and straightforward fashion. The interface for adventure games likely followed suit, with text commands eventually being replaced with mouse-driven command options, and in many cases with just a simple point-and-click interface.
2. Back then -- and this could be pure recall bias -- it seemed that you had to know more about how to use a computer than you do now. The text interface almost demanded it. But with the rise of the graphical interface, alongside the rise in popularity of computers in general, we perhaps now find that many (if not most) computer users know little about the systems they use. It's one of the main functions of the graphical interface: replacing arcane and enigmatic text commands with simpler and more natural visual representations. Perhaps the old text interface allowed people to be more comfortable with this type of system interaction.
The continued -- and growing -- use of Linux would possibly argue against this to some degree, but I think you could even argue that Linux is rising in popularity, at least in part, because of the graphical interfaces that are now available for it.
A lot of adventure gamers out there now prefer the simpler interface, whether it's as simple as point-and-click, or mouse-driven contextual menus. Text parsers, I believe, have borne the brunt of the responsibility for this, but I think the argument above contributes a great deal as well -- there exists now an alternative which is simpler and less finicky. Text as an input method in games has been all but abandoned, except for the persistent interactive fiction crowd.
With Vespers, I have decided to use text-based input for a number of reasons, which I will likely address in future blogs. But the interface, like the game, is really a hybrid -- there is a point-and-click interface with mouse-driven commands in addition to the text parser. I think, if you could look at transcripts of a large sample of IF games, that the vast majority of commands issued by players would amount to the compass directions and movement (N,S,E,W), LOOK, EXAMINE, TAKE, and INVENTORY. I don't have any hard numbers to back me up, but I would guess that these would account for somewhere around 75%-80% of all commands in a given game. In our hybrid game, these are all commands that can be issued with either the mouse or with a single key on the keyboard (e.g., X for EXAMINE).
Still, will players tolerate any text input? In general, I think players don't like the thought of having to use the keyboard -- or to switch between the mouse and keyboard. But we'll see. I think the benefits, which I'll discuss later, still outweigh what I feel is a (relatively) small inconvenience.
Catching up with Vespers
5 Feb 08
Although The Monk's Brew is a new blog, I've been blogging for some time on my progress with Vespers over at GarageGames.com, the makers of the 3D engine I am using (Torque Game Engine). I thought the beginning of this blog would be a good place to collect those initial reports, in case anyone would ever care to go back and review my development process and progress. All new blogs from this point will be posted here on TMB. Here are the links to the blogs, in chronological order:
Catching up with Vespers
5 Feb 08
Although The Monk's Brew is a new blog, I've been blogging for some time on my progress with Vespers over at GarageGames.com, the makers of the 3D engine I am using (Torque Game Engine). I thought the beginning of this blog would be a good place to collect those initial reports, in case anyone would ever care to go back and review my development process and progress. All new blogs from this point will be posted here on TMB. Here are the links to the blogs, in chronological order:
Chasing Windmills?
11/8/05
In which I first discuss my decision to pursue a hybrid of interactive fiction and a first-person 3D engine.
"Vespers3D"
12/30/05
In which I discuss my initial attempts at creating a text parser within the Torque Game Engine, and my enlistment of Jason Devlin and "Vespers" as the experimental game.
Vespers3D: The Adventure of Text Parsing
3/9/06
I which I discuss some of the challenges of implementing a text parser within a 3D world, partcularly how to deal with objects that don't have physical representation in the 3D environment.
Vespers3D: The Adventure Continues
5/31/06
In which I discuss the implementation of the visual inventory, visual object higlighting, and the horrors of text parsing such as disambiguation and multiple objects.
Vespers3D: Living the Adventure
10/16/06
In which I discuss our choice of company name (Orange River Studio), customizing command inputs, a new opening intro sequence, and the implementation of purely informational verbs such as LOOK, LISTEN, and EXAMINE within a 3D environment.
Vespers3D: Adventuring Along
1/22/07
In which I discuss implementing command completion within the text parser, the introduction of our first NPC (Matteo), and the auditions for our voiceovers.
Vespers3D: Adventures in Cinematics, Part I
4/26/07
In which I discuss how I implemented the cinematic animations in the game using a sequence manager and triggers.
Vespers3D: Adventures in Cinematics, Part II
6/17/07
In which I continue to discuss the implementation of the sequence manager and animation states.
Vespers3D: Adventures with NPCs, Part I
6/30/07
In which I discuss the development of our first NPC, Matteo, from text to concept to animated and voice-acted 3D model.
Vespers3D: Adventures with NPCs, Part II
7/25/07
In which I discuss the development of our second NPC, Constantin, from text to concept to animated and voice-acted 3D model.
Vespers3D: Visibility Issues in 3D
8/6/07
In which I discuss some of the real problems with referencing objects in a 3D world due to complex collisions and collision checking.
Vespers3D: Adventures with NPCs, Part III
9/3/07
In which I discuss the development of our third NPC, Lucca, from text to concept to animated and voice-acted 3D model.
Vespers3D: Adventuring Onward
12/28/07
In which I discuss ongoing issues with animation, the new opening intro sequence and music, and the implementation of the objects in the church.
Follow us on...
Latest Tweet
More Information
Tell A Friend About Us!
