     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Most of the puzzles in the game are related to the attributes of the objects you come across (openable? breakable? edible?) and this allows for multiple solutions and a greater feeling of immersion -- I expect you never "scripted" that particular moment. Smart objects that have their own built-in physics are also what make games like Half-Life 2 great, and really are less of a technological advance and more of a object oriented programming approach. When did you start to implement this approach and what impact does it have on your game making? ES: I've been interested in this approach since I first started writing IF. One of my earliest games (Metamorphoses) is even more systematically about object properties than Savoir-Faire. I enjoy writing the kind of game where the player becomes increasingly skilled at applying the rules of the game-world, rather than facing off against a bunch of unrelated single puzzles; it's easier to do that if you start with a consistent world model that supports most of your puzzle interactions. Having such a world model in place tends to provide a bunch of "toy" functionality as well -- fun secondary effects that the player can fiddle with when he's bored or not making progress. GS: What kind of editing/playtesting process do you have and how does it differ from your IF making peers? ES: Usually I draft the world model and the opening scenes -- enough to demonstrate the kind of interaction that's going to make the game work. For Savoir-Faire, for instance, that meant building the magic system, then implementing a few puzzles and enough rooms to give a sense of the setting. Then I show the prototype to someone. Occasionally my alpha-tester finds the premise unpromising, so it gets scrapped. More often, we decide that I'm going to need to add features to improve the player's experience -- things like a recap verb for a conversation-heavy game, to let the player review what's already been said without taking notes. It's much easier to write such features into the game from the beginning than it is to patch them in later in response to beta feedback. After we've vetted the prototype, I design a structure for the rest
of the game and implement it. As I write, I play through it myself a
lot. I try to forget what I've implemented and just type what comes
naturally to me as a player; I turn up a lot of under-implemented
bits that way. I also do most of my prose editing as I play. This is When I have the game to where it can be finished, I start beta-testing. I have worked with a number of beta-testers, and I pick a crew to work on a new project depending on their skills and interests; some are more interested in testing puzzle games than others. And I try for a balance of people who will approach the game as players (trying to experience what any other player would experience) and people who will approach it as testers (deliberately pushing the boundaries of the system). The second group identify more bugs, but the first group give the best feedback on structural and thematic issues. I encourage all my testers to send me their transcripts of play as well as comments, and I often follow up with some live conversation about how best to resolve flaws in the game-play. This is similar to the process most IF authors use, with maybe a couple of exceptions. I'm not sure everyone does an alpha-test before committing to write a full game; picking an alpha-tester is harder than picking a beta-tester. You want someone who is perceptive and articulate about game design and who has enough IF experience to spot cliches and stumbling blocks; someone who will be tactful, but honest enough to advise you against finishing the project if they think it's not worth following through on. This is hugely valuable and not easy to find. I also make heavier use of automated testing these days. The
traditional attitude is that you should get a bunch of beta-testers
to hammer on your game until it seems to be in good shape, then
release it. You might keep one script around to play through your GS: Speaking of your peers, does the interactive fiction community influence your game making? ES: Yes, hugely. I draw a lot of inspiration from other people's work and from the feedback I receive on my games. GS: How does this online community differ from any other communities you might participate in? ES: It's small, for one thing. Most of the other online communities I belong to are considerably larger. There are good and bad effects from that: each active participant has a big effect on your experience of the group and relationships tend to be more charged. I have closer friends in the IF community than in any other online community; I've also run into more personal frictions here. On the whole, though, the balance comes out positive. The other point is that IF tends to attract people with broad intellectual interests. To be a good IF author, you have to be part writer and part programmer, and that makes for an interesting group. |
|||||||||||||||
Previous
|
|
|