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 truly 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, I plan to expand and polish the prototype 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 1

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

As mentioned above, one thing I felt was needed in the game is a core combat mechanic requiring a certain skill level. One thing I wanted to stay away from was first-person melee combat. From researching games with melee combat in a first-person view, I thought it would be difficult to make the game feel right, especially with the constraint on art and 3d modelling.

The next alternative is naturally a first-person shooter. There are a lot of examples of 2D sprite FPS games over the years. One added benefit to the shooting mechanic was that, with a free look camera added, there are more opportunities to add little mechanics that add to the sense of exploration.

I also tried to keep all the controls on the mouse, making it a design challenge to avoid using the WASD. The reason was that I wanted to keep the tactile scrolling control for opening doors, but it would be an awkward input if I moved the interaction to the traditional key bindings. I was worried about the impact it had on the overall combat feel. The main gameplay became the balance between looking away to reposition vs. standing still to aim and shoot.

I also made a few variations of enemies to test out the overall combat feel. However, it felt like the decision that the player needs to make remains the same: moving away and then shoot the closest one.

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

Prototyping Phase 2

Free Movement + Push Melee

From the last iteration, I found that there is actually no real benefit to sticking to mouse-only control. The downside was pretty obvious: the player had to keep looking away and then trying to re-aim at enemies. Ultimately, it was more of an inconvenience than a fun gameplay opportunity. Therefore, the first change was to add free movement using WASD. Another reason for introducing the free movement was that, when the enemies were using free movement while the player was moving at a grid-based system, it felt challenging to judge the distance between things while moving.

Another new mechanic added was the pushing melee. This serves two goals:

  1. It provides an extra option besides shooting. With a well-timed push (especially when the enemy is attacking), the player can deal massive stagger damage to the enemy, knocking them over.

  2. The push is triggered using the scroll wheel, which is the same input used for pushing doors. This keybind emphasizes the push action, even now that movement control has moved to WASD.

One additional change on the enemy side is that, with melee added, there is an increased need to communicate the enemy’s state and movement through more visual cues. Animating a 2D sprite was more resource-demanding than low-poly 3D in that regard, since there are only limited online resources for enemies that face the player directly (most are either top-down or side-view). Therefore, I made a quick 3D version of a zombie to test out the gameplay.

However, from gameplay I realized that adopting a 3D model instead of a 2D sprite for enemies posed an issue. There is a certain level of expectation with an FPS and 3D enemies, and as I started to approach realism, the lack of polish became very apparent, whereas when the game was in pixel-2D, players were more likely to ignore the jankiness.