Ifu Postmortem

Postmortem

I felt inspired to write this postmortem as a way of collecting my thoughts and lessons learned in the month since I started working on Ifu for The Case of the Thinky Game Jam. This post is a combination of reflection, self critique, and analysis of genre defining games like Case of the Golden Idol, Obra Dinn, and Outer Wilds. I'm posting it alongside an update to the game, which you can read about here: https://otergen.itch.io/ifu/devlog/662431/ifu-post-jam-update-notes

Original thoughts for the game

I learned about The Case of the Thinky Game Jam in early December, a few days after it had started. At the time, I had just started learning JavaScript after completing the latest update to Postcards, a Ludum Dare game I was taking further into development. While working on that update, I'd gotten an idea for a deduction game that I was excited to start exploring over the holidays.

Enter The Case of the Thinky Game Jam: a perfect opportunity to figure out how deduction games work and flesh out ideas for my own game, while also providing a hands on way to rapidly learn JavaScript and the Twine format that uses it, Snowman. The task of the Jam was deceptively simple: to capture that “Aha!” moment that games like Case of the Golden Idol, Obra Dinn, and others have done so well, with few successors in the the genre.

I initially planned to make a piece of interactive fiction in which the main mechanic was the ability to swap between two main characters—nurse/doctor Marie, and pilot Ifu—to solve a murder in a field hospital. While controlling one character to gather clues, the other would go off and generate their own, and at times, the two would be together and the player could switch freely between them, leveraging the differences between Ifu and Marie to interact with the world differently. As you might expect, a game like this was massively out of scope for a game jam.

I ripcorded out of my initial idea after the first few days, changing to Ifu's current gameplay, which is loosely based on the looping mechanic of Outer Wilds: rather than solve a murder, you play as Marie trying to save an injured Ifu on the brink of death. The story came together in a single night and seemed within scope, but that was just the beginning.

“Aha!”

The task of making a deductive game from scratch was my greatest difficulty in creating Ifu. It was a paralyzing prospect to try to write a story and gameplay that would provide a satisfying challenge to the player.

I started by envisioning playing doctor: dropped into a surgery with very little information to go on, figuring out everything by trial and error. Then as the game loop restarted, the patient starts talking, the doctor and patient converse, the player able to select dialogue options to influence the story as much as the surgery itself—a feature quickly cut to maintain scope, but in thinking through what they would say, the story and the game's mystery were born.

After the story, I delved into mechanics—what the different surgery tasks tools would be, how loops would play out and build on each other, how extra hints and story bits might be delivered. From mechanics, it was on to bugs: as my first game in Snowman and using JS, there was a lot of learning and bug fixing—and some truly flabbergasting non-bugs that defied what I was learning. Once I couldn't find anymore bugs, I got a family member to sit down with the game so that I could return to thinking about the “Aha!” moment that had previously paralyzed me.

From a singular playtest I added a lot of polish points to the game: the “What Happened to Ifu” readout between attempts, the ability to end an attempt early, various Tips between attempts, the ending sequence, and plenty of little things. A big point of polish was adding bigger areas for the player to click on wounds through invisible rectangles—previously the player had to click on the exact svg path, which was massively annoying.

Perhaps you'll notice that none of these were the “Aha!” moment I sought. I added a few hint mechanisms in case the player got totally lost, but still relied on them following my train of thought in figuring out the sequence of injuries. Without getting into spoilers, this train of thought was laid out as injury mapping on the body: wounds of a similar type in similar places must have the same origin. Those that are outliers have their own cause, to be deduced toward the end of the game (importantly, all the outlier injuries were only ever outliers, there was no way to connect them and discern a sequence before today's update). If a player didn't grasp this specific pattern as the path to the solution, they'd have no way to solve the game without brute force, which was a pretty major shortcoming.

Now in this post-jam update, I've tried to go back, look at the game holistically, and see where and how a player might figure out each solution. I'm still not sure it's a “good” deductive game, but it ought to be better than it was, and it taught me some important things about making a good thinky game.

Takeaways From My First Deduction Game

Playtests. Had I sat down and built Ifu as a series of little puzzles each with its own evidence and different ways to arrive at solutions, it would be a better game. It may be harder to make a game like this, as opposed to the story/solution first way I did, but by the time I went back and thought about Ifu as a series of puzzles, I'd already made design choices that limited how the game could authentically point the player to a solution, rather than cheaply hinting at it. I'd originally thought I could tweak the game like this during playtesting, but this wasn't the case: at this stage, the game was too far along. Feedback helped with polish and matters of guidance for the player, not in improving puzzle fundamentals. Making a game with a proper puzzle foundation happens much earlier in development.

Stuckness. Going into The Case of the Thinky Game Jam, I was aware of the problem of deduction games where a player has all the evidence but still can't figure out how to proceed. I feel like games suffer when gameplay halts like this, so I tried to address it. In my original idea for the jam, I crafted a story that would continue moving forward no matter whether a player's solution was right or wrong, and that solution's correctness would influence the story outcome. In Ifu, I tried to address it with the looping aspect: if you stop to try and think through something for too long, the loop resets, so you might as well just try something. It didn't totally work, players could still get stuck as a fault of Ifu as a deduction game, but in future I still want to create games that don't stop when the player has to think or is stuck, rather one in which the game supports the player actively thinking and feeling out paths toward the right solution.

Dynamism. Puzzles should be able to respond to or accommodate different kinds of players. Before the update, Ifu was information-gated behind the player looping through the game a certain number of times. I had done this in anticipation of players needing time to get their bearings in the game, only to find out the hard way that players will get their bearings and solve puzzles at different paces. Even after updating to address these things, Ifu by its nature isn't a very dynamic or responsive game. In future, I would make sure that players can connect the dots toward a puzzle solution in different ways and at different paces. One path could still be the most challenging and rewarding, but a variety of acceptable paths should help ensure no player gets stuck, or doesn't get stuck for too long.

Information and Responsiveness. I provided very little guidance to the player in Ifu, both as a game design choice and because I was unsure how responsive to make the game. I was constantly worried I would add too much in the way of evidence or hints and thus cheapen the player's experience. The most notable example of this was a mechanic I'll call wound memories: Ifu the injured soldier starts to get his memory back as you heal wounds, and says things that help the player solve overall mystery in the game. Originally, I thought he would remember and say more and more as you healed his injuries in the correct order, but I backed off of this because it would be difficult to implement, and I worried it would make the game too easy. So I settled on having him remember only the first wound you heal, figuring enterprising players would use this mechanic to learn about each wound: they would accept not solving the game in that particular loop to instead learn valuable information. To say it a different way, a player would have to fail an attempt to ultimately succeed at the game. That's bad game design. I asked myself why I was so reluctant to add this extra information, if there was such a thing as too much information for the player, then realized the harm of the opposite case: too little evidence for the player to work with. When I realized this, I implemented the original and more responsive version of wound memories, but adjusted them so they wouldn't completely spoil things for the player.

Gameplay Monotony. Ifu is a looping point and click game, after a while it gets monotonous to click through everything over and over. Though I managed to cut out some unnecessary monotony in the update, if I made this game over again, I would try to shake up the gameplay more and more as the player got closer and closer to beating the game, to make the moment of finally beating it feel more exciting. In a longer form game, I'd also ensure there are different kinds of interactions and gameplay mechanics to help relieve monotony (although Obra Dinn manages to stave off monotony through its story hooks and evolution of its puzzle mechanic rather than gameplay variety, so there are multiple ways to tackle this problem).

Evidence and Hints. Thus far I've written of evidence and hints as largely interchangeable, when I know they are not. Evidence is implemented as core to the game, what a player uses to make deductions. Some games offer up their evidence as part of how the game inevitably plays out and it's up to the player to use their increasing amount of evidence to solve portions of a large pool of unknowns (like Obra Dinn with its pool of 60 characters). Others break up their pools of unknowns ahead of time, so each narrative chapter is contained and can build on the previous one without showing the player all the pieces of the puzzle from the beginning (like the cases in Case of the Golden Idol). Still others reveal their mystery but leave it to the player to find and utilize clues (like Outer Wilds). Ifu struggles when it comes to evidence: there are the wounds and their descriptions, there are dialogues to reveal the story and wound memories to help signal to a player they are on the right track and what a solution might be. But fundamentally, the mystery and its solution aren't properly incorporated into the game's evidence to allow the player to deduce what's happened to Ifu in a satisfying way. Instead I fear that these clues verge on being hints—things outside the core of the game that I as the developer provide to help players along, with each hint cheapening rather than enriching the experience. It's still something I'm trying to untangle a solution for, so that I can do a better job going forward.

In conclusion, Ifu was my first attempt at making a deduction style game, and while the game itself is maybe OK at best, it's been helpful in other ways. Seeing other people's feedback and giving it my own self-critique, as well as comparing it to other games I love, has begun to show me what makes a good deduction game and where Ifu struggles, and how I can make better games in the future.