---

The Future of Game Development Might Be a Cooperative

When AI makes building games easier, the most valuable resource may no longer be the people who can build them, but the people who know what makes them worth playing.

A New Era of Game Development

We are approaching a fundamental shift in how video games are created.

For decades, game development has been constrained by the cost of production. Building a game requires programmers, artists, designers, animators, sound engineers, producers, and countless hours of coordination. Even relatively simple ideas can require substantial resources to turn into something playable.

This has shaped the entire structure of the gaming industry. Studios organize around specialized labor, publishers provide capital, producers manage development, and players eventually receive the finished product.

But artificial intelligence is beginning to challenge this model.

AI can increasingly write code, generate 3D assets, create animations, compose music, produce textures, build levels, and assist with almost every technical aspect of game production. The cost and time required to turn an idea into a working prototype are falling dramatically.

This raises an interesting question:

If building a game becomes relatively easy, what becomes valuable?

I believe the answer is human judgment.

Not necessarily the ability to write code or produce assets, but the ability to recognize what is fun, what feels right, what is frustrating, what is beautiful, and what makes an experience worth returning to.

The scarce resource in game development may shift from production capacity to human taste.

And if that is true, perhaps we should rethink the organizational structure of game development itself.

From Game Studios to Game Cooperatives

Traditional game studios are designed to coordinate labor.

A cooperative game studio could instead be designed to coordinate human creativity, judgment, and participation.

Imagine a game owned by a community of people who collectively participate in its development. These people are not necessarily professional developers. They might be players, designers, critics, artists, storytellers, enthusiasts, or simply people with strong opinions about what makes a game enjoyable.

They become co-owners of the organization that develops the game.

Rather than relying on a small group of employees to make every creative decision, the cooperative provides a framework for a much larger community to contribute ideas, evaluate experiments, and influence the direction of the game.

Members could pay a membership fee to support the organization and participate in its governance. They could propose features, discuss design decisions, vote on experiments, participate in playtests, and contribute to the collective direction of the project.

The organization would operate as a commons: a shared creative asset that belongs to its members rather than an individual founder or outside investor.

The goal isn’t simply to make development more democratic.

It is to create an organization that takes advantage of what AI makes possible while preserving the human element that gives games their character.

The Experiment Becomes the Fundamental Unit of Development

One of the biggest changes I envision is replacing the traditional feature-development process with an experiment-driven model.

In conventional development, an idea goes through planning, design, implementation, testing, and eventually integration into the game.

This process can be expensive. Teams often spend considerable time debating whether something will work before anyone gets to experience it.

With AI-assisted development, we can approach this differently.

Instead of debating an idea indefinitely, we can build it.

Every proposed feature becomes an independent experiment. Each experiment gets its own development environment, implementation history, and playable version.

Consider someone proposing a grappling hook mechanic.

Rather than submitting a simple feature request, they submit an idea describing the experience they want to create:

• What problem does this mechanic solve?
• What should the player feel when using it?
• What possibilities should it introduce?
• What should it avoid?
• How would we determine whether it is successful?

The community can then refine the proposal. Members discuss its strengths, identify problems, suggest alternatives, and improve the design.

Once the proposal reaches sufficient maturity, an AI agent receives the resulting specification and builds a playable implementation.

That implementation lives in its own Git worktree.

It can be launched, tested, modified, and compared with other implementations without affecting the canonical game.

The experiment becomes a persistent artifact.

It doesn’t have to succeed. It doesn’t even have to be merged.

It simply needs to remain available for people to experience and learn from.

A Museum of Playable Ideas

This introduces another interesting possibility: nothing needs to be thrown away.

In traditional development, prototypes and abandoned features often disappear into old branches, disconnected repositories, or forgotten project folders.

In this model, every experiment can remain playable indefinitely.

Imagine opening the cooperative’s website and browsing hundreds of experiments:

• Different movement systems.
• Alternative combat mechanics.
• Experimental physics.
• New camera perspectives.
• Alternative progression systems.
• Different approaches to level design.
• Competing interpretations of the same feature.

Each experiment has its own history, contributors, design discussions, prompts, implementation versions, and playtest results.

You could explore the evolution of an idea from its original proposal to its various implementations.

Someone might even discover an abandoned experiment from two years ago, revive it, and take it in an entirely new direction.

The development history becomes a living museum of ideas.

More importantly, the organization accumulates knowledge rather than repeatedly starting from scratch.

GitHub Meets Wikipedia Meets Reddit

To make this work, the cooperative needs a different kind of development platform.

I imagine something combining three familiar systems.

GitHub provides the technical foundation.

Every experiment has its own worktree, version history, code, assets, and implementation artifacts. AI agents can work on isolated versions without destabilizing the main game.

Wikipedia provides the collaborative knowledge system.

Feature proposals become living documents. Members can refine specifications, correct assumptions, add constraints, propose alternatives, and maintain documentation.

The original proposal is not necessarily the final specification. It evolves through community participation.

Reddit provides the social discovery and voting system.

Members can discover interesting experiments, discuss them, and express their preferences.

But voting should be more sophisticated than a simple upvote.

There is a difference between liking an idea and liking its implementation.

Members should be able to express whether they:

• Want to see an experiment developed.
• Like the concept but dislike the implementation.
• Believe it improves the game.
• Disagree with its direction.
• Are uncertain.

This distinction matters because popularity and design quality are not necessarily the same thing.

The platform should help the community discover promising ideas without reducing every creative decision to a popularity contest.

The Most Important Role: Human Taste

If AI becomes increasingly capable of implementing almost any reasonable design specification, then the people who can recognize good design become extraordinarily valuable.

Consider the difference between two instructions:

“Create a movement system that allows the player to walk on walls.”

And:

“I want the player to feel as though gravity is a suggestion rather than a limitation. Moving between surfaces should feel natural, expressive, and physically satisfying. The player should discover creative ways to navigate the environment.”

The first describes functionality.

The second describes an experience.

The distinction is important because games are not merely collections of technical features. They are experiences designed for humans.

A mechanic can function perfectly and still feel terrible.

A movement system can be technically impressive but lack responsiveness. A combat system can be balanced but boring. A level can be visually beautiful but fail to encourage exploration.

AI can help implement these systems, but determining whether they actually work as experiences requires human evaluation.

This creates opportunities for people whose primary contribution is not programming or asset production, but their ability to recognize and articulate what makes something enjoyable.

We might eventually see roles such as:

• Taste curators.
• Playtest coordinators.
• Design stewards.
• Experience evaluators.
• Community designers.
• Experiment coordinators.

These people help translate subjective human experiences into actionable design direction.

Their contribution is not necessarily producing the game.

It is helping the organization discover what the game should become.

Let Competing Ideas Compete

Another advantage of this model is that disagreements no longer need to be resolved entirely through discussion.

Suppose the community disagrees about whether a game should have stamina.

One group believes stamina creates meaningful resource management. Another believes it unnecessarily restricts movement.

In a traditional studio, this might result in meetings, arguments, and eventually a decision made by a design director.

In an experiment-driven cooperative, both ideas can be implemented.

Experiment A introduces stamina.

Experiment B removes stamina.

Both become playable.

Members can experience the difference, compare implementations, and provide feedback.

The question changes from:

“I think stamina would make the game better.”

To:

“Which implementation actually creates the better experience?”

This is a powerful shift.

Instead of trying to predict the outcome of a design decision, we can create competing implementations and let people experience them.

We can even organize design competitions where multiple groups independently attempt to solve the same problem.

The best ideas can emerge through experimentation rather than hierarchy.

The Organization as a Human Feedback System

The cooperative would need a structured process for evaluating experiments.

After playing a prototype, members could provide feedback on several dimensions:

• Fun.
• Responsiveness.
• Clarity.
• Novelty.
• Satisfaction.
• Replayability.
• Frustration.
• Overall experience.

But numerical ratings alone are insufficient.

We should also ask questions such as:

What was the most interesting moment?

What felt frustrating?

What surprised you?

What would you remove?

Would you voluntarily play this again?

Would you want this mechanic in the main game?

These responses become a valuable knowledge base.

Over time, the cooperative develops a record of how people respond to different design decisions.

It can identify patterns, compare competing approaches, and learn which design principles consistently produce better experiences.

The community isn’t simply voting on features.

It is collectively building an understanding of game design.

The Challenge: Human Attention Becomes the Bottleneck

There is one significant problem with this model.

If AI makes experimentation cheap, the organization could generate more playable ideas than its members could ever evaluate.

We might be able to produce hundreds or thousands of experiments, but people only have so much time to play them.

This means the cooperative needs an effective system for allocating human attention.

Voting, recommendations, design reviews, and curated experiment collections become essential.

The organization needs to identify which experiments deserve further development and which are worth asking people to play.

This is where community participation becomes particularly valuable.

Members are not just funding production. They are helping determine where the organization’s limited human attention should go.

The development pipeline might look like this:

Ideas → Community refinement → Prioritization → AI implementation → Playtesting → Evaluation → Integration or preservation.

Not every idea deserves to become part of the canonical game.

But every sufficiently interesting experiment can contribute to the organization’s collective knowledge.

Ownership and Governance

For this model to work, the cooperative needs to be more than a community with a membership subscription.

It needs an actual ownership and governance structure.

Members should have clearly defined rights and responsibilities.

I would favor a democratic cooperative model where governance is based on membership rather than financial investment.

One member, one vote.

Contributing more money should not automatically mean having more control over the creative direction.

The cooperative would own the game, its intellectual property, its infrastructure, and the collective assets produced through the organization, subject to clearly defined contributor agreements.

It could operate with elected representatives, design stewards, financial oversight, and transparent decision-making.

Revenue from the game could support ongoing development, infrastructure, member compensation, community grants, and reserves.

There would also need to be clear rules around intellectual property, contributor rights, licensing, and commercial distribution.

The precise legal structure could take different forms depending on the jurisdiction. A cooperative, nonprofit foundation, or combination of legal entities might be appropriate.

The important principle is that the organization exists to serve the collective creative project rather than extract value from its contributors.

The Canonical Game and the Experimental Universe

One final architectural distinction is important.

The cooperative should maintain two separate environments.

The first is the canonical game: the official, integrated experience that players can rely on.

The second is the experimental universe: the collection of independent ideas, prototypes, alternative implementations, and abandoned directions.

The canonical game should be relatively stable.

The experimental universe should be unrestricted.

Experiments that demonstrate their value can be proposed for integration into the main game. That integration should follow a documented review process, with clear technical and design requirements.

This separation allows the organization to encourage experimentation without making the main game unstable.

It also means that the community doesn’t have to agree on every design decision.

Different interpretations can coexist.

A Different Kind of Game Studio

Ultimately, I think AI presents us with an opportunity to rethink the entire structure of creative production.

If the cost of implementation continues to fall, then the traditional model of organizing large groups of specialized labor may no longer be the only effective way to create games.

We could instead organize around communities of people who collectively own, explore, evaluate, and evolve creative projects.

AI agents provide the implementation capacity.

The cooperative provides the organizational structure.

The community provides the ideas, judgment, and feedback.

The game becomes the product of an ongoing collective process rather than the output of a fixed production team.

And perhaps the most interesting consequence is that the value of participation changes.

You don’t need to be a programmer to meaningfully contribute to a game.

You don’t need to be an artist to influence its visual direction.

You don’t need to be a professional designer to recognize that a mechanic feels wrong.

You just need to be someone who cares about the experience and can help make it better.

Perhaps the next generation of game studios won’t be organized around people who build games, but around communities of people who collectively decide what those games should be.