DIRECTIVE — The Hero Is the Problem

ERROR IS FATAL. DIRECTIVES ARE ABSOLUTE.

The Sector has been compromised. Rogue hostiles are committing acts of terrorism against society, and you're the solution.

DIRECTIVE is a high-velocity top-down bullet hell where you operate an advanced kinetic-redirection power suit. Unlike traditional bullet hell games, projectiles don't simply disappear after leaving the screen. Every shot remains a continuous threat, turning the battlefield into an increasingly dangerous environment.

Use phase technology to avoid incoming attacks, manipulate projectile trajectories, and clear rooms of hostile forces.

Every action matters. Every projectile matters.

[MISSION_STATUS: ACTIVE]

DO NOT FAIL ASSIGNED DIRECTIVE.

But while the game was about following directives, its development became an experiment in discovering what happens when a studio grows beyond its original structure.

I WANT TO MAKE IT FALL.

May 11, 2026. Bullet Hell Jam 7.

After the results of Omni-Gear Protocol, I wanted to push our production system further.

The previous project had demonstrated that our workflow could support a growing team. But I still didn't know where its breaking point was.

So I decided to recruit even more people.

I wasn't particularly concerned about winning this jam. I wanted to find out what would happen when the team became large enough to expose the weaknesses in our existing system.

I wanted to break it.

I WANT TO MAKE IT FALL.

And, well, it almost did.

Stress Testing the Studio

The biggest problems initially came from the programming department.

With more programmers joining the project, repository management became increasingly complicated. Some new members made unexpected changes that broke the project or disrupted the existing workflow.

But something interesting happened.

The problems became less frequent over time. New programmers gradually adapted to the repository, learned the workflow, and made fewer mistakes.

Meanwhile, the rest of the production process remained surprisingly stable.

Communication was fine. There was no major chaos, and nobody was experiencing the kind of burnout that had plagued some of our previous projects.

The system had taken a hit, but it didn't collapse.

In fact, the team seemed to be adapting better than I expected.

However, this experiment revealed another missing piece: we needed a proper Standard Operating Procedure.

New members repeatedly encountered the same problems because there was no clear onboarding guide explaining how things worked. Instead, they had to ask me about almost everything, sometimes interrupting development just to figure out basic procedures.

We had documentation for projects, but we didn't yet have a sufficiently complete guide for becoming part of the studio itself.

That needed to change.

The Single Source of Failure

But there was one problem that no amount of documentation could immediately solve.

Me.

If there was a bug, I came in and fixed it.

Spaghetti code? I fixed it.

Optimization problems? I fixed them.

Something wasn't working? Somehow, I was the one expected to make it work again.

I had become the person who silently handled all the technical problems so everyone else could continue working.

At first, it felt like good leadership. I was helping the team move forward, removing obstacles, and making sure development didn't get stuck.

But then I realized what I was actually doing.

I was becoming a villain by becoming the hero of my team's growth.

My team could focus on their responsibilities because they didn't have to deal with most of the problems I was handling behind the scenes.

They might even have started thinking that making games was much easier than it actually was.

Almost everyone was encouraging me to take the studio in a more serious direction. But behind that growing confidence, I was struggling to become the kind of manager the studio needed.

I was still acting as the emergency programmer, technical problem solver, project lead, and whatever else needed attention.

I had built a system that could accommodate more people, but I hadn't built one that could function without me.

Bus Factor = 1

This was particularly concerning because I already understood the danger of having a single source of failure.

In software development, the concept is often described through the Bus Factor: how many people would need to become unavailable before a project could no longer continue properly.

And for our studio, that number was dangerously close to one.

If I disappeared tomorrow, how much of the production process would continue working?

Could other programmers diagnose and resolve technical problems without waiting for me?

Could the team maintain the project, make decisions, and move forward independently?

Or would everything eventually stop because the person holding all the answers was no longer available?

I had spent so much time making the team more productive that I had overlooked how dependent they were becoming on me.

That wasn't the kind of studio I wanted to build.

A Week Away From Game Jams

So I made a decision.

I announced a one-week break from game jam hunting.

No immediately jumping into another competition. No rushing into another project just because there was an opportunity to participate.

I needed time to think, finish the Standard Operating Procedure, and reconsider how responsibilities were distributed across the studio.

More importantly, I needed to ask myself one question:

Would building a studio that still depends so heavily on its founder actually be a good decision?

I didn't want Slafurry Studios to become a collection of people waiting for me to solve their problems.

I wanted to build an environment where people could make decisions, solve problems, learn from mistakes, and continue working without needing the founder to supervise every little thing.

Being useful to the team is one thing.

Being indispensable to the team is another.

The Next Directive

DIRECTIVE was supposed to be another experiment in scaling our production system.

And in many ways, it succeeded. The team grew, new members adapted, communication remained stable, and the workflow survived problems that I had deliberately introduced.

But the most important discovery wasn't about the team.

It was about me.

A studio cannot grow sustainably if every technical problem, every difficult decision, and every unexpected situation eventually leads back to one person.

I had learned how to build a team that could work together.

Now I needed to learn how to build one that could work without me constantly holding everything together.

Because the ultimate goal was never to become the person who could fix everything.

It was to build a studio where nobody had to depend on one person to keep everything alive.

MISSION_STATUS: PAUSED.

NEW DIRECTIVE: ELIMINATE SINGLE POINTS OF FAILURE.