Tag: mike snyder

Distress by Mike Snyder [Comp05]

IFDB page: Distress
Final placement: 4th place (of 36) in the 2005 Interactive Fiction Competition

Say you’ve got an idea for a story. It’ll be thrilling, fast-paced, and ingenious. Say, just for illustrative purposes, it’s a story about the survivor of a crashed spaceship, who has to help injured crew members, signal for a rescue, and figure out why the ship crashed in the first place, all while being hunted by a hostile creature on the unexplored planet. You know what all the beats are, and how your protagonist gets from beginning to end by making clever use of nearby resources and surviving tightly timed encounters like chases and medical emergencies. You know there’s going to be a twist at the end, how you’ll foreshadow it, and how it will finally manifest.

Now, you could just go write that story! Who knows if it’d get published anywhere — it’s pretty cliché-heavy — but if you wrote it you’d be able to shape it exactly to how you imagined it. But what if you wanted to make that story into a game? It would seem to fit an IF milieu pretty well, with the protagonist being alone in an unfamiliar landscape, and having to piece together information and objects to get to the best ending. How do you take your story, which is specific and clear in your head, and turn it into an interactive experience that is — and this part is important — fun and enjoyable for players?

Well, this is where things get dangerous. When you make a story interactive, you are now obligated to create sufficient margin around the ideal plotline that players can experience the game’s world and its events without feeling like they’re inside some kind of narrative lab experiment where electric shocks are applied anytime they step off the prescribed path. At one extreme of this continuum, any command that doesn’t adhere to the ideal walkthrough results in a losing ending. At the other end, the player could depart from the story entirely and still be supported by the game to eventually reach a satisfying conclusion.

Guess which end of this continuum is easier to code? Lots of authors fall into the trap of forcing their players to adhere too closely to a specific string of commands, either by failing to implement anything outside of it or by lowering the boom immediately on any deviations. Very few authors create a world so rich that new and different stories can emerge from it autonomously, because doing so is unbelievably difficult. Finding a satisfying middle ground between these extremes is the essence of the IF designer’s craft. That’s why it’s often said that the best IF doesn’t offer unlimited interactivity but rather a very convincing illusion of unlimited interactivity.

So back to our crash survivor story, which, yeah, is the plot of Distress. You might implement this by creating lots of ways for the protagonist to survive, and in some ways, Distress attempts this. However, its flexibility tends to be around more trivial tasks such as what verbs can be used for one step of a first aid process. It has zero flexibility on more important things, like how many turns you have to complete that first aid process, and heads up — if you don’t complete it correctly, you are locked out of a winning ending without knowing it.

Some games might handle a situation like this by providing a generous time limit, and ending the game upon failure to complete the task, which would cue players that this is a puzzle whose outcome is crucial to success. Other games might give you clearer and clearer nudges towards the right solution, and then end the game on a failure, or even outright force a success. Distress, on the other hand, makes it seem like the failure is a valid outcome, and maybe even inevitable, only to silently prevent success even after many more steps are completed.

The author makes a telling comment in the text file accompanying the game: “To some degree, I think we as IF players have grown soft.” This comment suggests a view of interactive fiction in which the players battle the authors for dominance over the experience, and longs for the good old days in which authors would sharpen their knives and players would hope not to bleed too much. That’s one view of this medium. It’s not mine. I play IF because I want to experience a world and a story, and while I enjoy a challenge, I do not enjoy repeated electric shocks.

So it was with Distress, whose name seemed more and more apt the longer I played it. The writing is good, the coding is strong, and the premise is solid, and I found it fun and compelling at first, but it quickly became apparent that there was many an electric shock to be had. I lost over and over and over again. Finally I turned to the hints, and despite following their cues, even the one that “solved the puzzle”, I still lost. Then I turned to the walkthrough, and lost. Then I started over, adhered closely to the walkthrough, and finally got past the point that had been battering me. Was I having fun? Reader, I was not.

Distress set out to punish me for my deviations from its ideal route, and it certainly succeeded, but repeated punishment is not my idea of a good time. Even valid ideas for how to solve a puzzle, even ideas that actually are the solution to that puzzle, aren’t allowed unless you carefully shepherd the PC’s mindset through them. So, for example, there might be a battery to be found right next to you, but you’re not allowed to find it until you demonstrate to the PC that a battery is needed. To make matters worse, the many tightly timed sequences pretty much guarantee you’ll be replaying parts of the game many times, so while you learned about the battery problem 10 playthroughs ago, you still have to pretend it’s your first time.

Distress may well appeal to a certain kind of player, one who agrees that we’ve all gotten too soft. It wasn’t for me.

Rating: 6.8

Trading Punches by Mike Snyder as Sidney Merk [Comp04]

IFDB page: Trading Punches
Final placement: 10th place (of 36) in the 2004 Interactive Fiction Competition

Trading Punches is a lovely piece of work, with a good story and a fine design. It’s also got some flaws, so let me tackle those first, and then I’ll move on to the loveliness. The first problem I had with the game may be more just an idiosyncratic reaction: I found much of its prose rough going. It’s not that the writing was error-laden or terribly awkward — it’s just that I kept finding myself wanting to skim over it, and having to concentrate to actually read it. The problem was most severe in long room descriptions and infodumps, of which the game has many. I’m not sure whether the prose was just too dense for me, or whether it was some question of style, or what. I know that’s an unhelpful reaction, but it was my reaction nonetheless.

One definite problem with the style is that the game goes way overboard on a particular gimmick for making things sound SFnal: word-mating. Thus, the PC wanders around a landscape of “mossgrass” and “elmpines”, watching the “peacrows” and then later drinking some “brandyrum” and “whiskeygin”. Yeesh! A little of this strategy goes a long way, and Trading Punches had way more than a little; it sounded pretty silly in short order. Finally, though the game was obviously tested, a few significant bugs made it into this version. For one thing, certain commands, like “score”, draw no response at all from the game. Even more seriously, there’s a class of locations with one exit that consistently thrusts the player into a formless void from which there is no escape. At first, I thought this effect might be intentional, but further experimentation demonstrated that it’s almost certainly accidental.

So yes, Trading Punches has some problems, but I still ended my play session feeling very happy with it. Why? Well, for starters, I enjoyed the story quite a bit, and aside from the excessive word-mating, the setting felt nicely realized as well. In general, the plot and the game-world felt reminiscent of the work of Orson Scott Card, which I like very much. I don’t know if the author of Trading Punches is familiar with Card, but I wouldn’t be at all surprised to discover that influence on this game. It’s got plenty of Card’s hallmarks: bitter rivalry within a family, affecting the larger world and universe on a grand scale; a gifted protagonist with a strong moral center who has a significant impact by helping (or trying to help) others; and strong familial bonds offsetting the deep familial schisms elsewhere.

The aliens in the game feel original and well-imagined, and lend themselves to symbolic use as well. I also appreciated the design of the game — its central story of sibling rivalry is told through chapters that don’t hammer the point too hard, but still make it quite clear how the enmity grows between the two brothers. By skipping forward in time to the most important incidents in their relationship, the game develops the character of both the PC and his brother quite satisfyingly. Situating the chapters within a frame story works very well to knit the disparate pieces, and the game does an excellent job of weaving revelations about the frame story into the content of the chapters and vice versa. Unfortunately, two hours wasn’t quite enough time for me to get through it, partly because of my denseness around one of the puzzles. However, a glance at the walkthrough shows that I was most of the way through, and I felt regret at having to stop the game and write this review, which is clear evidence that the story had me hooked.

Even aside from the story and the design (and its bugs and prose tics notwithstanding), Trading Punches boasts an impressive amount of craft. Especially noteworthy are the game’s cool multimedia components. Each chapter (and each return to the frame story) begins with a full-screen graphic. These graphics are quite lovely, and do an excellent job of establishing the landscape. I found this especially helpful as I struggled with the dense prose’s attempts at scene-setting. The illustrations look as though they were created in some kind of graphics rendering software, and consequently have a bit of a Myst-like feel to them, which is a good thing.

Also effective is the game’s music, a synthesized soundtrack which loops constantly in the background. The music is generally quite effective at enhancing the mood of a particular scene, though some of the musical pieces don’t have enough melody or complexity to withstand the constant looping. No matter how good an eight-bar tune is, it’s bound to get a little grating on the hundredth repetition. The game itself is quite solid, too — it’s clear that a whole lot of effort went into this project. Aside from the few bugs I mentioned in the first paragraph, I found the code pleasantly error-free, and the same goes for the writing. The puzzles worked well for me, and the game did an excellent job of providing cues to help me know what I ought to try next. One item in particular was not only quite well-implemented, but also provided an excellent emotional through-line for the story.

Trading Punches still has a few details to clean up, and the word-mating has to go, but I’d recommend it without hesitation, especially to fans of dramatic fantasy games like Worlds Apart.

Rating: 9.2

Lunatix: The Insanity Circle by Mike Snyder [Comp99]

IFDB page: Lunatix – The Insanity Circle
Final placement: 12th place (of 37) in the 1999 Interactive Fiction Competition

Early on in Lunatix, I typed “X TUKE.” The game responded, “It looks just like you might have expected.” Of course, there’s no “tuke” in the game — I meant to type “tile” but my right hand had strayed a bit from its accustomed spot on the keyboard. I’m glad it happened, though, because the incident taught me something important about Lunatix: its parser pretends to understand more than it does. In my book, this is a big no-no. In fact, if I ever write a Parser Manifesto, my first principle will be, “Parsers must not pretend to understand more than they do.” Even a fairly innocuous violation of this rule, Inform’s famous “You can’t see any such thing,” has caused no end of debate on raif. When a game pretends to understand more than it does, you can never really be sure when you’re encountering a bug, because bugginess has been built directly into the interface.

What’s more, it’s a cop-out. Instead of doing the often tedious work of creating descriptions for the available objects, the game elides the absence of these descriptions by acting like it recognizes them when it doesn’t. As a player, I find this pallid deception infuriating. Unfortunately, Lunatix‘s parser does something even more infuriating, which has led to the formation of the second principle in my hypothetical Parser Manifesto: “Parsers must not give smarmy, unhelpful error messages.” My encounter with Lunatix was filled with exchanges like this (the words after the ellipses are my input):

...FILL WATER GUN
Your logic, although interesting, is flawed.
...TURN ON FAUCET
That's a pretty crazy idea, but it didn't work.

These kinds of responses make me want to scream obscenities at the game, and sometimes I did, along with feeble protests like “No it isn’t! Wanting to fill a water gun with water is not flawed logic! Turning on a faucet isn’t a crazy idea!” Then I remembered that talking to yourself is a sign of impending mental collapse, so I stopped. But my blood pressure stayed high.

The problem with this kind of message is that the game is willfully occluding its own shortcomings at the player’s expense. Error messages that insult the player, when in fact it is the parser that has failed, piss me off. I’d so much rather see the game say “I don’t know that verb” or “You can’t fill that” — that way I know exactly what hasn’t been implemented, and that knowledge will be useful to me throughout the game. Instead, Lunatix sneers at me and acts like its flaws are my fault.

Which brings me to the third principle of my Parser Manifesto: “Parsers must not ask questions without being prepared to receive an answer.” I had lots of exchanges with the game that went like this:

...POUR CPU
What are you trying to pour out?
...CUP
In a perfect world, that might have worked.
...POUR CUP
You empty the cup's contents onto the floor.

OK, so I made a typo in my first command, and the game asked me a disambiguating question. Fair enough. But wait! Further evidence reveals that the question only appeared to be for disambiguation. Actually, the parser wasn’t asking me a question at all, but giving me a message along the lines of “I only understood you as far as wanting to pour.” By phrasing that message as a question, Lunatix tricks me into thinking it is following the standard set by every other major parser: ask the player a question and process the answer. Instead, it’s only prepared to follow through with the first half of that standard, and gives me a snippy error message in the bargain. Grrr.

These kinds of problems have been more or less eliminated in the default library parsers used by most major IF tools, but Lunatix doesn’t use one of those parsers. Instead, it is a “homebrewed” creation written in (from what I can glean from the readme) QBasic, and presenting a radically different interface than most IF games do. The game splits the screen into four windows: the top half of the screen is split vertically between a square graphics window (displaying a picture of the current room) and a square text window, which always displays the textual description of the current room. Taking up most of the bottom half of the screen is a rectangular text window, which displays the game’s responses to the player’s input. Below that, a frame around a one line text field, is a window for the player’s input. It’s a bit reminiscent of the Legend interface, except instead of a compass rose and clickable command menus, there’s just a room description next to the graphic.

The graphics themselves are grainy and pixellated (or at least, they were on the two monitors I used to play the game), but still manage to be appropriately atmospheric at times, and even rather attractive once in a while. More importantly, they add significant content to the game — there are some objects that would be difficult to envision when described in text, but the presence of the graphic clarifies the setting a great deal. The window with the textual room description was nice, too, as it allowed systematic examination of the first-level nouns without having to periodically “LOOK” to remember what those nouns are. Of course, the game doesn’t actually implement most of these nouns, but that’s not the window’s fault.

The only difficulty I had with this window is that it didn’t always automatically update when something drastic had changed about the room, unless I explicitly typed “L” again. Thus, after solving a puzzle I might see a picture of a normal hallway, while the description alongside it raved about the giant squid blocking my path. In addition, lots of keen features were implemented in the interface, like command recall with the up-arrow, splash screens at the beginning and end of the game, a weirdly pulsating cursor, and nifty sound effects. So I can say with certainty that Lunatix is the most technically competent homebrewed game in the competition, perhaps even the most technically competent homebrewed game in the history of the competition. Unfortunately, all the snazzy windowing and gee-whiz effects in the world don’t really make up for its substandard parser.

The other part of the game’s core, its story, is OK. It’s one of those IF scenarios whose premise rationalizes why it is full of patently ridiculous things. In this case, you’re the unscrupulous director of an insane asylum and you’ve been given a drug which replicates insanity. This is a cozy explanation for why nothing you see really makes any sense, and seems to be just a setup for lots of different code and one-use-object puzzles. These puzzles are mostly OK, too. They’re more or less logical (within the confines of the completely nonsensical story) and, with one or two exceptions, pitched at the right level of difficulty. There is one real howler towards the end which makes almost no sense but will be deeply appreciated by fans of The Penguin on the old Adam West Batman show.

So in other words, the story and puzzles aren’t great, but they aren’t terrible either. Unfortunately, the combination of fair-to-middling plot with really-irritating parser makes the game less fun to play than it should be. See, (he said, mounting his soapbox) an IF game is a fusion of parser and story. The beauty of the modern IF languages is that they have freed designers from most of the hassle of worrying about the parser, allowing them to focus the bulk of their creative energy on the story. When a game eschews these time-tested solutions, it doesn’t just double its work, but increases it exponentially. Lunatix, strong as it is, isn’t quite up to the task.

Rating: 7.1