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

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, “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” (much less funny, I know), 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.