|
|
|
March 30th, 2010
08:15 pm - Busman's holiday
Update: non-LJ person asked if I have an RSS feed. Looks like I do, at huskyscotsman.livejournal.com/data/rss (or /atom)
Just got back from PAX East, a big gaming con in Boston. I didn't actually get too involved with the core videogaming stuff, and instead spent most of my time hanging around with folks from the Interactive Fiction community—we had a couple of discussion panels at PAX, and a few more sessions outside PAX in an informal IF Summit. We got a really energetic mix of fans, hobbyists, academics, historians, central figures from the glory days of commercial IF in the 80s, and even Don Woods who co-created the entire medium. Many old friends I hadn't seen in years, many people I'd heard of but never met, many people I'd never heard of but hope to meet again. Definitely the most interesting bunch of people I've ever seen gathered in a single room.
Some of you may be thinking "what's interactive fiction?" For me, IF is anything that's at the crossover point of games and literature: there's a story of some kind, but the reader is an active participant and has to help unfold it. The traditional form this takes is a text adventure, like the original Colossal Cave, or the commercial hit Zork that it inspired. The game tells you where you are, and you type "GO NORTH" or "GET LAMP". People are making free text adventures today that are better than anything you could buy back in the old days. And there are plenty of other forms: hypertext novels, say, or fancy console games that try to be interactive movies.
Anyway, there were a whole bunch of ideas and opinions being kicked around at the summit, and I'm going to forget them all if I don't write any down. So here's an incomplete list of stuff that piqued my interest.
The notion of logging player input came up in the adaptive hints session. This has been discussed on and off for a while, and it's clear that we really badly need tools to make it happen. Testing is super important for IF; quality is better than quantity, but both are good, so whenever anyone plays your game, it should log a transcript so that you (the author) get useful feedback. This is the kind of data-driven development we do all the time at Google, and it works amazingly well, so I want to help bring some of that magic over to the IF hobbyist community somehow. But there are a couple of tricky technical ramifications.
First, the game probably has to be hosted in the cloud. It doesn't necessarily have to run on a server rather than a client—the client could just run the game locally and send each command back—but doing everything server-side is the logical conclusion. (Quietly glossing over offline play for current purposes.) Most people are unable or unwilling to spend the time and effort to host stuff themselves, so there needs to be a super easy turnkey solution to cloud-based IF hosting.
Second, how do you rapidly modify the game while people are playing it? In current IF systems, save files are not portable between game versions, because the state is arbitrarily complex and porting it over when the game code changes is totally infeasible. I guess if you're doing an official beta-testing thing, you just tell your testers that a new version is rolling out and they need to start from scratch. But I'm really excited about the idea of blurring the boundaries of testing and releasing, and just having the players ferret out the bugs; in which case the versioning problem would have to be solved. (Though it could be solved indirectly—for example, by a game design that doesn't actually need save files as such.) Oh, and there are privacy issues if you have logging enabled by default—there probably needs to be an opt-out policy. (In principle opt-in is better, but all the panel authors agreed that most players never read the damned instructions, and in fact overlook all but the most blatant UI prompts; hence very few people would opt in.)
So: we need tools! We need people to write tools! I don't want to take on a big project like that myself, but I'd love to collaborate on something in this area with other techie people. I'm thinking Google App Engine, but I could probably be swayed in favour of some other platform. If you're interested, give me a shout.
That kind of logging setup is a special case of the more general concept of crowdsourcing: getting a whole bunch of people to each do a tiny bit of work for you. That can give good results in both quantity and quality: the total effort spent can be large, and you can sometimes get cool ideas that no single person would be likely to come up with on their own.
Testing is a natural fit for crowdsourcing because it's highly parallelisable; and you can still have a single author or at most two collaborators processing all the feedback and imposing their vision on the game. I wouldn't have thought that crowdsourcing the game design or writing itself would work as well: there's a reason why "design by committee" is pejorative. But apparently (what I think of as) Emily's game Alabaster was written by a crowd almost accidentally. She put some unfinished stuff out for discussion, and some people sent her a bunch of completely new material to add to it. She pulled it all together and somehow made everything fit. Most players seem to think it's a great game and even feels cohesive, though Emily says she can totally see the seams. Must give it a try!
That train of thought leads me to open source development practices. I went to Ben Collins-Sussman's talk at Google Boston where he gave a potted history of IF; talking to him afterwards, I was hugely impressed at the way he's bringing a modern open source mentality into the community. Most of our tools are still maintained by individual people and in many cases don't even use source control. Ben uses Google Code not only for his tools (his Android z-code interpreter, Twisty), but his games too. He uses standard bug-tracking tools for reporting problems and his progress in fixing them. He and Jack Welch have formed a really efficient coding and writing partnership, and are cranking out award-winning games at a terrific rate; and everything they do is totally open to the community, reusable under a Creative Commons licence. That's awesome, and more IF people need to operate like that. My contribution over the years has mainly been in the form of tools and interpreters of various kinds, and failing to properly open-source them has been my biggest mistake. Our traditional "auteur" approach to tools is okay if you're willing to put in a huge amount of effort indefinitely, like Zarf and Graham, but very few people are Zarf or Graham.
Okay, that's enough about tools and methodologies; let's talk about actual game design. That session on adaptive hints was pretty good. I took a few key points from it that I'm not sure were crisply captured in the ensuing discussion. There are two main approaches: multiple difficulty settings for the whole game (as in Aaron Reed's text game Blue Lacuna), and multiple levels of hinting per puzzle (Dave Gilbert's graphical games—I forget all the names, sorry). These aren't necessarily exclusive; you could do both.
Blue Lacuna has a short introduction where the game tries to gauge your skill level, before offering you a choice of difficulty levels. I think this is a great idea, not for the game's benefit, but so that the player gets a feel of what the different skill levels might involve. If I'm offered "easy", "medium" and "hard", how easy is "easy"? If given that choice right away, I have no idea, but if I've played five minutes of the game and it can give me some feedback on my performance, I can make a reasonably informed decision. A natural corollary is that I should be able to change my decision later on if the game turns out to be harder or easier than I expected; but that places some extremely tough constraints on your design: not only do you have to create several different versions of each puzzle, but you also have to figure out how to switch between them at almost any point. For Blue Lacuna, Aaron basically wrote two complete, separate games. I don't think that approach scales very well: insufficient bang for the buck.
Dave Gilbert talked about trying to make the hints good enough that people wouldn't be tempted to Google for the solutions. I think the key thing here is the "Pringles can" effect, as Stephen Granade put it: it's not the first Googled hint that's the problem, it's that once you start, you can't stop. It occurs to me that extremely non-linear and/or randomised game design might be helpful here, because it means the solution to the next puzzle won't be temptingly sitting right next to the one you just looked up. That little bit of extra effort needed to search the walkthrough for the relevant section may make some people stop after just one hint and get back to playing the game properly.
If you want to keep people away from Google, your in-game hints need to be great, which places heavy demands on the hobbyist writers. And you still need to solve the Pringles can problem! Somebody mentioned a game that forces you to play a simple shoot-em-up minigame in order to unlock hints; that little bit of effort makes the hints less "moreish". This particular person hated that minigame; this eventually drove her back to the puzzle she'd been stuck on, but she found that the break had somehow given her the inspiration she needed to solve it herself. A success story!
More interestingly to me, challenge-response as a game mechanic came up a couple of times in the same session. We were discussing different ways in which the game can encourage new players to read the instructions without forcing them down the throats of experienced players. Aaron Reed made the witty suggestion that the game should first ask "have you played this game before?"; then if you type "YES", it should follow up with: "Prove it! Which two NPCs have a conversation in the ballroom after midnight?" (I call this "challenge-response" because it reminds me of authentication systems where you're challenged to prove that you know the private key without having to reveal the key itself; although reading that Wikipedia page, zero-knowledge password proof is probably a better term to use.) Later, Dave Gilbert was discussing the problem of player versus character knowledge, giving the example of a game of his where facts were stored in your inventory, and you had to explicitly link them together to have the PC draw inferences. He found that many players got frustrated because they'd gathered all the appropriate facts, but didn't grasp that they needed to tell the PC by linking them together. I suggested that at the key point where the inference is needed, the game could just challenge you by saying "how do you know that? link the facts!" and opening your inventory automatically.
This all feels related to something I've been bending people's ears about for a while in the context of the Phoenix Wright games for the DS. The core mechanism of that series occurs in the courtroom scenes, where a series of witnesses make statements and you have to prove that they're lying or mistaken. To do this, you point out the key fact in the Court Record (i.e., your inventory) that contradicts a particular sentence. You can brute-force it if you really want to, but it's easier and more fun to just figure out the trick, at which point the relevant item is (usually) obvious. This is a really simple interface: the game doesn't try to do any tricky parsing, and you don't actually need to explain the trick to the "parser" at all; you just need to prove you know it by choosing the correct item and sentence out of 50 or 100 or so combinations. This would also be true if you had a combination lock puzzle based on some fancy mathematical series, say, but that's abstract, and from a storytelling point of view pretty boring. The genius of Phoenix Wright is that it's totally concrete: the puzzles can involve any kind of real-world physics or byzantine human motivations, because the challenge-response UI places very few limits on what can be expressed. For example, consider a puzzle like "Bob didn't know he was looking at Sally in a red cloak rather than Carol in a green cloak, because he's colour-blind, and that's why he thought Sally was the murderer". In Phoenix Wright, you just click on the cloak or the optometrist's report at the appropriate point in Bob's testimony. How on earth would you model that in traditional command-line IF? Or in a first-person graphical game? I guess you'd have to construct a scene where you can somehow use your knowledge of Bob's colour-blindness to good effect. That's a tough challenge!
This sort of "existence proof" puzzle can be done in a traditional text adventure, and in fact I think it's one of the most satisfying kinds of puzzle. I just now remembered my review of an old detective noir called Dangerous Curves, where I raved about exactly this concept. That game presents you with a bunch of clues, and you have to draw the correct inferences and follow the correct hunches in order to turn up at the right place at the right time: in principle you could stumble there accidentally, or brute-force it, but the game challenges you to prove you can read between the lines by taking the correct short-cuts. Phoenix Wright's courtroom UI is just the purest and simplest game mechanic I know of for conveying this style of puzzle. (Interestingly, the latest game in the series is a third-person point-and-click adventure with a similar "fact linking" mechanic to the one Dave Gilbert mentioned using. Haven't played it yet but I definitely plan to do so soon.)
Another thing that came up a couple of times was acknowledging the significance of player-created events. In an open discussion about the future of IF, Don Woods suggested that we might want to let players point out to the game what people and objects they want to remember for later reference. This led to some funny anecdotes from Emily about Fable II, where the emotional notes the game was trying to hit fell flat, but sometimes insignificant random encounters would be emotionally affecting; it'd be good if you could somehow tell the game when you thought something important had happened. Later at the pub, people were talking about Bioshock and Fallout, where it sounds like this kind of thing happens a lot. Procedural generation of graphics and of plot elements is very powerful; player-created content is very powerful; how can they best be exploited?
Replayability was another hot topic. Several panelists advocated short games with multiple "winning" endings: the replay value is in exploring the space of possibilities and deciding which endings you think are "better" and/or more satisfying. (I use scare quotes because this allows the author to explore morally ambiguous stories, where there is no correct answer that works out best for all the characters.) As the length of a single run gets shorter and shorter, it's increasingly likely that a walkthrough would list multiple solutions, and in many cases a "complete playthrough" would always consist of multiple runs, even if most players don't explore the game exhaustively.
How about longer games? Here I think there are forces pulling game designers in opposite directions: non-linear is good in terms of "hint moreishness", replayability, and just plain interactivity. But linear games have much simpler state spaces, which make it easier to provide adaptive hints and to port save files between versions; and if a game is totally linear, the author could provide shortcuts to jump directly to any chapter, which I think would hugely increase the replayability of interesting-but-tedious games like Heavy Rain. Very short, highly non-linear games with multiple endings cut the Gordian knot and allow you to do all these things at the same time, so for an author who wants to write something new and cool that seems like the smart choice. But from a player's perspective, epic sprawling games are often lots of fun, so it would be a shame if nobody wrote any. There are plenty of totally linear games that I like just fine, so maybe linearity isn't so bad! Or just go with a compromise, like a linear sequence of chapters with plenty of interactivity and choice within chapters. Throw in some sidequests, and you've got the standard structure of a big commercial game. Are there cooler-but-still-feasible structures for long games?
That's about all I can remember for now. (And I didn't even go to all the panels!)
Of course all this is just theory, with little intrinsic value until somebody actually tries it out in a game. Several people I've spoken to said they're now inspired to dig out their old projects again, or to start something new, although they're cautiously cynical about how long the enthusiasm will stick with them. And yeah, I'm kicking some stuff around in my head too. What I really ought to do is sit down and do something small and simple in Inform 7, although that's not necessarily where these ideas are leading me... We'll see.
We're living in good times.
|
Thank you for these extensive notes! Very useful, especially since they cover a panel I wasn't able to attend. This is just my personal spin on it, of course. Other people may have gotten entirely different things from the same panels. | From: | (Anonymous) |
|---|
| Date: | April 3rd, 2010 05:12 pm (UTC) |
|---|
| | great write-up | (Link) |
|
Great thoughts, Iain. One point of clarification: Blue Lacuna's story/puzzle mode choice didn't really involve *writing* two different games-- choosing story mode basically just removes about 30 items from play which block access to content or make things more difficult-- but it did involve *testing* two different games, which was a massive nightmare and challenge and headache. Which ties in to your comments about save games being incompatible across recompiles. This is an issue that frustrated me (and, I'm sure, other authors working on large games) a lot during development, although I'm pretty sure there's not any sort of easy solution.
Something else that occurred to me regarding capturing new player input: has anyone ever done any sort of user study to determine whether the types of actions new IF players try to perform matches up with the default set of actions provided? We've evolved a set of standard actions, but I'm not necessarily convinced these correspond with the sorts of actions that new players want to take. Aaron, that you?
Thanks for clarifying, that makes a lot of sense. I don't think that testing load can be reduced unless the optional puzzles are completely isolated from the rest of the game, so they can each be tested in isolation. But in that case they probably wouldn't be very good puzzles.
I haven't heard of any such study of player input. It'd be interesting to look at videos of things like Action Castle and Purple Blurb, and transcribe the things that people are saying (or shouting out in the background).
Edited at 2010-04-04 11:01 pm (UTC) |
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=91.7){kind=small}
huskyscotsman's journal
