DEV Community: Ahad pro Gamer

I Open-Sourced the Backend Before Building the Game

Ahad pro Gamer — Thu, 16 Jul 2026 10:54:19 +0000

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

Designing a Distributed Anti-Cheat Pipeline

Ahad pro Gamer — Fri, 10 Jul 2026 08:31:33 +0000

Every multiplayer game has to answer the same question:

How much should the client be trusted?

The answer is usually somewhere between "not at all" and "only when the server can verify it."

That approach has worked well for years, but while working on GameSecure I found myself asking a different question.

Instead of making either the client or the server responsible for every verification, could gameplay evidence be processed through an independent validation pipeline before the game decides how to respond?

That question led me to design the architecture below.

The diagram isn't meant to replace traditional anti-cheat techniques. Instead, it shows how gameplay verification can become a separate system that operates alongside the game itself.

The Client Doesn't Decide

From the player's perspective, nothing changes.

The player launches the game and connects to the multiplayer server as usual.

Behind the scenes, however, a lightweight SDK inside the client receives verification instructions from the game server.

Rather than embedding every verification rule directly into the game, the server can describe what information should be collected for the current session.

The SDK simply follows those instructions and produces a verification result.

At this point, no cheating decision has been made.

Only evidence has been collected.

Building a Verification Package

Once the server receives the SDK's response, it combines that information with additional session identifiers before creating a verification package.

The package contains everything required to verify a specific gameplay event while remaining tied to the correct player and match.

Instead of evaluating the package immediately, the server forwards it into an independent validation network.

The server's responsibility is to prepare the evidence—not to determine the outcome.

Independent Verification

Every verification package is processed by multiple validation nodes.

Each validator independently evaluates the task and produces its own result.

Because multiple validators examine the same package, the system is designed around agreement rather than a single authority.

The objective isn't to eliminate trust entirely, but to avoid depending on one machine to make every verification decision.

Returning Confidence Instead of Punishment

One design decision I intentionally made was separating verification from enforcement.

The validation network doesn't ban players.

It doesn't kick them from matches.

It doesn't decide moderation policy.

Instead, it returns a suspicion level that reflects how confidently the verification pipeline believes a gameplay event deserves attention.

What happens next is entirely controlled by the game developer.

One game might simply record the event for later review.

Another might increase monitoring.

Another could move the player into a separate matchmaking pool.

Others may choose temporary or permanent account actions.

The anti-cheat supplies evidence.

The game decides the response.

Why Separate Those Responsibilities?

I think anti-cheat systems often become tightly coupled with punishment systems.

Combining those responsibilities works, but it also means detection logic and moderation policy become intertwined.

Keeping them separate makes each component easier to reason about.

The verification pipeline focuses on producing reliable evidence.

The game focuses on deciding what should happen with that evidence.

Different games have different communities, different moderation standards, and different tolerances for false positives.

A single enforcement policy rarely fits every game.

Still an Ongoing Experiment

This architecture is still evolving.

Some components are already functioning, while others are still being refined as I continue experimenting with distributed validation, networking, and system design.

Whether this ultimately becomes a practical production solution remains an open question.

For me, that's part of what makes the project interesting.

Sometimes the most valuable software projects aren't the ones that immediately solve a problem—they're the ones that encourage you to question assumptions that have existed for years.

If you've worked on multiplayer networking, distributed systems, or game security, I'd be interested to hear how you would approach this problem differently.

Why I'm Building a Decentralized Anti-Cheat Instead of Another Plugin

Ahad pro Gamer — Sat, 27 Jun 2026 13:00:44 +0000

When most people think about anti-cheat, they think about kernel drivers, signature scanning, or server-side validation.

I started wondering about something different:

What if cheat detection itself wasn't trusted to a single machine?

That question eventually became a project I've been working on called GameSecure.

It's still very much a work in progress, but the architecture has been one of the most interesting engineering problems I've tackled.

The Problem

Traditional anti-cheat usually follows one of two approaches.

The client tries to detect cheating locally.

Or the server decides everything.

Both have strengths, but they also create single points of failure.

If the client is compromised, client-side checks become difficult to trust.

If the server has a bug, every decision is affected.

I wanted to explore another approach.

The Idea

Instead of making one machine responsible for deciding whether a player cheated, gameplay events are converted into validation tasks.

Those tasks are distributed across independent validator nodes.

Each validator analyzes the evidence.

Consensus determines the final verdict.

It's less about replacing existing anti-cheat techniques and more about distributing trust.

Why Go?

The entire project is written in Go.

Mostly because it gives me:

excellent concurrency
straightforward networking
simple deployment
good performance without excessive complexity

Since the project is heavily network-oriented, Go has been a good fit.

The Hard Part

The biggest challenge hasn't been writing detection rules.

It's designing a system that remains trustworthy even when some validators are malicious.

That leads into problems like:

reputation
consensus
collusion detection
replay protection
task distribution

It's interesting because the difficult problems aren't game-specific—they're distributed systems problems.

Current Status

The project is still under active development.

Some of the areas I'm currently working on include:

improving gameplay evidence collection
expanding validator logic
refining consensus
building better developer integration

There's still a long road ahead, but that's part of the fun.

Final Thoughts

Whether this architecture ultimately succeeds or fails, I've already learned far more about networking, distributed systems, and software architecture than I expected when I started.

Sometimes building an unusual project is valuable simply because of everything it teaches you along the way.

I'd love to hear from anyone who's worked on anti-cheat systems, distributed systems, or game networking.

What would you do differently?

Introducing OmniCore: A Neural Brain for Your Game’s NPCs

Ahad pro Gamer — Fri, 26 Jun 2026 13:43:16 +0000

Before this ever reaches a formal release, I want other game developers to put it through real conditions — not a polished trailer, not a curated showcase, but an honest stress test of what it can and can’t actually do inside a web build.

Below is an architectural breakdown of what the engine handles today, where its current limits are, and a link to play the live web sandbox to see the AI in motion.

What the Engine Actually Is
Stop relying on predictable state machines or massive, hard-coded logic loops that bog down your game loop. This project is a lightweight, external neural network engine designed to serve as an independent behavioral brain for game characters.

Instead of executing static scripts, the NPCs gain true multimodal agency — interpreting their surroundings, executing movement, and communicating dynamically based on game variables. The character isn’t following a decision tree you wrote six months ago; it’s making a fresh inference based on what’s actually happening in the world right now.

How It Works Under the Hood
Unlike standard local assets that add thousands of lines of code directly to your project, this operates as a dedicated API runtime. You integrate a lightweight wrapper into your game engine, which handles the secure connection between your game variables and the core neural network engine. Your project stays clean. The heavy lifting happens off to the side, freeing up local CPU cycles.

Three things are happening simultaneously:

Environmental perception: The game pipes spatial coordinate and entity data through the API. The core neural network processes this data to give the NPC an awareness of its surroundings, allowing it to track player positioning and navigate around obstacles in real time.

Dual-control navigation matrix: The character’s physical movement can be driven dynamically through custom backend scripts, or shifted on the fly to directly interpret and execute live player instructions.

Modular communication stack: The underlying engine can process inputs and return outputs flexibly depending on the game’s layout. It can parse text inputs to drive UI dialogue boxes, or process live player microphone audio to generate voice-to-voice loops.

What This Is Not (The Current Limitations)
I’d rather undersell this than oversell it, because the entire point of releasing this early prototype is to get honest technical feedback.

It is not a finished product. This is a raw prototype. Some things will break. Some dialogue will come out stranger than expected. Some edge cases in the physics setup will expose behavior I haven't seen yet.

It is not running on dedicated GPU clusters yet. The current build is validated on CPU-only hosting. This means response latency is a real, active area of tuning — not a solved problem. If you test this expecting console-AAA instant response times under heavy concurrent NPC load, you will quickly find the edges of what CPU inference can currently do.

Test the Live Prototype Now
I have embedded the early pipeline into a basic low-poly web sandbox so you can test the sync, latency, and movement routines directly in your browser.

I’m looking for eyes from other programmers to see how it holds up. Drop into the sandbox, try to throw unusual inputs at it, try to make the pathing fail, and let me know how it handles your commands!

👉 Play the Live AI Sandbox on itch.io