BLACK WATER NIGHT GLASS: What Godot Wild Jam #98 Taught Me

Godot Wild Jam #98 has wrapped up. The ratings are in, and I’ve had a week of watching people encounter BLACK WATER NIGHT GLASS with absolutely none of the knowledge I had while making it.

That turned out to be a fairly important difference.

I came away from this jam with a game I want to keep developing. I also came away with a much clearer understanding of what players enjoyed, where they got stuck, and how much of the experience some of them never reached.

The project started under the working title SIGNAL. I wrote about its development in Following the Idea Instead of the Plan, then posted a release update on itch.io. This is the next part of that story: what happened when people actually played it, and what I’m taking forward.

Where it landed

BLACK WATER NIGHT GLASS finished 64th overall, with 22 ratings. The jam received 158 submissions, and 157 entries received ratings.

Godot Wild Jam #98 results

Category	Score / 5	Rank
Overall	3.234	64
Audio	3.364	45
Theme	3.636	51
Originality	3.545	56
Graphics	3.455	56
Fun	3.136	59
Accessibility	2.773	81
Controls	2.727	87

Game results · Full jam results

Audio was my strongest placement. Theme received my highest category score. Controls and accessibility were the weakest areas, which lines up with quite a bit of the written feedback.

There are several different problems inside those last two categories, though. Some involved browser shortcuts. Others involved understanding what an action required or what the game was telling you after you attempted it. Those need different responses.

The game found an identity I want to keep

The original idea was a frog operative infiltrating a communications facility in darkness.

CROAK became the center of that idea. It reveals useful information, but making a sound also gives nearby enemies something to respond to. That connected the Signal theme with both Feeling Froggy and Double-Duty in a way that affected the decisions you made.

During development, I removed the flashlight because CROAK was becoming the more interesting way to read the environment. I also experimented with movement, aiming, weapons, and different ways of teaching the player through the level. Those experiments helped me figure out which parts belonged together.

The feedback gave me good reasons to keep exploring that direction. Players responded to the minimal visuals, the UI, the atmosphere, and the way CROAK made the space readable. One reviewer who usually doesn’t play stealth games still wanted to keep going.

This response covered both the appeal of the presentation and the friction of learning the controls. Original comment.

The most encouraging feedback described someone combining systems: leaving bodies as bait, using CROAK to lure patrols, and using injuries to change a pursuit. That was the kind of experimentation I hoped the game would support.

It gives me a useful direction for expansion. I want to build encounters that give those tools more interesting relationships and consequences.

The browser shortcuts were an unfortunate way to lose a mission

I bound crouching to Ctrl and movement to WASD.

Ctrl + W closes a browser tab.

Several people found that combination while trying to move carefully or escape. Right-click combinations also opened browser menus for some players. It was especially frustrating to read about someone losing the page close to extraction.

I spent a lot of attention on how the controls felt inside the game and gave too little attention to what the browser would do with those same inputs.

I’m disappointed that this kept people from having the experience I had built. The larger release is going to be downloadable only, so browser shortcuts won’t be part of that version’s control environment. The lesson still matters for any future browser release: test the actual exported experience, including combinations of inputs.

I can’t calculate how much this affected the rankings. What I can see is that it interrupted people who were otherwise interested enough to keep playing.

I’m simplifying takedowns

Takedowns produced the clearest pattern of confusion.

Players weren’t consistently sure whether to hold the button, press it repeatedly, or time their presses. One detailed response described around ten attempts at the opening, with occasional success through mashing that still didn’t feel rewarding.

Earlier in development, I had more feedback around that interaction, including a progress indicator. I stripped it back before release while leaving the timing requirement underneath it.

Looking at the responses now, that information was doing more work than I gave it credit for.

The interaction could succeed without the player understanding why. My reply below the comment describes the feedback I removed. Original comment.

The responses weren’t unanimous. One player suggested that getting behind a guard should earn a clean takedown. Another specifically liked the extra interaction after figuring it out. I appreciate having both perspectives.

For the next prototype, I’ve decided to test the simpler version.

Get close enough from behind, press the button, and the takedown happens immediately and silently.

Reading the patrol, choosing an approach, and reaching that position are the skills I want that action to reward.

I’m also removing the knife for this test. Its future role is still open. It could eventually make sense as a tool, but I haven’t designed a purpose for that yet. The next version of this interaction will focus on the takedown.

That is a decision about what to test next. I still need to see how it feels when someone unfamiliar with the game uses it.

The opening needed checkpoints

Several players struggled to get through the first level. Some made repeated attempts and reached the warehouse, then lost that progress when they died.

This single mission should have had at least one checkpoint, and probably two.

Reaching a later section should have secured some of the progress made getting there. Original comment.

The intention for the larger game is to reward progress through a level with checkpoints. A checkpoint should save your location and enough of the mission state to let you return to that moment. That includes being able to stop playing and continue later.

Dying would return you to the latest checkpoint, with the situation restored coherently: your condition, equipment, guards, bodies, and objective progress.

The exact placement still needs work. Reaching the warehouse is an obvious candidate in the existing mission. Another checkpoint around the relay sequence is worth testing.

I also want to be careful about how I interpret the difficulty feedback. Some people enjoyed the challenge and found themselves wanting another attempt. One response specifically praised the movement pace, gradual introduction of mechanics, and places to hide bodies.

That’s useful evidence too. I want players to learn something from a failed attempt and have a reasonable opportunity to apply it. Repeating a substantial stretch of already-understood play makes that harder.

CROAK needs to communicate its risks more clearly

CROAK received some of the strongest praise, but one response described having better results by avoiding it. From that player’s perspective, revealing the guards also seemed to expose the player immediately.

Other players used it successfully as a lure.

This is a useful warning about how the defining mechanic can feel during the opening. Original comment.

I want to understand that difference before deciding how to rebalance it.

Hearing a sound, investigating its origin, and seeing the operator need to be understandable events. Players should have enough information to predict a response and make a plan around it.

That leaves several things to test: the explanation, the timing of enemy reactions, the opportunities to reposition, and the encounter layout. I want CROAK to feel like a tool you can use deliberately.

Facing, aiming, and knowing what an action will do

The simple shapes helped give the game a consistent visual style. The diamond representing the player also made facing less obvious than it could have been.

That matters when an action depends on direction.

A clearly oriented character would help. I also need the interaction itself to communicate its target. For a takedown, I want the player to understand when a guard is eligible and who the button will affect.

The broader control design is still open. Guns are part of the direction I want to explore as the game expands, which is why the twin-stick approach existed in the first place.

One possibility is to separate movement, facing, and aim. Ordinary movement could determine facing until the player deliberately aims. A weapon could then point independently of movement, while a nearby contextual interaction could align the character with its target.

That is a proposal to prototype. The exact inputs, transitions, and behavior still need testing.

More space needs more interesting decisions

One player reached the relay and felt the earlier areas offered more to engage with. Later on, they could often move along the perimeter without encountering much.

That is a specific observation I want to investigate as I revisit the level.

A larger game will need encounters that develop the existing mechanics: different patrol relationships, reasons to gather information, useful alternate routes, and consequences that change a plan.

Quiet space can help the pacing. I want to be deliberate about where it appears and what it contributes.

There were also reports of abrupt guard rotations and inconsistent knife hits. Those need to be reproduced and understood. Stronger feedback around alert transitions and objective outcomes would help players read the mission as it changes.

The sabotage objective is a good example. An early development test already exposed the possibility of escaping while the objective failed. A later player reported discovering that the charge had been disarmed. Arming the charge, completing sabotage, and reaching extraction need distinct, understandable feedback.

What I learned about making this during a jam

A lot of my development time went into iterating on the level and trying to teach through the situations themselves. I wanted people to discover uses for CROAK, body hiding, and alternate paths while playing.

Some responses show that approach working. Others show where I left too much for the player to infer.

I also learned how misleading my own familiarity could be. During development, I worried that parts might be too easy, even while struggling with them myself. But I knew the patrols, the intended timing, and what every interaction was supposed to mean.

A new player was learning all of that at once.

For the next round of development, I need unfamiliar players early enough that their confusion can influence the design. I want to watch what they try before explaining what I intended.

The other lesson is about feedback. Removing an indicator can make the presentation cleaner while leaving the player with an incomplete explanation of an action. I need to judge those changes by what someone can understand during play.

The jam was useful because it got this whole experience in front of people. Their different reactions have given me much better questions to work on.

What comes next

I’m beginning to plan a more polished, more expansive downloadable version of BLACK WATER NIGHT GLASS.

The next prototype will focus on the decisions I’ve made so far:

• Immediate, silent takedowns that reward getting into position.
• Removing the knife while that simpler interaction is tested.
• Checkpoints that preserve progress through death and between sessions.

Alongside those changes, I’ll be working through facing and aiming, CROAK’s readability, and how the opening teaches the player. Those details are still being designed.

The next useful test is a mission someone can approach without my explanations: learn the interactions, make a deliberate plan, understand the result, and carry that progress forward.

Then I want to see whether they want another mission.

Thanks to everyone who played, rated, and left a comment, especially the people who kept going after a confusing takedown or an unexpected trip out of the browser. The detailed feedback has been useful, and I appreciate the time people gave it.

Play the original jam version of BLACK WATER NIGHT GLASS · Follow the development on RyanPond.com

---

Reviewer names and avatars are hidden in the screenshots. The comment wording is unchanged. Original comments are linked below the screenshots. Click a screenshot to view it at full size.