Traffic

Adapted from an IFCOMP24 Review

A parser-driven, time loop scenario of interconnected cause and effect to untangle? Yes, please! One whose puzzles are both intuitive, yet lateral-thinking heavy? YES, PLEASE. One that minimizes hand holding and segues from pure puzzle play to underplayed but engaging dramatic beats? YES PLEASE AND THANK YOU, GIMME GIMME GIMME.

This game may represent the quickest ramp from my neutral, “Well, what have we here, Comp entry N+1?” that I start every game with, to “HELLZ yah, this is my jam!” You are quickly introduced to the looping gameplay core, with almost no guideposts to follow. I found this game, for a while, to be just about perfect at leveraging tight scenario descriptions and implicit parser assumptions to strike the wonderful balance between ‘what the hell do I do next?’ and ‘wait, this wild thing I tried actually has a response!’ It is a deep implementation that centers player initiative and for while continues rewarding and rewarding and rewarding it. The mechanism of looping itself is a wonderful ‘wot the hell?’ → ‘oh, I see what you’re doing!’ discovery.

It does seem though, like either that initial impression is not as precisely engineered as it feels, or that time ran out on implementation. At some point we segue from a gleaming clockwork of balanced expectations and rewards to what feels very placeholder-implementation-y. I have no insight to this author’s development process, but it feels like things were attacked in this order:

1. Overarching conceit, mechanisms and plot skeleton conceived, turned into outline
2. Detailed individual puzzle design, step by step through outline
3. Strawman mechanical implementation of entire work
4. Sequential text refinement, including cluing and mood/deduction balancing
5. Profit!

It further feels like this work only got halfway through step 4. Specifically, whereas early puzzles were masterpieces of player information balance, leaving us tantalizingly on the razor’s edge of deduction and head scratching, later puzzles were missing key pieces of info and expectations that made it unplayable without walkthrough.

There is one puzzle that requires NPC mood management, with no feedback on their mood making it impossible to detect, never mind gauge. Another requires you to examine something that is never remarked upon in text (at least text presented in my run through). (Spoiler - click to show)a cab, that unless you read the walkthrough are hearing about for the first time from me. Yet another requires clear spatial information to solve that is woefully under conveyed. Still another requires a bespoke verb that nowhere in the text is it hinted might be needed and/or interesting. The only way past ALL these is via the walkthrough. Which itself was sometimes deceptive, as if referring to an N-1 implementation and not the final release. (Still close enough to close the deal, but certainly leeching a lot of good will in the process.) All of these stand in stark contrast to early puzzles that hummed by comparison. Not helping matters, after some resignation and trying to follow the walkthrough, it appears I entered an unwinnable, endless loop and needed to restart. Though given I didn’t follow the walkthrough from the start, possible there was some state issue the walkthrough did not anticipate.

If I had to grade each of those above development steps, which, I’m not your teacher but why not? I would grade 1-B+; 2-A+++; 3-B; 4-D. The puzzle and scenario design just felt top notch to me, flush with promise of a truly engaging game. It just felt let down by final polish where later puzzles were noticeably clunkier to work than the early ones, and purely for reasons of player communication, not inherent design. You know what solves that though? More Polish!

Unfortunately, that late downgrade in polish really undid a lot of the early work’s promise. If I may borrow a conceit from my Spring Thing reviews…
Gimme the Wheel - what I would do next if it were my project: I would attack the last half and double and triple revise the text to produce the same level of finesse as the first half of the game. The bones here are as good as I’ve seen, and the first half SHOWS how capably things could be balanced. Traffic 2.0 could be something special.

Played: 9/10/24
Playtime: 1.25hr; incarcerated, looped, restarted following walkthrough
Artistic/Technical ratings: Sparks of Joy->Mechanical/Notably Intrusive puzzle cluing
Would Play Again?: No, experience feels complete

Artistic scale: Bouncy, Mechanical, Sparks of Joy, Engaging, Transcendent
Technical scale: Unplayable, Intrusive, Notable (Bugginess), Mostly Seamless, Seamless

Fittingly for a game that’s structured as a series of repeating time loops, I am getting déjà vu writing this review, because I’m sadly going to have to start and end with a point I’ve made many many times before: if you are planning on putting a game in the Comp, especially if it’s a parser game, especially especially if it’s a puzzley parser game, and especially especially especially if it’s a puzzley parser game relying on a bunch of nonstandard commands and mechanics, you need beta testers to put the thing through its paces. Traffic has some clever ideas and an engaging premise, but as it currently exists I think the only options for experiencing it are “type in the walkthrough” and “tear out a tuft of your own hair every five minutes for two hours, at which point you’ll probably be irrevocably stuck maybe halfway through.” I’d definitely recommend the first experience over the latter – even for those of my readers who are fortunate enough not to be dealing with the incipience of male-pattern baldness – but even better would be playing a hoped-for post-Comp release that improves the clueing and implementation so that its clear potential can be realized.

Part of that potential is the comedy of the setup. Much like Turn Right, this is a game about getting across an intersection; unlike Turn Right, this time you’re a pedestrian (yay), and the risk of being run over is very high (eek – the blurb should probably have a content warning for this), but you’re carrying a weird science gizmo that allows you to rewind the clock and hop into other people’s bodies (er?). With a little experimentation, you learn that by looking at particular people in the short time available to you before you get pasted, you can queue up targets for your Quantum-Leap-y ability, at which point you’ve got a short window to try to change things so as to avoid the accident – prevent the phone-addicted parent from pushing her baby stroller into the road, reset the wonky traffic-light controller system, deescalate a passenger’s mental health crisis that will lead to the bus getting stranded in the middle of the intersection. If you fail, no big deal, you can always try again, albeit at the cost of another bone-crunching death to reset the timeline.

I love this premise; it’s a clever way of making a puzzle of, and lightly skewering, the absurdities of everyday life, while getting around the artificiality of letting the player have infinite time to prevent a traffic accident that clearly has to happen within a few seconds. And making the protagonist be a sad-sack postdoc just adds to the comedy, while the drily understated prose gives the slapstick room to breathe. Unfortunately, to switch transportation metaphors, things quickly go off the rails.

There are two main issues I experienced that undermined the puzzles – and this is an entirely puzzle-focused work. First, you’ve got your implementation challenges. There were many times when I knew what I had to do, but struggled to communicate this knowledge to the parser. Take the bus scenario: to prevent the old lady from melting down, obviously you’d want to let her take your seat rather than being forced to stand. But STAND doesn’t work (someone else takes the seat out from under you), and ASK/TELL WOMAN ABOUT SEAT just gets a generic response indicating the conversational topic isn’t recognized. I had to go to the walkthrough to learn that I had to GIVE SEAT TO WOMAN, which I suppose is idiomatically reasonable but wouldn’t be intuitive to anyone familiar with parser IF conventions; really, if the player types any of these things it’s clear they’ve solved the puzzle and they should be accepted.

Then there are the puzzles that aren’t sufficiently clued. Some of these might just be places where I was being thick: there’s a math puzzle that I feel like might be underdetermined, such that answers other than the one the game is looking for should also be valid, but I admit I could be wrong about that since it’s a long time since I’ve solved this kind of problem. But in the late game, there’s a puzzle that can only be solved by intuiting the presence of an undescribed item (Spoiler - click to show)(the bed, in the sequence with Sarah – adding insult to injury, the stuffed animals, which are mentioned, aren’t implemented), and after you resolve the initial trio of challenges you’re thrown into a second that requires you to maneuver two different cars to block the progress of a police cruiser, which is described so confusingly that even the walkthrough couldn’t get me unstuck, requiring a restart.

And finally there’s the puzzle that gates off the real ending from the premature one, which requires both reading the author’s mind AND wrestling with atypical syntax (Spoiler - click to show)(the game very clearly indicates that looking at people is what triggers the body-hopping, so THINK ABOUT SARAH is completely unmotivated and not a command most parser-players would think to try; and after that we’ve got BREAK PACKAGE rather than OPENing it, which gives a discouraging result, and BARK TWICE being mandatory when BARKing on subsequent turns would be more natural). Admittedly, said “real ending” is still a shaggy dog story, but the game is much more satisfying with it than without it so gating it with the aggressiveness with which you’d conceal an Easter Egg is a bad design choice, to my mind.

But again, I don’t think this was a design choice: like everything else I’ve complained about, I think it’s just a lack of testing – there aren’t any credited that I could see, at least, while the blurb describes these extra-spicy puzzles as “mild”, and many of these issues are ones that I think would be easily corrected if the author had the advantage of seeing how people try to grapple with the game. Again, this is an awful shame because Traffic deserves to be its best self; with its many rough edges thoroughly sanded down, I could easily see myself recommending this game to folks in the mood for a clever yet grounded comedy game, so I very much hope to see a post-Comp release.

In this game, the PC is run over by a car that veers onto the sidewalk and killed—and then regains consciousness in the body of the last passer-by they looked at. They loop through the events surrounding their death, trying to manipulate their environment so that everything aligns in such a way that the car doesn’t hit them. It is essentially what in board-gaming circles we would call a programming game, where you’re queuing up a set of actions for each participant that will then execute the next time through the loop.

As far as I’m concerned this is a fantastic premise, and I love the unusual elements of the gameplay structure, too. The writing also serves the concept well; it’s pithy and funny (if more in a wry-smile than a laugh-out-loud kind of way). I can imagine a version of this game that would be one of my favorite games of IFComp 2024.

Unfortunately the puzzles all had moments where they were pretty obtuse, and Traffic doesn’t quite know how to nudge the player in the right direction through helpful error responses or other environmental info. Since there are also no hints, whenever I got stuck, I really hit a wall. My experience of the game was largely one of getting 2/3 of the way to the solution of a puzzle, getting stumped for an extended period of time, and finally turning to the walkthrough (which very bluntly gives the shortest possible path to the solution).

For example, when playing as the baby, (Spoiler - click to show)I found the pacifier and I had the idea to throw it, but the response to trying to throw the pacifier without a target is simply the default response, “Futile.” Therefore I assumed I was on the wrong track with throwing it, and gave up. If the response had been something like “You don’t think the woman will notice if you just throw it in a random direction”, that would have been really helpful. I then at one point tried TAKE PHONE, which just got the response that I couldn’t reach it. This, too, seems like a missed opportunity to steer the player towards the solution (“Your arms are too short, but maybe there’s another way…” or what have you). The former suggestion and the latter combined would probably have added up to THROW PACIFIER AT PHONE in my brain; nothing currently in the game did.

In general, even just a VERBS command listing the verbs needed to complete the game would have been a big help. Anything to point me in the right direction just a little bit.

This string of almost-but-not-quite-figuring-out-the-puzzle-myself experiences left me feeling vaguely disappointed and unsatisfied; like a cat chasing a laser pointer, I have stalked my prey (the puzzles) at length but not, ultimately, gotten my kill (the triumph of actually solving one). So I walked away mostly feeling cranky about the whole experience, which is a shame because there’s so much going on here that I do like.

Parser games let you type in whatever you want. They only respond to a small fragment of that. If I open a random parser game and say 'I endeavor to hop on my right foot fifty-five times before squawking like a parrot', then it won't respond with meaningful feedback (I know AI can respond, but the chance of that response containing content intended by the author that directly pertains to my command is low).

This is one reason new parser players struggle; how do you know what to type?

Parser games traditionally solve this in two ways. The first is by the community adopting unspoken customs about what commands are important. By experience, players come to know that 'X ME, 'INVENTORY', 'TAKE', 'DROP', 'PUSH', 'ENTER', etc. are generally understood and work well.

The second is by giving the commands in-game, either explicitly (like limited parser games that list the required vocab) or implicitly (if the game says, 'You feel a strong desire to yodel', then you can reasonably expect to be able to yodel).

This game takes neither of those two paths. In it, you play through various related scenarios about a traffic jam in an intersection. Many, if not most, of these scenarios are solved by commands that are both unusual in parser games and which aren't provided or mentioned in-game.

That makes this game pretty hard. Adding on to that, there are some default actions that don't have responses, making it hard to know what to do.

The storyline is a fun concept, and I enjoyed the ending, but I ended up using the walkthrough for about 70% of the game. I won't elaborate too much on the story as there are some early spoilers that give much of the flavor of the game, but suffice it to say that this is a puzzle about examining a system of interconnected events and trying to figure out how to adjust them in order to save yourself.

I think the game could benefit from responses to an ABOUT command to give expectations to the player. While I personally would have also liked more nudges in-game or a better idea of necessary commands, I realize that that may not match the author's vision and that they may have directly desired for players to have to hunt and experiment for a while. If that's the case, I think it's fine to leave it as-is.