Wrapping Up At the GDC Austin

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

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

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

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

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

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

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

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

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

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

A Moment To Pause and Catch My Breath

Well, that was a bit longer hiatus than I was expecting, but there you have it. It was quite a July and August. Mixed in with an impossible workload, particularly in August, was a couple of vacations (including an awesome backpacking trip to Yosemite National Park, which required more preparation than I had expected) and a big deadline. Yeah, that deadline. It's amazing, particularly without having children, how easily free time can get sucked away before you realize it. So just about every spare minute I could find was spent working on my presentation, which has left very little time for any Vespers work recently.

I've given a lot of scientific talks and lectures before, and it's pretty rare to have to prepare my talk well in advance. On only a handful of occasions can I remember having to turn in my slides before I gave the talk, which (given my nature) means that I can and do work on the slides right up until the talk itself. Not so in this case, which I can understand for a conference like this. They wanted the slides just under a month before the talk, which is great in theory (they have the slides in hand, the talk is basically done well in advance) but painful in practice. Juggling a stressful time at work with vacation preparations (and vacation itself), along with finishing up my presentation before the deadline, was, in hindsight, a less than ideal experience for me.

But I will readily admit, despite it being completely against my nature, it's great to have my slides done at this point, with just some minor tweaking left to do. At the same time, though, I'm growing a little uneasy. With all of the talks and lectures I've given in the past, I'm very comfortable presenting material in front of a crowd – but nothing in the past really compares to this. To give a good talk, I think it's important not just to know your topic, but to also know how to present your topic. For me, science is straightforward. Interactive fiction, not so much. Although there are many people out there in the IF community that know this topic far better, I believe I have enough of a handle on it to be informative to those less familiar with the field. But I suspect lecturing about IF is probably similar in many ways to lecturing about literature, and the skillset for presenting material like that is largely different than for presenting scientific research.

For instance, particularly challenging for me is how to present and discuss specific examples of major points. It's one thing to discuss "games that incorporate meaningful choice" as a topic, but another to relate that to a specific game – at least without reviewing large portions of game transcripts and spoilering the hell out of it (while also boring the audience to tears). It's also tough to review specific examples with an audience this size. IF doesn't lend itself well to screenshots or brief demo movies. There's no bar graph to slap up on the screen and describe in detail.

In the end, I'll mostly discuss techniques and strategies from a fairly birds-eye view, and discuss specific game examples briefly without presenting too much detail. I think that should suffice, and if I do a good job of reviewing IF and showing some of its unique aspects, I'll hopefully arouse enough interest and curiosity to get people to try some of the games I'll be discussing to see for themselves how those techniques are implemented, and if they work for them.

The games I'll be discussing, to various degrees (some I only briefly mention, others I spend a little more time on), include Eric Eve's Blighted Isle, Adam Cadre's Varicella, Aaron Reed's Blue Lacuna, Emily Short's Galatea, the multi-author Alabaster, VIctor Gijsbers's The Baron, and Michael Gentry's Anchorhead. And by the way, the more time I spend with Blue Lacuna, the more I am struck by how massive and impressive that piece is.

I thought it would be tough to come up with 60 minutes worth of material, but (as is usually the case) I'm now wondering how I could possibly fit all of this material into "only" 60 minutes. I generally aim for one slide per minute, but the final number is actually 70 slides. That's too many, although there are at least a dozen slides in there that are quick intros, nothing more. I'll practice, and it should be okay.

By the way, in case you were wondering where a talk about IF might place on the Great Anticipation Scale at the GDC, a quick look at the schedule might offer some insight.



That's me, scheduled in the morning at the same time as the Wednesday Keynote Address.

Ah well. It's about MMO's anyway – and seriously, who cares about those these days?

Gulp

This, to be perfectly honest, isn't something I ever expected to see.

It certainly does make it real. I was hoping to put together something like a panel discussion to take some of the pressure off, but that turned out to be more complicated than I thought. So there it is, and here I am, all jittery and uneasy two months in advance and hoping that I can come up with enough interesting material to justify this trust I've been given.

The AGDC Game Writers Summit web page has been updated with most of the sessions, so I have been able to glance at some of the company I have been placed in. Looks like there are some big designers and writers from Valve, Eidos, Sony Online, Red Storm, and Ubisoft. Wonderful. And there are some really interesting talks planned, such as Mary de Marle's "Redefining Our Role in Crafting Player Driven Narratives", and Aaron Oldenburg's "Intuitive Design of Interactive Narrative: The Mischief of Created Things". Should be very cool, and that's only the Game Writers summit.

And then, get this, there's some freak from--wait, where is he from again?--who's actually going to talk about interactive fiction. No, seriously. It says so right there, at the bottom.

Right. Well, off to work, then.

IF@AGDC

So apparently the powers that be at the Austin GDC were curious enough about modern interactive fiction to give it the floor (part of it anyway), for a few minutes at least. I received notice the other day that my proposal for a talk on "game design innovations in IF" was accepted for presentation during the Game Writers Summit. I'm pretty happy about that, especially considering that last year I found the Game Writers Summit to be the most interesting part of AGDC. I'm curious to see how many people are intrigued enough by the topic to attend. I'm hoping it's more than four.

Of course, the e-mail notice was soon followed by one of those "Oh shit" moments. I suppose this means I actually have to do it now.

That happens on occasion in the day job. We submit grants all the time for various ambitious research projects, and we're pretty used to rejection. But, occasionally, we do just enough to bullshit our way past the review committees and the work gets funded. Yayz. Except usually it's quickly followed by a collective, audible *gulp*.

So, we'll see how this goes. Many thanks to the people who supported this and helped with the editing. I'll be preparing the talk throughout the summer, so if anyone is interested to see how it evolves, just let me know and I'll keep you updated on it. Below is the synopsis of the talk that will appear in the program guide, which is pretty similar to what I had posted earlier. If you're interested in seeing the whole abstract, just drop me a line and I'll e-mail it to you.

"What's old is new again: game design innovations in interactive fiction"

Synopsis: The modern commercial game industry is frequently criticized for a reluctance toward innovation. Although independent game developers, to a certain extent, have accepted the challenge of advancing innovation in game design, another small but devoted group of individuals has been doing this for years, behind the scenes, in a genre largely overlooked in gaming circles: interactive fiction, formerly known as text adventures. A closer look at the many ways in which this medium has evolved over the years will reveal a number of techniques and strategies that game developers, mainstream and independent alike, might consider exploring and translating to their own genres and projects.

The One Thing He Forgot To Mention

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

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

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

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

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

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

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

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

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

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

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

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

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

The End of January Vespers Thing

January was a very busy month for the game, and I feel like we've made some great progress on a number of fronts. I think part of the reason is that we had set a goal for ourselves: try as hard as we could to get most of the work for Act I finished by January 29th, the date of the first Utah Indie Gamers night of 2009, so we could show it off in public. Setting goals can be useful for getting people focused on particular tasks, and it's probably a good way to work even when those goals aren't met.

Which is a good thing, because we didn't meet that goal.

Which itself is probably a good thing, because I wouldn't have been able to show it off at the Utah Indie Gamers night anyway. This past Tuesday morning, I recall having a slight wispy cough as I left for work; by late Tuesday night, I was begging for mercy. The microbes have barely let up on their stranglehold since. I was pretty sure this was influenza (despite getting my flu shot), although some of my colleagues tell me a similar bug called parainfluenza is making the rounds here these days, and the symptoms are similar. It matters little, they both suck. There are few things more humbling than sleeping on the bathroom floor (because the bedroom garbage can was already full of my heaving) or shaking with chills on the couch despite layer upon layer of clothing and blankets. The Utah Indie Gamers night was Thursday. By then I was only feverish. Now I'm finally not feverish, but I've been reduced to little more than a cough, mucus, and virus factory.

But enough of that. The Vespers engine code is up to version 04k with the addition of a few lines to detect animation triggers. The Torque animation exporter allows you to set keyframes within animation sequences that act as triggers for whatever response you want, which you can specify in the object's onAnimationTrigger method. Like most things that involve the Torque model and animation exporter, it takes a bit of time to figure out precisely how to set this up, but I believe I have it working now with Constantin. I'm now using triggers to specify when to play the scraping sound of the knife skinning the hare, which is nicely timed with the motion of the knife. I'm also using it to more smoothly transition between his idle animations. That should prove to be a very useful tool in the future.

Constantin video. Best viewed in High Quality (bottom right corner).
(Might need to turn up the volume to hear it.)

A lot of the progress in January has been with the animations. Shawn has been working his tail off, and we're now basically finished with the Act I animations for Ignatius, Constantin, and Matteo. The latter two were already animated by our previous guy, but we needed to re-do them for a couple of reasons: first, the animations weren't so great and we wanted to improve them while adding lip sync; and second, we would need re-rigged characters for the first cutscene anyway. Constantin looks tremendously better now than he did before (even my wife noted this), with much smoother and more interesting motions. The same goes for Matteo.

Lem continues to work on Lucca, although it's going slow for him. But that just leaves Drogo and Cecilia, and once those two are finished, we should have ourselves an actual, complete Act I. Add a cutscene on top of that, and we might just have ourselves a working demo. Soon.

Despite having some family issues that demanded his attention for a while, N.R. made some nice progress in January mostly on the 2D front. Most of his efforts were directed at spiffing up the GUI and HUD elements for the game, and I'm very happy with the results. In addition to updated window frames, he designed really nice Options and Help window GUIs, incorporating some of the elements from the church fresco designed by Régis.

Options dialog.
He also incorporated a sweet ribbon design with a medieval image he obtained and utilized in the Main Menu GUI.

Main menu screen.
(Click for larger version)

He's also been working on additional visual goodies such as a more realistic and bloody stone for Lucca to scrape at, and a more interesting and natural appearance to the top of the belltower, exposing the floor boards while mounding snow around the outsides.

The new bloody flagstone.
(Click for larger version)

The updated top of the belltower.
(Click for larger version)

N.R. also spent a crazy amount of time working on a new Orange River Studio logo design for me during January, and I think we're getting close. By next month's update we should have a design finalized. N.R. has been dealing with a lot this month and I'm amazed that he's been able to get as much done as he has, and he continues to do some pretty amazing work. I am a very lucky person.

Despite my bitching about fonts earlier this month, I'm still in negotiations with the P22 foundry for a much more reasonable licensing fee for the Cezanne typeface, which is good news. I really like the font and I appreciate it for what it offers, and it's nice to know the P22 guys are very much open to creative solutions for this and are willing to work with small developers like me. I'm pretty confident it will work out well, and I'm really looking forward to settling on that font once and for all.

Finally, as I reported last month, we decided to try a little something different and utlize Pieter Bruegel's famous painting, The Triumph of Death, as the main background for our opening splash screen. I tried a couple of new things with the splash screen, including some nice closeups and crossfades, and I'm very satisfied with how it turned out. I'd like to go over some of the Torque-specific techniques I used to create it in another blog, hopefully during February.

So despite the bloody, protracted battle with the microbes, January turned out to be a very productive month for Vespers, and I'm looking forward to a good February as well.

Curse My Expensive Font Tastes

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

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

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

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

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

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

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

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

Flute

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

Cezanne

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

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

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

Whitechapel

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

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

Secret Scrypt

Curse my expensive font tastes.

Write from the Start

So pretty much one of the most challenging parts of making games for the small indie or hobbyist developer is getting the extra help you need. The developer who can do it all on his or her own -- programming, artwork, writing, modeling, animation, web design, yada yada -- is a rare breed with far too much talent and disposable time. When I made Missions of the Reliant way back when, in (gulp) 1994, I could handle most of it myself because things were just...simpler. I didn't have to worry about modeling or animation, and web design meant little more than plain text and a few animated GIFs (mostly I just focused on BBS's and AOL -- and, sadly enough, eWorld). Life, as they say, was so much easier when we were young.

Unless you start from the beginning with a set of partners, it's tough to find people who are willing to put the necessary time and effort into your project, particularly if they're not being paid. But once you start paying people to provide the services you need, the expenses can start piling up fast. That's especially true for modelers, animators, and 2D artists, where the good stuff usually doesn't come cheap. And since the majority of small indie and hobbyist developers who initiate new game projects are programmers, not artists, you end up with a lot of projects that die on the vine because they just can't obtain or afford the artwork that is needed. As one person I knew said, it's cheaper to program than to create art.

A while back, as these thoughts were bouncing around inside my head, I began to wonder how different it might be if a game project was started by a visual artist rather than a programmer. I started a thread on the GarageGames forums to see if people were familiar with any such projects, and it turned out to be a pretty long thread. Some good thoughts there, but not a lot of games that started with the artist and lasted through to completion and release.

That was a couple of years ago, though, and I know of (or suspect) a few examples since. One that came up recently, as reflected upon by Chris over at The Artful Gamer, is the Quest for Glory II remake by AGDInteractive through the efforts of artist Eriq Chang. As Chris notes:

"I call this a 'renaissance' of computer game re-makes because the creative torch has finally been returned to artists. Instead of designing and conceiving games from scratch without any attention to their expressive qualities (as we see in most commercial games), AGDInteractive (has) put artists behind the wheel and allowed them to drive the creative process."

But I'm not really here to discuss how visual artists can drive creative game development. The reason I bring this up is because I was reminded of this topic during a recent web chat about a similar concept.

Back at the Austin GDC last year, I found myself most interested in the discussions and talks on game writing, and through those interactions I was introduced to the Game Writers SIG, a "community of game writers whose goal is to improve the quality of games writing by increasing overall awareness of the craft of games writing and how it fits into the game development process." Although it's not exactly my specialty, I enjoy following the e-mail list discussions from a distance. Anyone else interested in signing up for the mailing list can check out their sign-up page.

One of the topics that often comes up on the list is how to better promote the idea that writers should be involved in the videogame development process much earlier than they typically are. What often seems to be the case, as I understand it, is that writers are engaged well after a game has been designed, such that the writers are frequently asked to fill in gaps or otherwise work within a well-established framework that has little chance of being altered much. As such, there is little opportunity to shape the project from the beginning, or to impact game design and gameplay mechanics through the writing process.

Something like this was brought up again on the SIG's monthly (roughly) chat meeting, which I checked out for the first time this past week. The discussion turned to the creation of a list of arguments the group could use to convince game companies of the benefit of hiring and involving writers. One member, Reid, posed the following question:

"Here's an idea. What if the SIG made a small game to showcase the value of writers when they have more creative control and are brought in early?"

In response, Corvus brought up the idea of using Inform to create a piece of interactive fiction. Nice idea, I would have to say. But then again, there are already plenty of excellent IF games already out there that have been written by, you know, writers. Is the problem that game companies aren't familiar enough with good IF games, and they just need someone to make them take a closer look? Or is it perhaps because companies that make graphical games might not be terribly interested in what text-only IF games might have to offer?

I don't know the answer to that, and maybe I'm missing the mark, but I do know how I feel about the whole idea -- it forms the basis for the Vespers project. When I started this thing, the goal was to create a 3D first-person adventure game that was based on an established interactive fiction game. The main reason was to see how a typical text-based interactive fiction game would mesh with a visual 3D interface, but just as importantly, the idea was to start with a game that was fully designed and written by a writer. That's one of the big advantages to having started with Jason's Vespers game -- the plot, dialogue, characters, setting, puzzles, all of it was already written, tested, played, and critiqued. We knew what worked well, and what didn't. Characters and setting were already nicely fleshed out. All we needed to do (easy for me to say) was to take that entire game design and translate it from text to graphics, while still keeping most of the text.

In the end, Vespers might not necessarily be the best example to show game development companies to convince them of the value of starting with a game writer, but I certainly hope it will encompass this idea and at least help move the field in this general direction. That's the goal, at least.

A secondary but related goal is to use this game as an example of what, specifically, interactive fiction has to offer to the mainstream videogame industry. While I wouldn't necessarily describe IF as a "mature" medium, it has been around considerably longer than most other types of videogames and, as such, I believe it has a maturity that perhaps other genres lack. This extends to some of the more interesting areas of game design (at least to me) -- puzzle design, narrative design, character development, and conversation dynamics, to name a few. I think there is a lot that mainstream game designers can learn from some of the better or more advanced IF games. It's an overlooked genre and community, and it's something I plan on submitting to an upcoming GDC for a lecture and/or group discussion. We'll see if anyone's listening.

Feedback For Better IF Parsing

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

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

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

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

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

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

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

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

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

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

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

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

The End of October Vespers Thing

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

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

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

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

• Sometimes thicker portals experience problems.


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


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

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

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

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


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


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

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

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

The results so far have been mostly good.

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

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

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

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

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

Until next time...

Day Three (at the AGDC), Part Two

As I mentioned last time, there were some really intriguing presentations on the third day of the conference. One in particular was a technology demonstration given by representatives of two companies, Emotiv Systems and 3DV Systems, which are developing innovative ways for players to interface with computers or other entertainment devices.

Randy Breen from Emotiv Systems demonstrated what he called their "Brain-Computer Interface", a device that fits on the head and is based on EEG machines. It basically translates brain waves into actions after a period of training. It's compact (I didn't even notice him wearing it during his talk), lightweight, and wireless, and includes a gyro to detect head movements. It can also detect facial expressions (blinking, smiling, eyebrow movement) and can essentially monitor emotional states. It can also detect cognitive intent to manipulate objects. Wild, but apparently true.

During the demo, he displayed the tool's SDK which exposed the various detections, and displayed an avatar mimicing his behavior -- blinking when he blinked, raising eyebrows when he did, smiling along with him. He envisions the eventual ability to move lips along with audio to visually represent speech. His last demonstration was of cognitive action: he was able to move a 3D block on screen merely by thinking about it. He then showed how the tool can be trained to perform other cognitive actions, like making the block disappear just by thinking it. Very slick.

It looked as though the tool and its software still have a ways to go before it is fast, smooth, and widely applicable. But it was nevertheless impressive, and appears to offer a ton of possibilities for games in the future.

Next was Charles Bellfield from 3DV Systems, who demonstrated their camera-based tool for detecting and harnessing player motion. Although I didn't understand much of how it worked, it appears as though a sophisticated camera/detector sits on top of a computer screen or television and sends out light waves, measuring the amount of light that reflects back from the individual and using that information to generate a fairly detailed greyscale image of the person's shape -- parts of the person that are closer appear lighter, providing a real-time, three-dimensional, depth-based representation of the subject. They are also able to specify how far from the camera the light should be detected, making it easy to remove all background and focus entirely on the subject. And, though special techniques that I didn't catch, they're able to make the system track different targets on the subject, such as hands, fingertips, feet, and so on.

The demonstrations were very cool: a flight simulator application where the plane is steered by the players hands mimicing the holding of a yoke (and guns fired by the movement of his thumbs); a kickboxing simulation that responds accurately to the player's punching and kicking motions. Even height of the player becomes important, such as in the kickboxing simulation, since the tool can detect height and translate that into the application, providing a more accurate and detailed response.

This system appeared a little closer to being ready for prime time, and could advance the incorporation of player motion into gaming in a fashion similar to the Wiimote, only without the need for a remote at all. All in all, a very cool set of presentations, and I'd really like to see how these tools make it into the marketplace.

The last presentation that I went to was given by Adrian Hon from Six To Start, who discussed the "We Tell Stories" digital fiction project from Penguin Books. This was the project a little while back that presented six alternative stories by six different authors over six weeks, each using a unique form of presentation. "The 21 Steps" by Charles Cumming was a story told through Google Maps; "Slice" by Toby Litt was a slow-motion horror story that was blog- and twitter-based; "Fairy Tales" by Kevin Brooks was a fairy-tale-maker story with a simplistic, branching narrative similar to a CYOA; "Your Place and Mine" by Nicci French was a psychologic thriller/horror story written in real time, one hour per day over five days, similar to improvisational storytelling; "Hard Times" by Matt Mason and Nicholas Felton was more like an essay, and may have suceeded less because of this.

The sixth and last story was "The (Former) General in His Labyrinth" by Mohsin Hamid, a tale about the now former Pakistani leader written in a CYOA with HTML style, a sort-of hybrid CYOA/text adventure/dungeon map, as Hon put it, although I think that's a slight bit of a stretch. Still, the design is intriguing. The player essentially chooses the path through the story by clicking on different directional arrows; although the movement through the story is tracked visually with a "storymap", the movement is not location-based but rather story node-based. That is to say, movement to one particular node represents a particular choice and reveals a specific portion of the narrative, with the map showing which nodes have been visited, and the story changes based on the nodes that have been visited. What's interesting is that the author designed it such that there is no repetition when re-visiting nodes -- the story changes, even if slightly, when backtracking, and some portions of the storymap are designed as loops that "play" differently when traversed clockwise as opposed to counterclockwise. It sounded like a clever design, and I'll have to try that one for certain.

The remainder of Hon's talk was about storytelling in games, and although it covered much of the usual ground, it was refreshing to hear it from the perspective of the literary scene rather than the gaming scene. One point he specifically made was that most readers (as opposed to gamers) have little to no desire to see interactivity in their stories -- or, alternatively, they don't think interactivity automatically makes story better -- which is interesting in light of the desire of some IF supporters to see the medium reach out to a more reader-oriented audience. He himself believed that stories in games are (or will be) better because they are interactive, but we still have a long way to go -- its not easy to write a story, as he said, and a good story in a game requires writers with sufficient independence and the trust and respect of the designers. Like Andrew Stern's talk earlier in the day, it triggered a good deal of stimulating discussion from the audience, which was refreshing to see, and the sign of a thoughtful, engaging talk.

Day Three (at the AGDC): Stern on Linear Storytelling

The last day of AGDC was an excellent day, with two talks in particular that led to a good deal of spirited, academic discussion about storytelling and a third lecture that demonstrated some very slick next-gen controllers that could have a significant impact in the future on game design and interface.

The first talk of the day was given by Andrew Stern, he of Façade fame, although he did not focus specifically on the accomplishments of that project. Instead, his talk, provocatively titled "Linearity is Hell: Achieving Truly Dynamic Stories in Games," explored the possibility of truly dynamic storytelling in games and how a system like that might be designed. Stern did acknowledge that this was more of a theoretical talk and that he has no claim to a solution for this; rather, he was hoping to express his understanding of what such a system might entail.

He began by describing the well-known problem of combinatorial explosiveness that typically characterizes systems that try to accomodate branching storylines, and proceeded to offer that one solution to this would be "story generativity", or a system that generates story nodes on the fly (akin to "procedural storytelling"), which would be capable of providing players with the Big Three game elements we seem to most covet: freedom, well-formed story, and agency; whereas most games these days are typically able to provide at most two of those three.

Without going into too much detail here, he related this type of system most closely with improvisational theater, and the Oz Project in particular, where improv actors received direction through headsets for a single independent participant. The idea for a dynamic storytelling game, generally speaking, is to accomplish something similar through the creation of behaviors for NPCs which help direct and guide them through a narrative scene, encompassing such things as motivations, goals, dynamics, and dialog.

Interestingly, Stern briefly discussed what he called a "calculus" for NPC dynamics, which comprised defining different narrative states to track, and then using various approaches to compute the narrative state; for instance, with a narrative state of romantic interest, the idea is to use a calculus (fuzzy, algebraic, statistical, etc.) to evaluate things like flirtations, responses to NPC advances, tone and language of the player, and so on. It immediately brough to mind some of the approaches embraced by Chris Crawford, specifically the use of mathematics and algorithms for different aspects of character appraisal and storytelling, so perhaps there are some similarities there.

He did acknowledge that the type of system he described would be more adept at generating sequences rather than sentences, and in that respect the system would probably not be generative enough to be a true end product. But to me it seemed that the real challenge is precisely in going from structure to presentation; that is, while the mechanics of creating and manipulating the components of story, including character motivations and behaviors in response to (or in lieu of) player actions, do appear to have features amenable to mathematical or algorithmic control, it's the process of taking the product of those calculations and algorithms and working them into a coherent narrative where the true challenges lie ahead. And I would propose that this final step, the delivery of the story, is where much of the art of storytelling exists -- stories can easily be broken down to reveal their components and structure, but the presentation of that structure is dependent on the skill of the storyteller. Can that ever be done procedurally? In a way that is artistic and moving?

I'm reminded again of Crawford, this time of the product of his work on the Storytron, after playing a bit with the online demo of Balance of Power: 21st Century. There's much I could write about the system, and it's clear a massive amount of work has gone into the modeling and implementation of relationships and character interactions -- certainly a significant accomplishment. I don't know Crawford's intentions for the system beyond BoP:21K, or whether future storygames (like the one in progress by his colleague, Laura Mixon) will look or play differently, so I could be off base; right now, though, the presentation has the look and feel of a basic story structure and its components, with none of the crucial dressing of language and style that an author provides. That is to say, the storygame is plenty of substance without any style. Does this work? Perhaps for others, not so much for me. Could it be more? I'm not sure.

The discussion that followed the talk was spirited and entertaining. Points raised included how a system like this could incorporate certain issues with language, writing style, and humor, which are notoriously difficult to reproduce procedurally. Others noted that the system he described sounds like something better suited to drama management than actual end-dialog or behavior generation, and that perhaps it matters more how the story is delivered rather than constructed. Stern argued that this type of system does not have to entirely remove the author's voice from the output, and that he sees it as more of a 50/50 relationship. I think the system is still too theoretical to be able to envision that myself.

I guess it really comes down to the question of what we really want from the stories in our games, and which we find more influential: substance, or style? Personally, I think both play an important role, but it's still too difficult to imagine a system that can procedurally handle both with equal skill.

It's fair to say, though, that Stern's talk was accepted by the speaker and audience as mostly hypothesis, with the intention of stimulating discussion and debate. And in that sense, I think the talk succeeded far better than most at the conference. Plenty of people stayed behind afterward to continue the discussion, and it's likely to continue even longer on e-mail discussions and blogs. And it made for a very entertaining and enjoyable experience.

More to come later on the rest of Day Three as I get back in the swing of things.

Playing the Protagonist Part, Partly

A blog entry and discussion over at Corvus Elrod's Man Bytes Blog about character and plot got me thinking about that tricky relationship between the player and protagonist, and the expectations (and allowances) game authors often place on their players.

In some games -- typically non-first person games -- the player is asked to play the role of a particular character. In Dreamfall, the player starts out playing the role of Zoe; in Tomb Raider, Lara Croft; in Deus Ex, J.C. Denton. In many interactive fiction games, the same applies, such as the Abbot in Vespers. In many instances, the protagonist has a history, and in some cases a personality, but inserting the player into that role can produce a frustrating conflict when player behavior does not necessarily match what might be expected from the established character.

To a certain extent, authors expect players to perform at least a minimal amount of role-playing with the game's protagonist. In some cases, more than the minimum is expected. As Jimmy Maher once said in a comment on this blog, "I don't think it's too much to ask my player to accept the premise and situation of the story she is in, and to behave in a reasonable manner." Which means that it's generally okay to discourage unreasonable play that extends beyond the border of acceptable behavior--acceptable in general (no, you can't eat your sword), or for the context of the story (no, you can't start punching your friends just for fun).

The problem is that gamers enjoy pushing limits. As Corvus said, "I too often enjoy subverting a game's intended design." It's fun to do, I'll admit it. I've often played games and at times tested the system to see how it would respond to unexpected or inappropriate behavior. It's something of a reward to see a game respond to a particular action that is otherwise inappropriate.

What's funny is that game designers invite that sort of behavior by implementing responses to it. For instance, how many interactive fiction games implement a witty response to the XYZZY command, even though there is naturally no place or reason for using it? If no game other than Colossal Cave had a response to that command, nobody would be tempted to give it a try. And if there is a response implemented for that command, how many other interesting goodies like that might there be to discover? How many of us who played the original Warcraft sat there clicking repeatedly on their individual units to see how many different annoyed responses it would elicit? It's a form of exploration, I suppose.

Granted, this is a bit different than the topic of role-playing, but I think the same principle applies. Still, in the situation of role-playing, accounting for different types of behavior, even bizarre behavior, can actually work to the game's advantage. Take Façade, for instance. Wasn't it at least as interesting to play the game while trying inappropriate or unacceptable actions, just to see how the characters would respond? And in many cases, they did respond -- by being shocked and surprised. That type of behavior was anticipated, even though it did not fit at all with the protagonist's character, and it altered the relationship between the protagonist and the other characters in ways that might be expected, providing a sort of internal validity to the game.

This would seem to support what Corvus said in his blog comments the other day:

"The problem, as I see it, is that the story itself is still widely considered to be a separate layer of the game from the game mechanics. The end result is a severe disconnect between what NPCs are saying to you and your behavior. Until such time as player actions, all player actions, are directly interpreted as components of the story...it’s not going to be solved, either."

In other words, all player actions, not just critical ones, need to be interpreted by the game within the context of the character performing the action (his or her personality and relationships) and the situation within the narrative. So it's okay if a player, who is playing the part of a character not known for violence, really does want to perform a violent act on another character, as long as the game and its story account for it. As Corvus says:

"How much more exciting will that become when your actions have immediate and direct consequences? When the targets of your inanity say, 'Well if you're going to hit me with a bicycle, I'm not going to tell you where the meeting is being held!'"

The difficulty with this approach, at least for the game designer, is that it's a ridiculous amount of work to try and account for every possible action in every situation of the game, and the effect of those actions on all of the different characters in the game. And it's also somewhat different for turn-based games with discrete actions, such as interactive fiction, and real-time 3D games that allow players to run around, jump up and down, pick up and throw objects, and so on, all while an NPC is trying to talk to you about something; the options for inane behavior are exponential. The complexity of a system designed to handle and interpret these actions in all different game situations would be staggering.

I'm mostly rambling here, and I'm not entirely certain what the point of all of this is or where it's going. I guess I'm just interested in hearing what others think about the relationships between designer, player, and protagonist, and the expectations that each brings to the table.