Why I Open-Sourced a Backend for a Game I Haven't Started Yet
When people think about open source, it is usually after a project has already been used in production, after a tool has proven itself in the real world, or after a game has already shipped and the developer wants to share what they built.
This is not one of those cases.
For a while now, I have been planning a future open-world VR game. That project is still far from active development, but during the planning phase I started thinking seriously about the architecture behind it. One part of that architecture stood out to me more than the others: the networking backend.
I did not want to wait until the game was actually being built to figure out how that backend should work. I also did not want to leave the code sitting on my computer for months or years while I worked on other things. So instead of keeping it private until the game eventually enters development, I decided to clean it up, separate it from the game itself, and release it as an open-source project.
The result is DWCS (Distributed World Computation & Synchronization).
The Idea
DWCS is an engine-agnostic backend whose responsibility is very small and very specific.
It coordinates distributed computation and synchronizes a shared world state.
It does not know what your data represents.
It does not know anything about animations, physics, rendering, AI, gameplay rules, or engine-specific systems.
Those responsibilities belong entirely to the application using it.
DWCS only coordinates tasks, receives results, stores synchronized state, and distributes updates.
In other words, it is infrastructure rather than game logic.
That distinction matters a lot, because the entire project was built around the idea that the backend should not need to understand the meaning of the data it is moving around. It should only understand how to move it, how to coordinate it, and how to keep it consistent across participants.
Why Build Something Like This?
The original motivation came from a simple but important question:
Who should perform the computation in a multiplayer system?
There are really two common answers.
One answer is that the server performs the computation. In that model, the server is responsible for most of the heavy lifting. It calculates the world state, validates actions, resolves conflicts, and sends the results to the players.
The other answer is that the players perform the computation. In that model, clients do more of the work locally and the server mainly coordinates, validates, or synchronizes the results.
Both approaches work. Both approaches are used in real systems. But both approaches also have trade-offs.
If the server performs too much computation, then the server becomes expensive to run. The more players you add, the more CPU and memory you need. The more dynamic the world becomes, the more work the server has to do. That means the infrastructure cost grows as the game grows. For a small prototype that may be acceptable, but for a larger multiplayer world it can become a serious problem.
If the players perform too much computation, then you run into other issues. Trust becomes harder. Synchronization becomes more complicated. Different clients may produce different results. You have to think about validation, consistency, cheating, and conflict resolution. That does not mean client-side computation is bad. It just means it needs to be designed carefully.
I wanted to explore a different balance.
Instead of making the backend responsible for application-specific computation, what if it only coordinated work?
What if the backend did not need to know whether the data represented a simulation, an animation, a procedural system, a shader parameter, or something else entirely?
What if the backend simply distributed tasks, collected results, and synchronized the shared state?
That idea became DWCS.
The motivation was not just theoretical. It came from the practical reality that I do not want the server to carry a heavy load forever. As the number of players increases, the amount of work the server has to do usually increases too. That means more power, more resources, and more cost. I wanted to design something where the load could be distributed more intelligently instead of forcing the server to do everything.
This was especially interesting to me because I am also working on similar projects and experimenting with related ideas around multiplayer architecture, distributed systems, and engine-agnostic tooling. While planning this new game idea, I realized that the backend itself was interesting enough to stand on its own.
The Original Goal
The project was not originally intended to become an open-source library.
It was created as one component of a future VR game that I have not started working on yet.
Standalone VR headsets are powerful, but they still have limited CPU and GPU resources compared to desktop hardware. At the same time, pushing more computation to dedicated servers can become expensive very quickly. That creates a difficult trade-off.
If the server does everything, the server becomes the bottleneck.
If the client does everything, the client becomes more responsible for computation, but synchronization and trust become harder.
I wanted to explore a middle ground where the backend would not be the place where all the application logic lives. Instead, it would act as a coordinator for distributed work.
That means the backend can manage synchronization, ownership, and task distribution while the application decides what should actually be computed, how the results should be validated, and how those results should be used.
Whether that computation is related to animations, simulation, AI, procedural generation, world updates, or something completely different is up to the developer.
DWCS does not care what the bytes represent.
That was the core idea from the beginning.
A Different Way to Think About the Backend
Traditional multiplayer backends usually understand the application’s data.
They know about movement.
They know about physics.
They know about combat.
They know about gameplay rules.
They often end up being tightly coupled to the specific game or engine they were built for.
This project intentionally avoids that.
DWCS treats every payload as opaque data.
It does not need to know whether the incoming data represents a character position, a terrain chunk, a weather update, a procedural object, or a custom simulation result. It only needs to know how to coordinate the flow of that data.
That makes the backend much more flexible. It also makes it easier to reuse in different kinds of projects, because the backend is not tied to one specific gameplay model.
The application decides what the data means.
The backend decides how to coordinate it.
That separation is one of the most important design choices in the entire project.
Two Independent Domains
The architecture separates responsibility into two completely independent concepts.
Domain 1 — Computation
This determines what a participant is allowed to compute.
A developer may choose to assign computation based on distance, visibility, ownership, interaction, workload balancing, custom gameplay logic, or any other rule they want.
The backend does not enforce the policy itself.
It simply distributes work according to whatever the application decides.
Once computation is finished, the participant submits the result back to the backend.
This is the part that helps reduce the burden on the server. Instead of the server doing all the work, the work can be distributed across participants in a controlled way. That does not mean every task should be pushed to clients. It means the architecture allows the developer to decide where the work belongs.
Domain 2 — Synchronization
This determines what data a participant receives.
Receiving data and computing data are intentionally independent.
A participant may receive updates for one region while computing another.
A participant may compute nothing while still receiving synchronization updates.
A participant may compute a task locally and still subscribe to a broader shared world state.
The backend keeps these concepts separate instead of assuming they should always be identical.
That separation is useful because not every participant needs to do the same thing. In a multiplayer world, different players may have different responsibilities, different visibility, different authority, or different levels of access. DWCS is designed to support that kind of flexibility.
Why the Separation Matters
This separation between computation and synchronization is not just a technical detail. It is the reason the project exists.
If the server is responsible for both computation and synchronization, then the server becomes the center of everything. That can be simple, but it can also become expensive and difficult to scale.
If the clients are responsible for both computation and synchronization, then the system may become more distributed, but it also becomes harder to keep consistent.
By separating the two, DWCS allows the application to decide how much work should happen where.
That means the backend can support different patterns depending on the project:
- a more server-authoritative model
- a more distributed model
- a hybrid model
- a model where some tasks are local and others are shared
- a model where different participants see different subsets of the world
This flexibility was important to me because I did not want to lock the future game into one rigid networking style before development even began.
Two Deployment Models
DWCS currently supports two different approaches.
Server Mode
A centralized server manages ownership, task leases, synchronization, and the authoritative world state.
This mode provides predictable coordination and is intended for applications that prefer a central authority.
It is the more mature part of the project and the one that aligns most closely with the idea of a controlled multiplayer backend. The server can assign work, track who owns what, manage updates, and keep the shared state consistent.
This mode is especially useful when you want a clear source of truth and a straightforward way to coordinate participants.
Peer Mode
The peer-to-peer mode removes the central coordinator.
Each participant computes locally and exchanges updates through gossip synchronization using version-based conflict resolution.
This mode is considerably more experimental than the server mode and should be viewed as a proof of concept rather than a production-ready networking solution.
I included it because I wanted to explore what the architecture could look like without a central authority. Even if it is not the final answer for the future game, it was valuable to experiment with the idea and see how the system behaves when coordination is distributed more directly.
What DWCS Is
- An engine-agnostic backend.
- A distributed computation coordinator.
- A shared world synchronization system.
- A TCP + JSON protocol.
- A framework that leaves application logic to the developer.
- Open source under the GNU GPL v3 license.
What DWCS Is Not
- A game engine.
- A networking library tied to a specific engine.
- A rendering system.
- A physics engine.
- An anti-cheat solution.
- A persistence layer.
- A production-ready networking framework.
It intentionally solves one problem while leaving application-specific decisions to the developer.
That is important because I did not want to create another system that tries to do everything. I wanted something focused. Something that handles distributed computation and synchronization without pretending to be the entire game.
If a developer wants to use it, they still need to decide how their game logic works, how validation is handled, how persistence is stored, how security is enforced, and how the rest of the application is structured.
DWCS is only one piece of the puzzle.
Why Not Just Use a Traditional Server?
This is a fair question, and it is probably the first question many people will ask.
The answer is not that traditional servers are bad. They are not. Traditional server-authoritative architectures are common for a reason. They are understandable, well-tested, and often the right choice.
The reason I built DWCS is that I wanted to explore a different trade-off.
If the server performs all the computation, then the server load grows as the game grows. More players usually means more work. More work usually means more CPU, more memory, and more infrastructure cost.
That is fine for some projects, but not ideal for every project.
I wanted to see if I could design a backend where the server does less application-specific work and more coordination work. That way, the load can be distributed more intelligently across participants instead of forcing the server to carry everything.
This is especially relevant for large or dynamic worlds, where the amount of computation can become significant. If the backend can coordinate that work instead of owning all of it, then the system may scale in a more flexible way.
That was the main reason I decided to build this project in the first place.
Current State
This project should be considered experimental.
The centralized server mode has been tested locally during development and behaves as expected within those tests, but it has not been validated under real production workloads.
The peer-to-peer implementation is even earlier in its lifecycle. It demonstrates the intended architecture but has not been thoroughly tested under real-world networking conditions.
There are still many improvements that can be made, and I fully expect the design to evolve over time.
I want to be clear about that because I do not want the project to be misunderstood as a finished networking solution. It is a working prototype and an architectural experiment. It is meant to be explored, tested, criticized, and improved.
That is one of the reasons I chose to open source it now instead of waiting until the future game begins development.
Why Open Source It Now?
Because I'm not using it yet.
The game this backend was originally designed for is still a future project.
Rather than leaving the code private until that game eventually enters development, I would rather release it now, let people inspect the architecture, experiment with it, criticize it, improve it, or simply take ideas from it.
There is value in making the project public early.
If someone finds a flaw in the design, that is useful feedback.
If someone sees a better way to structure the synchronization model, that is useful feedback.
If someone wants to adapt the idea for their own project, that is also useful.
And if nobody uses it, that is still fine. At the very least, the ideas are documented and available instead of sitting unused in a private repository.
Since I am already working on similar projects and thinking about related systems, it made sense to release this one now rather than waiting for some future point that may be years away.
By the time I actually begin building the game, the project may have evolved through community feedback—or it may simply serve as a documented record of an interesting experiment.
Either outcome is valuable.
Why This Project Matters to Me
This project matters to me because it represents a design direction I have wanted to explore for a while.
I have been interested in systems where computation is not forced into one place by default. I wanted to see what happens when the backend becomes a coordinator instead of a heavy computation engine. I wanted to see whether a multiplayer architecture could be built in a way that gives the application more freedom while reducing unnecessary load on the server.
That is especially important for the kind of future game I have in mind.
A large open-world VR game can create a lot of pressure on both the client and the server. VR hardware has limits. Server infrastructure has costs. Multiplayer synchronization has complexity. If the architecture is not designed carefully, those pressures can become a problem very quickly.
DWCS is my attempt to explore a more flexible answer.
It is not a final solution to every multiplayer problem. It is not a replacement for every existing architecture. It is simply a project built around one idea: distribute the load, keep the backend focused, and let the application decide what computation belongs where.
Final Thoughts
This project is not trying to replace existing multiplayer architectures.
It is not claiming that traditional client-server models are wrong.
It is not saying that every game should distribute computation in the same way.
It is simply an exploration of a different division of responsibilities.
Can synchronization be treated as its own independent layer?
Can computation be distributed instead of centralized?
Can the backend coordinate work without needing to understand the meaning of the data?
Those questions led to this project.
The fact that the game itself has not started development yet is exactly why I decided to open source the backend now. It was already useful as an experiment, and I would rather share the ideas early than keep them hidden until some future release.
If nothing else, I hope it starts interesting discussions about different ways distributed systems for games can be designed.
If you are interested in multiplayer networking, distributed systems, backend architecture, or engine-agnostic design, I would love to hear your thoughts.
project link: https://github.com/ahadprogamer/DWCS
Top comments (0)