Read the Room (Work in Progress)

Roles: Game Designer, Programmer

Production Time: 3 days during Game Jam. Currently Work in Progress for 1 month.

Team Size: 5

Engine: Unity

Platform: PC

Link: Itch.io for the game jam build

“Read the Room” is a roguelike dungeon-crawler where opening a door is a high-stakes gamble. Open the door with your scroll wheel. Glimpse the danger, then decide: fight or slam it shut. Each room’s quick combat hinges on high-stakes calls of risk and reward. See how far you’ll push your luck before extracting with the loot you’ve collected.

Ideation & Game Jam Phase

This is truely a project born out of passion. I participated in a small school game jam for 3 days during fall break. The theme was “Fight or Flight”.

I wanted to capture that classic movie beat: you push a door open, see a roomful of tough enemies, then quickly back out and shut it again. After playtesting it among peers and friends, I was happy to find out that, the “door moment” worked.

Encouraged by that spark, two friends and I now plan to expand on the prototype and polish it into a feature complete demo.

What We Did Right

  • My favorite design decision was swapping out the typical W/S keys for a scroll wheel to control forward/backward movement.

    This was meant to mimic the tactile sensation of opening and closing a door: you aren’t just pressing a button to toggle a binary “door open” or “door closed” state, but rather easing it open or slamming it shut with variable speed. This continuous control scheme highlights the in-between states—the moments of hesitation or abrupt decision—which traditional one-button doors don’t capture. In most games, a door is a simple on/off toggle, but here, your scroll wheel input literally shapes the way you approach (or retreat from) danger. It’s a lesson I learned from an earlier alt-control project: how players physically interact with the hardware can profoundly affect the “feel” of the mechanic itself.

    An added benefit is how seamlessly this partial opening state fits with the first-person camera in our game. As you scroll the door open, the information you see inside the room changes dynamically, potentially revealing threats just out of view. A seemingly harmless scene can turn deadly the moment you catch a menacing figure in the corner of your eye. This tension arises precisely because the door’s openness and your line of sight evolve together.

    Overall, this mechanic is key to creating the “fight or flight” experience.

  • Inspired by dungeon crawler games, the 1st person + grid based movement create both a nostalgic and immersive feel to exploring in the dungeon.

    Another benefit is how smoothly it pairs with scroll-wheel controls for forward/backward, letting me assign turning left/right to mouse buttons. That way, the entire movement control stays on a single device, reinforcing a slower, more methodical pace that suits the tense atmosphere of exploring each corridor.

What Needs Improvement

With limited time, it is natural that the game jam build is not without flaws. In fact, there are several design problems that needs to be addressed. I will discuss them in the next section.

Prototyping Phase

Analysis on Design Problems

Core Decision Making: Door Opening

In the game jam build, the decision on whether or not to open a door is THE core decision the player has to make. However, it felt unsatisfying.

There are several factors at play that are also intertwined. To fully understand the issue, I examined the decision from the two components that make up a decision: risk and reward.

Risk

The risk of opening a door is naturally tied to the combat needed to clear the room. Right now, though, the combat assessment feels very binary: you either “obviously can” or “obviously can’t” handle it. That robs us of the “maybe I’ll squeak through” tension, which is what really creates those dramatic moments. I see two main reasons for this.

  1. The combat is so simple that it’s almost entirely predictable. One big reason we went with simple stat exchanges and automated combat was our time/resource constraints. I also worried that, if the combat were too complicated, players, with limited time to make a decision, would just be guessing anyway. But as a result, that simplicity does not generate enough uncertainty.

  2. There’s no skill factor at play. I don’t think that’s the root cause, because games like Loop Hero also lack direct skill input but still manage to build suspenseful moments. Skill variation is just one way of generating uncertainty if the rest of the system isn’t complex enough.

Overall, the key point is that our current system doesn’t allow for that borderline scenario where you’re not completely sure if you’ll make it out alive. That borderline moment is where the real drama should come from, and right now it’s missing.

Reward

In this game, players can also see potential rewards for clearing a room, since the items are visibly placed in the room while player peeks into the room. In the game jam build, there are mainly two types of rewards/items. the first type is effectively victory points that have a monetary value assigned and will count as the loot when the player extracts from the dungeon. The second type is stat boosts items that provide either attack or defense values to the player. The issue is that neither type generate interesting enough decisions to the player.

Added Features

Free-look camera

Shooting

Event Chain System for Power-Ups

I’ve always been curious about how roguelike games—such as The Binding of Isaac—manage a huge variety of items that not only modify a character’s basic stats but also have significant gameplay-altering effects while still working together seamlessly. I realized that simply adding a massive chain of if statements to check numerous booleans isn’t the right approach. After discussing this with some engineering friends, I decided to try an event chain system.

The main idea is to use event chains to describe a sequence of actions that should occur whenever a specific event is triggered. Examples of such events include: when a player’s attack hits an enemy, when the player takes damage, or when a character dies. Traditionally, these events might be handled by multiple objects or managers subscribing to them. However, by leveraging an event chain manager, I can encapsulate each piece of logic in an event node. This approach allows me to easily add or remove these nodes during the game, making the system both flexible and modular.

Even better, I can turn these event nodes into ScriptableObjects that act as passive item effects. For instance, I could create an event node that spawns a new projectile and makes it bounce to the nearest enemy, then insert that logic into the hit event chain to achieve a “projectile bounce” effect. This method keeps the code cleaner, more organized, and highly extensible—essential for a roguelike game with tons of different item combinations.

This flow charts shows when the event chains for generating an attack and for processing hitting an enemy

This graph is the current implementation of the Event Chain when an enemy gets hit