Looking for Unreal Engine Devs — MMO Infrastructure Idea (Need Help Building It)

I’m going to be direct.

I’m not a senior Unreal engineer or backend architect.

I’m someone with an idea — and I want to see if there are developers here who think it’s worth turning into something real.


:light_bulb: The Idea (High-Level)

Building MMOs in Unreal Engine is still way harder than it should be.

Every team ends up rebuilding the same core systems:

  • Networking + replication systems
  • Backend infrastructure from scratch
  • Persistence and player state systems
  • Server scaling / sharding logic
  • Cross-world or multi-zone architecture
  • Inventory / progression frameworks

Even “standard” multiplayer games end up reinventing 80% of this.

So the idea is simple:

What if Unreal Engine had a reusable MMO infrastructure layer — like a modular SDK you plug into your game instead of building everything yourself?

Not a game framework.

Not a SaaS backend lock-in.

A developer-owned MMO foundation layer for Unreal Engine.


:gear: What This Could Become (If Done Right)

I’m not claiming this is the final design — this is the direction I’m trying to explore with people who actually know this space.

But imagine:

  • Plug-in backend architecture for Unreal Engine
  • Persistent world + player state system
  • Scalable server/zone framework
  • Optional cross-world systems (modular, not forced)
  • Standardized multiplayer architecture templates
  • Clean integration with UE5 replication / GAS / EOS if needed
  • Self-hosted or cloud-deployable backend services

Basically:

A starting point for MMOs instead of a blank slate every time.


:warning: Reality Check

To be clear:

  • I do NOT have a working system
  • I do NOT have a backend already built
  • I am NOT claiming this is technically solved

This is an early concept — and I fully expect experienced engineers will tear it apart, reshape it, or explain why parts of it don’t make sense.

That’s exactly what I want.


:fire: Who I’m Looking For

If you’ve ever worked on or near MMO systems, multiplayer architecture, or Unreal networking — I want your input.

Specifically:

  • Unreal Engine C++ developers (networking / replication)
  • Backend engineers (distributed systems, APIs, scaling)
  • MMO or large-scale multiplayer dev experience
  • DevOps / cloud infrastructure experience (optional but valuable)
  • Even people who have failed at building this kind of system

Honestly, I’m not looking for “idea agreement.”

I’m looking for people who can say:

“Here’s what actually works, and here’s what doesn’t.”


:high_voltage: Why This Might Be Worth Your Time

If something like this is even partially viable, it could become:

  • An open-source foundation for MMO development in Unreal
  • A shared infrastructure layer that multiple projects build on
  • A way to cut down years of backend duplication in game dev

Or it could turn into a learning experiment that documents how MMO systems actually should be structured.

Either way — it’s worth exploring.


:open_mailbox_with_raised_flag: If You’re Interested

Drop a reply or DM with:

  • Your Unreal / backend experience
  • Any multiplayer or networking systems you’ve worked on
  • Your honest take: is this idea completely unrealistic or worth exploring?

No fluff needed. Even a “this won’t work because X” is useful.


:brain: Final Note

I’m not trying to pitch a finished product.

I’m trying to find the people who immediately understand the problem space and think:

“Yeah… I’ve dealt with this before. This actually should exist.”

If that’s you — I’d love to talk.

:money_bag: Follow-Up: Player Subscription Model to Fund Infrastructure (Live Games)

One thing I want to add to the idea — and I’d really like feedback from people who’ve actually shipped online games — is a possible player-funded infrastructure model once a game is live.

The idea is simple:

Instead of studios fully front-loading server + backend + maintenance costs, the active player base subscribes, and those subscriptions directly fund the ongoing infrastructure and development costs of the world.


:puzzle_piece: How This Could Work (Conceptually)

Once a game is live and stable:

  • Players optionally subscribe (monthly or seasonal)
  • That subscription revenue is allocated toward:
    • Server infrastructure (compute, scaling, hosting)
    • Backend services (persistence, authentication, world state)
    • Ongoing maintenance and live ops
    • Possibly continued feature development

So instead of a fixed-cost model where the studio absorbs everything, it becomes:

“The world is funded by the people actively living in it.”


:video_game: Why This Idea Came Up

MMOs and large online games already kind of function like this indirectly:

  • Sub-based MMOs (like classic models)
  • Battle passes / seasonal monetization
  • Cosmetics funding live ops
  • DLC expansions funding continued development

This is just trying to formalize that into a direct infrastructure support system tied to actual runtime costs.


:warning: Important Reality Check (This Part Matters)

I’m not assuming this is viable — I know there are serious challenges:

  • Player willingness to pay ongoing subscriptions is unpredictable
  • Free-to-play expectations are dominant in many markets
  • Cost scaling might not align cleanly with player count
  • Risk of “paying for the right to access servers” perception issues
  • Requires extremely transparent value delivery

So this is very much an open question, not a proposal.


:handshake: What I’m Trying to Figure Out

I’d really like input from people who’ve worked on:

  • Live service games
  • MMO economies
  • Subscription vs F2P monetization systems
  • Backend cost scaling for multiplayer games

Specifically:

Has a “player-funded infrastructure pool” ever actually worked cleanly at scale?

Or is this just another version of existing subscription models under a different framing?


If nothing else, I’m trying to connect the technical side (MMO infrastructure SDK idea) with a realistic long-term funding model, and I don’t want to assume the wrong structure early.

Feedback appreciated — especially critical takes.

Hi @Enmity07. I read over the proposed MMO Infrastructure Idea. I had difficulty identifying what stands out in this “idea” compared to traditional MMO Infrastructure implementation. Please summarize.

Good question — let me clarify more concretely, because I don’t think I explained the distinction well enough.

The core idea is not that MMO architecture itself is new, but that there may be value in packaging and standardizing common MMO infrastructure patterns into a reusable Unreal Engine–native stack.

There are really three separate pieces I was trying to describe:

1. Unreal Engine integration layer (plugin)
A standardized UE plugin that provides consistent integration points for multiplayer games, such as:

  • replication pattern extensions / conventions
  • persistence and state sync hooks
  • session/world connection management
  • clean integration with backend services

The goal here is to reduce the amount of custom glue code every project writes for multiplayer systems.

2. Open, self-hostable backend infrastructure layer
A modular backend that provides the common services many multiplayer/MMO projects end up rebuilding:

  • player state persistence
  • world/session management
  • shard/zone or server instance orchestration
  • scaling hooks for running multiple servers/instances

The emphasis is not on inventing new MMO systems, but on making the “common 80%” reusable across projects instead of rebuilt each time.

3. Deployment + scaling model
A deployment approach where server capacity can scale dynamically based on active players, with costs more closely tied to actual usage rather than heavy upfront infrastructure investment.


One additional angle I’ve been considering is something closer to a “FiveM-like accessibility model,” but for Unreal Engine games and general multiplayer projects.

Not in the modding sense, but in the sense of:

  • making it easier to add persistent multiplayer to games that weren’t originally designed as full MMOs
  • enabling dedicated server-backed experiences without building full backend infrastructure from scratch
  • lowering the barrier for smaller teams to experiment with MMO-style systems

So overall, the main point is not “new MMO theory,” but whether there’s value in a reusable Unreal-native backend + plugin ecosystem that reduces how often teams have to rebuild the same infrastructure layers.

That’s what I’m trying to pressure-test with people who’ve actually built these systems before.

From what I understand, Iris is mainly focused on high-performance replication and networking inside Unreal Engine — basically optimizing how gameplay state is synchronized between server and clients. It doesn’t really cover the broader MMO backend needs like persistence, account systems, or world simulation.

While researching this, I came across Planetary Processing, which seems to go much further in that direction by handling persistent world state, backend simulation, and server orchestration.

That made me wonder if the two could actually work together: Planetary Processing as the backend/persistence and world simulation layer, and Unreal (with Iris) handling the real-time in-engine replication for active gameplay sessions.

If that separation of responsibilities is clean enough, it feels like they could complement each other rather than overlap. In fact, a partnership between Unreal and Planetary Processing would make a lot of sense conceptually for MMO-scale projects, since it would cover both the backend infrastructure and the high-performance in-engine networking side.

Building on the idea of Epic potentially collaborating with something like Planetary Processing, it’s interesting to think about where Epic could evolve the Unreal ecosystem itself if they ever wanted to natively support MMO-scale architecture.

Rather than trying to extend EOS or relying on Iris alone (which is primarily focused on high-performance replication within a single server instance), Epic would likely need to introduce a new foundational layer: a distributed, event-driven world simulation platform that sits above EOS and below gameplay.

This layer wouldn’t be about providing predefined MMO systems, but instead about standardizing how persistent worlds exist and scale. Things like persistent world state, event sourcing, dynamic authority (which server owns which entities), cross-server simulation, and automatic world partitioning would all live here. Game-specific logic would still be fully developer-defined through components and rules, but the backend would handle the complexity of distribution and persistence.

In that stack, EOS would remain focused on identity, social features, matchmaking, and discovery, while Iris would continue handling real-time replication and networking inside individual simulation servers. The missing piece is the global “world fabric” that connects all of it together.

Interestingly, Epic is already partially moving in this direction through UEFN. Fortnite Creative acts as a constrained but massively scalable world platform where Epic controls hosting, persistence, and orchestration. Features like the planned shared weak maps and broader shared-state systems hint at more advanced cross-session and cross-island persistence, which is essentially the early form of this kind of world-level state management.

So rather than a fully open MMO backend for all Unreal projects, Epic seems to be experimenting first inside their own ecosystem — building out Fortnite/UEFN as a proving ground for persistent, distributed world simulation. If those systems ever mature and generalize, they could represent the foundation of a much broader Unreal-native MMO backend layer in the future.