SIGNAL: Following the Idea Instead of the Plan

Godot Wild Jam #98 revealed the theme SIGNAL, and I immediately had several games competing for space in my head.

The initial wildcard choices I explored were FEELING FROGGY, FLASHLIGHT, and DOUBLE DUTY. A frog, a flashlight, and something doing two jobs. Apparently that was enough to start designing a small tactical operation.

SIGNAL could mean communication. It could mean sound, detection, or getting information you didn’t have before. It could also mean revealing yourself—or deliberately changing what another character thinks they know.

I didn’t need to settle that ambiguity immediately. It gave me something to experiment with.

A frog operative needs to move like a frog

The idea moved toward a top-down tactical stealth game with a frog operative. That gave me a character, but it also created a problem: if I could replace the frog with a person and nothing changed, I wasn’t doing much with FEELING FROGGY.

So the controller became a design question. Should walking be smooth, or should each step have a little pulse? Should running become a series of more obvious bounds? What does careful, low movement look like for this character?

I explored a hybrid: controlled stealth movement, subtle pulses while walking, and more visible bounding when moving quickly. Low movement and stealth positioning needed to support the same tactical decisions.

The tension was pretty simple. I wanted it to feel like a frog, but I also wanted the player to get through a doorway without negotiating with an amphibian.

Too much emphasis on the movement rhythm could make positioning awkward. Too little would make the frog identity cosmetic again. The controller evolved around finding a useful balance between those two things.

The croak became more than character flavor

Movement wasn’t the only way to make the frog matter. Croaking started becoming much more interesting than I expected.

A croak can help the player understand the space or manipulate enemy behavior. But making that sound also gives enemies an origin to react to. You gain something by broadcasting a signal, and you create a problem by broadcasting it.

That became the central relationship in SIGNAL.

It also gave DOUBLE DUTY a clear purpose. One mechanic performs two meaningful roles: providing useful information or influencing the situation, while exposing a sound origin to enemies.

That felt more connected to the theme than a collection of gadgets that each did their own thing. The croak wasn’t just another button. It was starting to explain what the game was about.

The flashlight could work. It just wasn’t helping this game.

I started with the assumption that the player would have a usable flashlight. It was one of the wildcards I had picked, and it seemed like a reasonable fit for stealth.

As the croak, enemy perception, information mechanics, and level design developed, that assumption became harder to justify.

The flashlight increasingly felt like a separate mechanic that existed because the wildcard said it should. It wasn’t reinforcing the strongest parts of the design.

This wasn’t a case of being unable to make a flashlight work. A flashlight could work. It just wasn’t helping this particular game.

That distinction matters. A functional mechanic is not automatically a useful mechanic. Something can be implemented correctly and still pull attention away from the decisions that make the rest of the game interesting.

I could keep finding reasons to include it, or I could accept what the prototype was telling me. I removed the flashlight and dropped the FLASHLIGHT wildcard.

The active wildcards are now FEELING FROGGY and DOUBLE DUTY. Keeping an extra wildcard wasn’t worth forcing an extra mechanic into the game.

A laser answered one question and raised another

Removing the flashlight didn’t instantly settle the rest of the design.

I explored a pistol laser because it fit tactical aiming more naturally. That immediately raised a bigger question: how much conventional weaponry actually belongs here?

Gun, laser, knife, takedown, stance, and aiming ideas were prototyped and evaluated. They helped me test what kind of tactical game I wanted, but that doesn’t mean every experiment is a promised feature of the active prototype.

The stealth and information game was becoming the stronger center. Weapon systems could support that, but they didn’t need to become the reason to play.

Implementation was helping me answer design questions. Sometimes the answer was to keep something. Sometimes the answer was that I understood the game better without it.

Then the level needed to teach it

Eventually I had to stop looking at the mechanics one at a time and put them into situations a player could actually read.

The early vertical slice began forming around guards and patrols, incomplete information, the SIGNAL/croak mechanic, LOW traversal and alternate routes, infiltration, sabotage, alert states, and extraction.

That changed the problem from “does the mechanic work?” to “how does somebody learn what it is for?”

How do I teach the player what SIGNAL means without stopping the game to explain SIGNAL?

The early sections started evolving around a sequence of discoveries. The player hears danger but doesn’t have enough information. Using SIGNAL helps make sense of the space. That knowledge gives them a chance to manipulate or avoid an enemy, discover another route, and enter the larger encounter with a better understanding of what they can do.

LOW and alternate traversal needed a reason to exist in those situations, too. An alternate route is more useful when the player understands the risk it helps them avoid.

The level itself was becoming part of the tutorial. I’m still working out how clearly it teaches those relationships, but it gave me a more useful target than adding another explanation to the screen.

I escaped. The objective didn’t.

The early mission structure is straightforward on paper: infiltrate a compound, sabotage the objective with a timed bomb, and get out.

Putting a bomb into a stealth game creates quite a few questions that don’t fit neatly into that sentence.

Can guards discover it? Can they investigate it? Can they disarm it? What happens if the operator extracts but the objective fails? And how does the player know which of those states the mission is actually in?

An early playtest produced exactly that uncomfortable result: the operator escaped, but the objective failed.

Getting out and completing the mission were separate things. The prototype needed to communicate that separation more clearly.

That exposed the next design problem: feedback about the bomb and objective state. Planting the bomb, leaving the area, and successfully completing sabotage can’t all feel like the same event if they produce different outcomes.

I don’t have a final answer to every part of that yet. But I have a much clearer problem to solve than I did before the playtest.

Sometimes you don’t discover the next design problem by thinking harder. You discover it by playing what you built.

What changed along the way

SIGNAL hasn’t moved neatly from idea to design to implementation.

It has looked more like an idea, a prototype, an unexpected interaction, a problem, a change, another problem, and a better understanding of the game.

The frog’s appearance led to questions about frog movement. Croaking became the central mechanic. The flashlight became unnecessary. A laser seemed like a better fit, and then weapon systems became secondary to the stealth and information game.

Individual mechanics led to questions about how the level teaches them. The objective system exposed communication problems that weren’t obvious on paper.

I don’t think the discarded experiments were wasted work. They helped define the boundaries of SIGNAL. Trying something gave me evidence I couldn’t get by simply deciding that the first version of the plan was correct.

That’s one of the more useful things about prototyping: you can learn that something works, and then learn that it still doesn’t belong.

Still following the idea

SIGNAL [working title] is still actively being developed for Godot Wild Jam #98. It’s a jam prototype, and the final design is still taking shape.

That’s probably the part I’m enjoying most right now. SIGNAL is becoming clearer, but mostly because I keep finding things that don’t belong in it.

Game design isn’t finding the perfect idea and implementing it exactly as imagined. It’s repeatedly learning what game you’re actually making.

Follow SIGNAL’s current prototype and project notes ↗