Playing Phantom of the Arcade within the context of a web page has me thinking about the new things we could be doing with interactive fiction that simply weren’t possible in the heyday of text adventures.
IF is an interesting game type. They player isn’t just working to complete the story, but to experiment with the gameworld and read what the author has to say. Being stuck in IF can be just as rewarding as moving forward, provided the game has interesting things to say about it.
> use fork on light socket
I beg your pardon?
Isn’t very fun. You type in something crazy and the parser just shrugs. On the other hand:
> use fork on light socket
The electricity in this house is functioning much better than your common sense. Ergo, you have been shocked.
This might squeeze a smile out of the player. Even if it doesn’t, there is satisfaction in seeing the gameworld react to your input. You connect with the author over this mutually understood action. Feedback itself is a reward.
The challenge for the author is to fill the world up with entertaining feedback. Trying to write a response for every conceivable player action is a task that scales poorly. That’s simply too much to write, and a vast majority of them will never be seen. What the author needs is to be able to anticipate likely courses of action – correct or not – and compose responses for them.
I’ve always said that you can’t beat people in aggregate, no matter how smart you are. Anyone who has ever run a tabletop roleplaying game can tell you how impossible it is to anticipate player actions, even when there are only four of them and they’re all your friends. Anticipating the actions of thousands of strangers is an impossible task. Those people will try things that never occurred to you and will come up with (sometimes legitimate) solutions to problems you didn’t envision. Every “I beg your pardon” and “you can’t do what” on the part of the parser is a tiny failure on the part of the writer as he or she tries to outwit thousands of readers.
But for games that run over the web there is the ability for the author to adapt their story in response to failed player input. What I would like to see is a system which gathers up failed actions (sorted by room) for the writer to review, sorted by frequency. So the designer can review this list and see that n number of people tried to use the glazed ham with the woodburner stove instead of using it to distract the rabid wiener dog. The author can either let the player cook the ham (which would not diminish its usefulness against the dog) or offer up some sort of reasonable response as to why they can’t or shouldn’t cook the ham, or at the very least add some text so that the game can say “no” instead of “huh?”
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.
Makes me want to write one of my own.
UPDATE: Speaking of writing IF, Mike Rubin has a response to this over at Monk’s Brew, which is interesting because he’s working on a rather ambitious IF title himself.
A Telltale Autopsy
What lessons can we learn from the abrupt demise of this once-impressive games studio?
Internet News is All Wrong
Why is internet news so bad, why do people prefer celebrity fluff, and how could it be made better?
Philosophy of Moderation
The comments on most sites are a sewer of hate, because we're moderating with the wrong goals in mind.
Let's ruin everyone's fun by listing all the ways in which zombies can't work, couldn't happen, and don't make sense.
Here is a 13 part series where I talk about programming games, programming languages, and programming problems.