Our experience building an MMO tech demo with Godot 4.4.1 (.NET/C#)
Hi everyone 
,
I am working for CipSoft, a game development studio from Germany with many years of experience building and operating online games. My task for the past few months was to evaluate several engines and networking approaches for MMO development, including Godot 4 (.NET/C#).
As part of this evaluation, we built a small but functional 3D MMO tech demo in Godot and created a short trailer that is linked below. We wanted to share our experience, especially from a networking and MMO perspective, in case it is useful to others.
Here’s the short video of our evaluation:
[Youtube]
What we built 
We created a simple third-person multiplayer tech demo.
- 3D world
- Third-person character controller
- Combat with projectiles
- AI enemies
- Respawning players and enemies
The client and server were exported from the same project using different presets.
For load testing, we launched multiple headless bot clients that connected automatically and simulated gameplay.
What we liked 
One of the first things we appreciated about Godot was how lightweight and accessible it is. There is no heavy installation process. You download it and can start working immediately. That simplicity makes it very easy to get going, especially when building prototypes.
The editor feels clean and well structured. After a short adjustment period, especially coming from Unity, the Scene and Node concept starts to make a lot of sense and encourages a modular way of thinking about game architecture. For everyday work, the workflow feels fast and responsive.
We also liked how straightforward it is to create dedicated server builds and run the engine in headless mode. For online games this is an important foundation, and in our experience it worked reliably.
Overall, Godot feels developer-friendly, open and refreshingly lightweight. It makes experimentation easy and allows for quick iteration, which we really value during early prototype phases.
What we found challenging 
From an MMO perspective, we ran into some limitations, mainly around networking and parts of the 3D toolchain.
When using the High Level Multiplayer API with ENet, things worked well for smaller multiplayer scenarios. However, during load testing at around 80 to 100 concurrent clients, we observed server CPU spikes followed by mass disconnects of all connected players. We documented the issue and discussion here:
For context, our server was running on a Linux virtual machine with 2 CPU cores and 2 GB of RAM. The bot clients were distributed across six separate Windows machines. The bots connected automatically, moved through the world, jumped, and engaged enemies in order to simulate real gameplay traffic rather than just idle connections.
With ENet, once we approached the connection threshold mentioned above, the server load increased sharply and eventually resulted in all clients being disconnected.
After investigating the behavior and not finding an acceptable solution, we replaced the High Level API with the Telepathy TCP library and implemented a more custom networking layer. With that setup, server stability under load improved significantly under the same hardware conditions. In this configuration, the bottleneck shifted to the client side, which for us was acceptable since the server remained stable and responsive.
The tradeoff is that this approach requires more custom architecture and shifts more responsibility to the developer instead of relying on engine-level abstractions.
Regarding the 3D toolchain, we noticed that certain workflows require additional external tools or plugins. For example, there is no built-in terrain editor in Godot 4, so creating larger landscapes requires using community add-ons such as Terrain3D.
Even some rendering defaults, such as shadow behavior, require manual adjustments to achieve production-quality results.
From a commercial game development perspective, we also felt that C# is not yet treated on the same level as GDScript within the engine tooling. Especially debugging and performance profiling are significantly better supported for GDScript.
The built in profiler only supports GDScript. When working with C#, profiling inside the engine is currently not available, which means relying on external tools for performance analysis.
Those tools are typically closed source and often expensive. For this evaluation, we did not want to purchase a full annual subscription for JetBrains Rider and JetBrains dotTrace, which is recommended. We used Visual Studio 2022 Professional, which we already have, but only for CPU profiling, since network profiling is not available there.
It is important to note that we did not heavily focus on network optimization during this evaluation. The tech demo was intentionally kept simple and close to default engine behavior in order to assess baseline performance. We did not implement advanced replication filtering, bandwidth optimization, custom prioritization strategies, or deeper architectural scaling approaches. With additional dedicated networking optimization, higher scalability may well be achievable.
Overall Conclusion 
Overall, our experience with Godot 4 was positive, especially in terms of usability, iteration speed and overall accessibility. The engine feels lightweight, modern and very approachable, which makes it great for rapid prototyping and smaller-scale multiplayer projects.
From a strict MMO perspective, particularly regarding high concurrency in a single world instance, we currently consider Godot’s networking, High Level Multiplayer API plus ENet, as insufficient. Achieving the level of stability we expect for large scale online games required moving to a more custom networking solution, which increases engineering effort.
That said, we are aware that Godot is evolving quickly. The pace of development and the openness of the ecosystem are impressive. Many of the areas we touched on may improve significantly in future versions.
We share this not as criticism, but as a transparent report from our evaluation process. If we overlooked something or there are approaches we should have considered, we would genuinely appreciate the discussion.
Thanks to everyone contributing to Godot and building such an ambitious open-source engine.