Omni-Gear Protocol — Scaling the Joke

One chassis. Three gears. Zero margin for error.

OMNI-GEAR PROTOCOL is a physics-based puzzle platformer set inside a decaying industrial complex. You play as a prototype robot whose entire functionality depends on three specialized mechanical components called Cogs.

Each Cog grants a different ability: movement, jumping, or telekinetic interaction. But there's a catch. These components aren't permanently attached to you. They're physical objects that can be removed, transferred, and sacrificed to operate the factory's machinery.

To progress, you'll have to give up parts of yourself. Sometimes, the only way forward is to become completely helpless and hope you can retrieve your components before it's too late.

The game revolves around resource management, spatial reasoning, and unconventional puzzle-solving. Every component has a purpose, and every sacrifice changes what you're capable of doing next.

But behind this mechanical puzzle was another experiment entirely: building a team that could operate like a small studio rather than a temporary game jam group.

Back to the Old Team

April 26, 2026. Gamedev.js Jam 2026.

After regaining some confidence through my experience with a randomized team during Intern of the Cosmos, I decided to return to my previous team.

This time, I wanted something bigger.

I was no longer interested in competing only in small game jams with limited submissions. I wanted to challenge myself in a much larger competition, one with a substantial number of participants and a much bigger prize pool.

My reasoning was simple: I'd rather lose against 500 submissions than win against just two.

It was a different kind of ambition, but it also came with a different set of risks.

Building Something Bigger Than a Jam Team

One of the more unusual decisions I made was recruiting people who had little experience working in collaborative development environments.

I was still riding the confidence I gained from Intern of the Cosmos, and I wanted to test whether my production system was truly people-agnostic.

Rather than simply assembling another random game jam team, I started building something that resembled a small-scale studio.

This was also when I created the Slafurry Studios Discord server.

Instead of putting everyone into one crowded communication channel, I introduced dedicated channels for different departments. Artists could coordinate with other artists, programmers could discuss technical matters, and information could be organized around the people who actually needed it.

It sounds like a fairly ordinary decision, but it was another missing piece of the production system I had been developing.

Previous projects had taught me that communication problems could easily derail an entire production. This time, I wanted to make collaboration more structured without making it unnecessarily complicated.

And surprisingly, it worked really well.

Code Less, Let Designers Do More

The plug-and-play philosophy from Intern of the Cosmos also continued into this project.

I focused on creating reusable gameplay systems, supported by proper documentation and examples that explained how those systems could be used.

This allowed the level designer to experiment with mechanics without constantly depending on the programmer to implement every new interaction.

And the results were better than I expected.

The level designer managed to create puzzle combinations that I hadn't even considered possible when designing the original systems.

That was exactly what I wanted from a modular development approach: building a foundation that allows other people to discover possibilities beyond the original design.

However, there was another problem.

The difficulty curve turned out to be much harsher than intended. The puzzles could become surprisingly challenging, and not every player would necessarily have the patience to figure them out.

A flexible system gives designers more freedom, but that freedom still needs direction. Having the ability to create complicated puzzles doesn't automatically mean those puzzles are enjoyable or accessible.

A Small Team, A Big Result

Despite the challenges, Omni-Gear Protocol achieved something we were genuinely proud of.

Out of 487 submissions in Gamedev.js Jam 2026, the game received 4th place in the Innovation category.

For a relatively small team working with a limited scope, that was a significant result.

It showed that we could compete in a much larger environment and produce something that stood out among hundreds of other submissions.

More importantly, it validated several of the decisions I had been experimenting with.

The structured communication channels, modular gameplay systems, documentation, and division of responsibilities had all contributed to making the production process work.

And somewhere along the way, a team that started from a joke began to resemble an actual game studio.

Slafurry Studios is the result of a joke.

A joke that somehow grew beyond its original punchline.

The Next Question

Omni-Gear Protocol was a successful experiment, but it didn't answer everything.

If the system could support a larger team, accommodate inexperienced collaborators, and produce a competitive game, how much further could it go?

Was the system genuinely strong enough to scale, or had we simply not reached its limits yet?

There were still problems to solve. Difficulty balancing needed improvement, communication could always be refined, and managing a growing group of contributors would bring entirely new challenges.

I had spent several projects learning how to build a workflow that didn't depend entirely on individual experience.

Now I wanted to know whether that workflow could survive something bigger.

Omni-Gear Protocol gave us a reason to be confident, but it also gave us another reason to keep experimenting.

One chassis. Three gears. Zero margin for error.

And apparently, zero intention of slowing down.