Cheat-Proof Multiplayer for Godot and other engines. Zero DevOps Required.
MultiplayerNode
Write your server authority in pure GDScript. Click deploy. We handle the rest. Flawless HTML5 web exports, seamless desktop and mobile cross-play, and high-performance routing for high-entity .io , Survivor-Likes, or any multiplayer game.
Join the Closed Alpha Waitlist
Why Choose Us
Native Optimizations Syncing thousands of entities can crush your server and bandwidth. We combine native Area of Interest with automatic Delta Compression, sending only the exact state changes to the players who actually need to see them.
Pure GDScript Stop hacking enterprise C# libraries to fit your engine. Write your Authority logic natively, click "Deploy" from the editor, and we instantly spin up your headless servers in the cloud.
No Success Penalties Scared of bandwidth bills if your game goes viral? We will charge a flat monthly rate based on Concurrent Users (CCU). No hidden compute minutes. No surprise egress fees.
(ViVa Games has been developing Kakele MMORPG for years)
Combining the best of MMOs and Big Tech
We are two lead developers who previously worked at Google on large-scale distributed systems. For the last six years, we've also run the battle-tested, high-performance C++ networking architecture behind Kakele MMORPG. We are building MultiplayerNode to bring that combined engineering expertise directly to you, so you can stop wrestling with networking and start building your game.
Infrastructure You Can Trust at Scale
Your players don't care about your backend; they care that their shots land, the world doesn't lag and their connection doesn't drop. Our solution combines native Area of Interest with automatic Delta Compression, sending only the changes to players that actually need to see them. When input is involved, the Client-Side Prediction guarantees no delays. We've spent our careers solving those problems, from core big tech infrastructure to the open-world performance demands of a live MMORPG.
(In Kakele, it can easily reach hundreds of players onscreen at the same time, and gameplay is still smooth)
How It Works
Step ①
Native Integration
You drop the MultiplayerNode plugin into your Godot project. You set up the params for State Syncs and implement optional functions for network Game Events. No proprietary SDKs, just pure GDScript. No need for previous Godot multiplayer knowledge either.
Step ②
One-Click Deploy
When you hit deploy, our MultiplayerNode plugin automatically packages your Godot build and pushes it to our cloud registry. This is a headless build, and it acts as the Authority, which controls any critical logic for your game.
Step ③
Edge Orchestration
When you are ready launch, our infrastructure spins up your code on our virtual machines. We handle the DevOps, including: certificates, servers, uptime, routing the connections and manage everything else.
Multiplayer Shouldn't Be Hard
Frequently Asked Questions
Not at all. That is the entire point of MultiplayerNode. We are building a custom Godot Editor plugin that will add a "Deploy" button directly into your engine. When you click it, we will automatically export your headless server build, containerize it, and deploy it to our VMs. You will just write game code.
Yes. Getting secure WebSockets (wss://) working in Godot web exports is hard, so our C++ Relay is designed to handle all SSL termination for you. You will just connect your peer, and it will work flawlessly in the browser.
No. You can still use standard @rpc annotations or our upcoming drop-in MultiplayerNodeEntity node. You can write server authority in pure GDScript, just like you would for a local network game.
If you have 5,000 zombies on a map, a player only needs to know about the 50 that are currently on their screen. Instead of forcing your Godot server to calculate and broadcast all 5,000, our lightweight MultiplayerNodeSync node will pass spatial data to our C++ Relay. The Relay will perform the spatial hashing in microseconds and only route updates to players within the radius.
This will be a fully authoritative Dedicated Server architecture. Your server logic will run securely in a headless Godot instance in our cloud, meaning clients won't be able to cheat by altering their local game state.
Absolutely. You will be able to use a free development instance and connect your client instances to it. You will only hit the "Deploy" button when you are ready to push your build to the live servers.
We hate AWS-style egress bills as much as you do. We plan to charge a flat monthly rate based entirely on your Peak Concurrent Users (CCU). There will be no hidden fees for compute minutes, CPU spikes, or bandwidth usage. If your game goes viral, you won't wake up to a surprise bill. There will be a generous cap on bandwidth, and we will monitor that cap and adjust your max CCU if you go over the limit. We will let you know when that happens, so that you can either optimize your game or buy bandwidth credits.
Our infrastructure is being built to scale automatically. When a room fills up or a new server instance is requested, our edge orchestration will spin up a new Docker container with your Godot headless build in seconds. We can talk about more concepts, such as server topology, so that you can understand better what the limits of your game will be.
Zero C++ knowledge will be required. We are building our high-performance relay in C++ (based on the battle-tested architecture of Kakele MMORPG), but you will interact with it entirely through pure GDScript and our Editor plugin and nodes.
MultiplayerNode is being built exclusively for Godot 4.x, taking full advantage of the modern High-Level Multiplayer API. For the alpha, we will support GDScript out of the box (C# support is on the roadmap).
We will! However, we are focusing 100% on Godot 4 at the moment. Trying to build a "one-size-fits-all" SDK for every engine usually ruins the developer experience. We want to deliver a flawless, "Zero DevOps" workflow for Godot developers first, and if enough developers adopt our stack, we will definitely expand to other engines.
We chose Secure WebSockets (wss://) over UDP for two massive reasons: seamless HTML5 cross-play and flawless firewall traversal. WebRTC (the browser equivalent of UDP) requires complex signaling servers and often fails on strict school or corporate networks. By using highly optimized WebSockets paired with our custom binary schema, we will keep payload sizes microscopic. For MMORPGs, Survivors-likes, and co-op RPGs, this will deliver near-UDP latency while guaranteeing your game runs instantly anywhere, from a web browser to a desktop, without any complicated setup.
No. Because for the majority of modern multiplayer games, UDP is overkill. The industry dogma that "TCP is too slow for games" needs to be myth-busted. If you are a AAA studio that can afford multiple senior network experts, UDP can give you an extra benefit for twitch-based shooters. But we believe that for MultiplayerNode and the developers we serve, the negatives (DDoS vulnerabilities, firewall blocking, and immense cognitive and engineering overhead) greatly outweigh the positives. We will be writing in-depth dev blogs covering the exact math and architecture behind this decision eventually.
No, Kakele's client was built using a different engine. However, our studio is officially transitioning to Godot 4 for all of our upcoming multiplayer titles. When we started, we realized Godot needed a highly scalable, zero-DevOps server architecture for the ambitious games we want to make. So, we took the battle-tested C++ server code that currently handles thousands of Kakele players and rebuilt it specifically to interface natively with Godot's High-Level Multiplayer API. We are building MultiplayerNode because it is exactly what we need for our own future games.
