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.
September 18, 2009
Wrapping Up At the GDC Austin
January 25, 2009
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.
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.
June 20, 2008
Conversations with NPCs
As Corvus Elrod likes to say, compelling stories arise primarily from the relationships between characters. Although these relationships can be generated or expressed in different ways, I think it's fair to say that conversation is probably the most obvious and frequently used method in games. Yet it's interesting to note that conversation systems in games are fairly rudimentary and, in many cases, pretty unsatisfying.
There are many reasons for that, of course; human conversation can be horrifically complicated to deconstruct, and dynamically generating realistic and meaningful conversation with computer-controlled characters is still years away, especially when you factor audio into the equation. As a result, most conversation systems in games are simplistic representations that often follow tight scripts and leave little room for exploration, which is probably fine with most developers; it's difficult and time-consuming to create sophisticated interactive conversation, particularly without forcing players to use text-based input, and most text entry in mainstream games was abandoned some time ago. In the end, conversation is typically an insignificant component of gameplay, demanding barely more thought from players than a cutscene might.
I don't have nearly the range of experience with games that many other people have, but I would venture to say that the conversation systems in most graphical, mainstream games fall under one of two general classes:
1. Click to speak. The simplest system, where you just click on an NPC or hit a single key to trigger conversation. The player typically has no control over the topic of conversation or what the player character says, generally or specifically.
2. Multiple choice dialog trees. Players select from a limited list of speech options, which helps direct the conversation to some extent.
I'm sure there are mainstream games with variations on these that I've missed or forgotten, but they are less common. Nevertheless, I have yet to see a conversation system in a graphical, mainstream game that is particularly satisfying. Most games that use #1 generally are just using conversation as a means of advancing a storyline, without really incorporating conversation into gameplay in any significant way. Systems related to #2 do at least involve some thoughtful input on the part of the player, and because the choices presented are often specific player quotations, the resulting conversation can seem much more natural while also providing some degree of characterization for the player character. On the other hand, this type of system also encourages a "lawnmower" approach of trying all options, even if it requires re-initiating the conversation or using the save/restore approaches. There is thus little consequence to making those choices, especially if the different conversation branches just lead to the same end point anyway, as is often the case.
It's probably clear to readers here that I think interactive fiction has a leg up on other game genres in many areas, and conversation is one of those areas. But why is that? Is it because the medium has more conversation tools at its disposal? Is it because text-based input (and output) allows a greater range of conversation possibilities?
I don't necessarily think so.
A while back Emily Short created what is essentially the seminal piece on conversation systems in IF, and there's little reason to rehash what she so comprehensively covered. For those not as familiar with IF or her essay, I'll just summarize the most common IF conversation systems, which mirror those mentioned above in graphical games. The three most common are:
1. TALK. Players just type TALK TO
2. Topic-based conversation. The most common form is the ASK/TELL system, where players type ASK
3. Multiple choice dialog trees. Same as mentioned earlier. Unlike with the ASK/TELL and TALK systems, players have a pretty good idea what specifically they will be saying or asking with the NPC, rather than generally. Particularly in a text game, this can provide a better degree of characterization. On the other hand, all potential choices are patent, leaving little challenge for the player, particularly if the conversation branches all lead eventually to the same end point. Also, as mentioned above, the UNDO or SAVE/RESTORE commands encourage the lawnmower approach, which can lessen player involvement and remove much of any challenge that is present.
These basic systems are not all that fundamentally different than those used in most mainstream graphical games, and within the IF realm they have their advantages and disadvantages. To me, though, there are three main reasons why I think conversation in IF generally works better than in other game genres: skill, creativity, and patience.
As I've suggested before, I think that perhaps it is a consequence of these games being created largely by writers rather than teams of programmers, designers, and artists, and I'm guessing it also has to do with the fact that most IF games are not commercial and lack the associated deadlines and budget constraints. It takes a lot of skill and time to write good conversation that creates depth for characters and their relationships, and even more to write it within a system where it is often pieced together at different points in time based on player actions. That takes a lot of planning, design, and testing. In some cases it demands some creative modification of the conversation system being used, but for the most part good, meaningful, and challenging conversation in games can be created with the tools and systems that are already out there. The more I play different IF games that have well-crafted conversation, the more I have come to realize this, and the more I believe that mainstream, graphical games can learn a lot from these implementations -- if only the developers would have any interest in it, which is to say, if only they thought that players would have any interest in it.
I also think the nature of the medium and the IF community is to encourage experimentation with different types of systems, and the result is that there have been some pretty creative solutions to what is (still) a complicated and mystifying issue. Sometimes that involves systems that combine different elements; Vespers, for instance, combines the TALK system with the ASK/TELL system, while a game like Short's Pytho's Mask combines topic-based conversation with multiple choice dialog trees. But often there is more that is designed under the hood, so to speak, in order to generate conversations that flow smoothly and are consistent with the events of the game regardless of the player's prior actions.
Over time, I'll try to review some of the games that I think do well at implementing conversation, with a focus on the mechanics, but also with a focus on the question of whether conversation systems like these could have a role in the more mainstream, graphical games industry. In the meantime, I'd be interested to hear if there are any mainstream games that people have encountered in the past that they felt utilized an effective conversation system.
February 9, 2008
A Verb Analysis in IF
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.
February 6, 2008
Al Lowe on adventure puzzles...and text?
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.
