Netcode Architecture Decision for Physics-Based Movement FPS (GameObjects vs Full DOTS/Entities) — Seeking Guidance

News & General Discussion
, ,
1

Hey everyone,

I’m in early prototype stage for a multiplayer movement FPS with melee combat. The core movement system is already built and working with GameObjects — wall running, wall jumping, climbing, ledge grabbing, grappling, swinging, rail movement, and standard locomotion. Physics-based, and it’s feeling good so far.

Now I’m at the point where I need to make a foundational architecture decision before I go any further, and I want to get it right before I’m too deep to change course.

Target Platform: Mobile and PC
Target Player Count: 8+ players per session
Unity Version: 6.4

The Game at a Glance

  • Multiplayer movement FPS — fast, physics-driven locomotion is the core fantasy
  • Melee combat system — throwables, boomerang, parry, swords, daggers
  • Needs to handle high-frequency physics state sync (mid-air collisions, grapple swings, wall contacts) across players
  • Target: competitive multiplayer, so netcode quality is non-negotiable
  • Must run well on mobile hardware alongside PC — performance budget is tight

The Decision I’m Stuck On

Option A — GameObjects + Netcode for GameObjects

Keep my existing prototype as-is. Use NGO for networking. Familiar workflow, easier to iterate, most Unity learning resources apply directly.

Concern: Will NGO handle the volume and frequency of physics state updates this game demands without turning into a mess? Especially for things like grapple rope simulation, swinging arcs, and throwable weapon trajectories synced across clients. Also concerned about whether NGO can keep up cleanly at 8+ players with this movement frequency on mobile hardware.

Option B — Full DOTS/Entities + Netcode for Entities

Rebuild everything on ECS. Use Netcode for Entities, which is built on Unity Physics and seems purpose-designed for exactly this kind of high-frequency simulation sync.

Concern: Massive migration cost from my existing prototype. And I genuinely don’t know how to handle the parts that DOTS doesn’t cover cleanly — animation, VFX, character management. The development complexity also feels risky for a cross-platform mobile + PC target.

Option C — GameObjects + Netcode for Entities

Keep the GameObjects workflow for game logic, rendering, animation, and VFX — but use Netcode for Entities as the networking layer instead of NGO.

This is the option I’m most seriously considering, but also the one I’m least clear on technically. My understanding is that Netcode for Entities is designed around ECS architecture, so I’m not sure how well it actually plays with a pure GameObject setup. Is this even a viable combination, or is it trying to get the best of both worlds and ending up with the worst?

  • Can Netcode for Entities meaningfully sync GameObject-based physics without the underlying ECS simulation?
  • Is there a documented or community-validated pattern for this hybrid, or is it essentially unsupported territory?
  • Would I lose the core advantages of Netcode for Entities (deterministic physics, proper client prediction, rollback) if the simulation itself is still running on Rigidbodies?
  • How does this hold up specifically at 8+ players on a mobile + PC cross-platform target in Unity 6.4?

Specific Questions

1. Physics Approach

  • In the GameObject + NGO path: is Rigidbody + NGO’s state sync reliable enough for fast physics bodies (players mid-swing, throwables in arc) at 8+ players? Or will I be fighting desync constantly, especially on mobile where tick rates may need to be lower?
  • In the full DOTS path: Unity Physics is deterministic — does that actually solve the sync problem, or does it just move the complexity elsewhere? How do people handle client-side prediction + rollback for physics-heavy objects in Netcode for Entities?
  • In the GameObject + Netcode for Entities path: does the determinism and prediction advantage of NFE survive if the physics simulation underneath is still Rigidbody-based? Or is it effectively just NGO with extra steps at that point?

2. Visual Effects, Animation, and Character in Full DOTS

This is the part that worries me most about Option B. If fully committing to ECS:

  • How do people handle character animation? Is Animator still used on a separate GameObject that just reads from ECS state, or is there a cleaner pattern in Unity 6.4?
  • VFX Graph — does it work alongside DOTS entities without a hybrid workaround?
  • Character switching (players can potentially change character/loadout mid-session) — is this manageable in pure ECS or does it get messy fast?

3. Hybrid Viability at Scale

Is there a stable middle ground — whether that’s Option C or running game logic and physics in DOTS but keeping rendering and animation on GameObjects — that people are actually shipping with at 8+ players? Or does any hybrid approach create more problems than it solves, particularly on a cross-platform mobile + PC target?

What I’m Leaning Toward

Currently leaning toward Option C — GameObjects + Netcode for Entities. The reasoning:

  • My existing GameObject prototype is already working and I’d like to preserve that investment
  • The movement system involves enough physics complexity (grapple, swing, throwables, 8+ players simultaneously) that NGO’s sync model feels like it might not be the right fit
  • Animation, VFX, and character management staying in the GameObject world removes the biggest unknowns from Option B
  • Cross-platform mobile + PC makes the performance overhead of a full ECS migration harder to justify right now

But I genuinely don’t know if Option C is a real, supported architecture in Unity 6.4 or if I’m misreading what Netcode for Entities can do outside of a pure ECS context. That’s the core thing I need clarity on before I commit.

Any experience from people who’ve shipped or are actively building in this space — especially on mobile + PC cross-platform at this player count — would be really valuable.

Thanks in advance.

2

For PC sure. Mobile … not without a lot of faking. Latency and jitter (inconsistency of latency) are several factors greater on mobile.

Mobiles will also lose the session connection when a player moves the app to the background, so you got to work on that side of the infrastructure as well, ie reconnect behaviour. From what I know and read here, it’s a potentially huge time sink for a solo dev unless you take the easy way out: background means “you lose”. If the host backgrounds: “session ended” for everyone.

You would have to have a dedicated server for mobile players if you want to avoid the latter. Or Distributed Authority with host migration, though you have to expect a noticable hiccup during migration.

In short: Mobile just isn’t the platform for fast online multiplayer action games, especially not first/third person. The ones you do get to play are engineering marvels in disguise built by engineering teams who knew what they were up against, and they still would have to employ all sorts of trickery.

Speed is the wrong metric. For multiplayer physics you’re looking at a serious engineering challenge that NGO isn’t well-equipped for. I can’t speak for NfE personally but due to the fact that it’s deterministic it at least has the fundamental architecural requirement satisfied that physics-enabled multiplayer games require.

While you can sync physics with NGO it’s going to be janky. Distributed authority can help with that provided the physics are isolated to the player, ie their own grappling hook will work great, but two players hooking each other will be messy.

DA will simulate the physics locally thus it appears fine for the owner. Without DA all physics simulation runs entirely on the host/server machine, which adds to that machine’s load.

Also keep in mind that 8 physics objects plus 8 grappling hooks plus a few throwable physics objects is something even a mobile CPU laughs at, and the data this generates is likely less than 5 KiB per net tick (or ~150 KiB/s @ 30 Hz). Physics simulation and data aren’t going to be the problem, the latency will be.

Note that you will not sync the entire rope, that’s a local-only visual effect. What you need to sync is the rope’s end point ie a single object. Same for swinging. The player isn’t attached to the rope but located somewhere between start and end linearly even if that doesn’t match the rope sway perfectly. Or you simulate the rope sway with an algorithm and make the visuals match (again: locally, every client does that, whether the rope looks somewhat different between clients is irrelevant).

It moves the problem to each individual client. Though I don’t know if that’s the actual technical implementation, just the expectation. When physics is deterministic, you sync the full state and can apply the changes locally. Then you’d only need to sync up any unexpected deviation (ie prediction/rollback).

I can’t say anything about today’s NfE prediction/rollback feature though.

In that case you lose the ECS determinism. Rigidbody physics + NfE is simply a bad match with presumably no benefits and likely only drawbacks. So you can safely rule that out as a valid option.

There are ECS-enabled Animation assets on the store I believe. But yes, from what I understand you still have an Animator GameObject that responds to ECS world changes.

You still need to address VFX graphs with a MonoBehaviour. But other than that VFX Graph assets couldn’t care less about GO vs ECS or the net tech stack.

This really is just swapping out some data fields (the payload/equipment info) and synching the change visually ie updating Animator, Mesh, VFX, etc.

If you still work off the notion that changing character loadouts require a network character spawn/despawn of a separate network-synchronized prefab, reconsider: The player is an “empty shell” object with just the network data and sync logic. The visualization is a child object in the GameObject world, or different components in ECS. Either way, visuals just respond to the underlying data changes.

Networking games are event driven, data-crunching beasts first and foremost, where traffic is paramount. Every byte may count, especially on mobile. When you hit packet size limits (1.500 bytes roughly), fragmentation occurs. That’s 2+ packets possibly taking different routes through the Internet which can only start a client-side action when the receiving end got all packets, so the slowest packet determines the overall latency. This is particularly problematic on mobile due to the way mobile (over the air) networks work, and because the jitter is generally higher than on desktop.

So if you have preselected avatar choices, you’d really only send an RPC “change to avatar #7”. Same for individual equipment pieces ie the equipped weapon and armor and the inventory. You ought to have a shared library (ScriptableObject) using stable IDs where you can look up this index for an actual mesh or prefab. The UI, and the rendering basically just utilize the underlying game data to show what they need to show, and it updates either as a whole or for a specific thing based on an even raised via an incoming RPC, respectively it sends such an RPC.

Sending a single two-byte Int16 for indexes ought to be sufficient. You can also use a GUID (16 bytes) if the changes are rare and it eases the workflow (ie use Asset GUID but not as string, because then that’s 32 bytes).

You don’t want to despawn an entire character, save its state somewhere, and reinstate the character, with the whole inventory also synchronizing in full. That could easily be a thousand times more data to sync up.

So any architecture can handle this easily if it’s set up to handle it easily. You can also make it highly inefficient in any architecture. It’s really up to you, and you just started to scratch the surface here. :wink:

Analysis paralysis. You’re good to go with NGO for PC for the time being.

Because …

Yes, more problems than you bargained for.

I’d strongly recommend to develop for PC first and foremost and stick with NGO and publish. See if you can find success. It makes little sense to add 6+ months of development time for something that might not even find an audience. Or worse, when you find 95% of your audience is on PC and you wasted all that effort trying to make it work on mobile.

Alternatively, go mobile only but know it’s a significantly bigger challenge with longer turnaround times, just the build+deploy+run+profile/debug workflow compared to PC is crazy. And if you wanted to support both Android and iOS you’d also be switching between Windows and Mac computers. Mac => compile and deploy to iOS, or use Unity’s DevOps to create iOS builds, and wait a while longer for it to complete and download, then deploy to multiple devices for network play. Wheres on PC you can build, run and debug within a few seconds, and launch the same EXE multiple times locally.

If you do find success, you can make v2 and make that have a better multiplayer given all the things you’ve learned after the initial development. That’s the pragmatic, sane approach. :wink:

3

Thanks. That helped a lot :smiley: