Senior Unreal Engine MMO Multiplayer & Dedicated-Server Architect

I am hiring one highly experienced Unreal Engine developer to build the production-quality Unreal client and dedicated-server foundation for a persistent PC MMO.

Goal

The finished platform must support at least 1,000,000 concurrent players in one shared persistent universe, distributed across many dedicated servers. One million is the minimum operating target, not the ceiling. The architecture must expand to tens of millions or more by adding servers, backend capacity, databases, and machines without rebuilding the Unreal multiplayer foundation.

This contract covers the Unreal client and game-server layer. Production accounts, databases, orchestration, and infrastructure will be operated locally and developed later. The Unreal systems must provide replaceable interfaces for them.

Environment and workload

* Unreal Engine 5.7 source build, PC
* C++ foundation; Blueprints where appropriate
* Headless, strictly authoritative dedicated servers
* Perforce, using a development stream of the real main project
* Initial target: at least 100 concurrent players per server, verified by profiling
* One developer; estimated 450–900 hours

World/server topology

The universe contains:

1. Open-space zones
2. Solar systems
3. Planetary-orbit regions
4. Planetary surface regions

Each is a logical region capable of being divided among multiple adjoining server subdivisions. A logical region, subdivision, running server process, and physical machine must be treated as separate concepts. Gameplay cannot permanently bind a region to one process, address, machine, or fixed server count.

Development and alpha will use only a few servers within each region type, but they must use the production-intended expandable structure. More regions and subdivisions must be addable through configuration as population or simulation load grows.

Required architecture

* No hard-coded global population, region, subdivision, or server limit
* No assumption that one region always uses one server
* Stable global IDs for players and persistent entities across servers and restarts
* No permanent data existing only inside a map or server process
* No single game-server process coordinating the entire universe
* No requirement for every server to communicate directly with every other server
* No hard-coded addresses or machine assignments
* Versioned player/world data suitable for future migrations
* Spatial relevancy and interest management so clients receive only nearby/relevant state
* Configurable replication and server capacities
* Servers authoritative over spawning, movement, inventory, currency, progression, ownership, travel, and other important outcomes
* Persistent regions capable of saving, restoring, restarting, and continuing simulation while empty, subject to future optimization

Travel and handoff

Players must travel between subdivisions of the same region and through this hierarchy:

Planetary surface → orbit → solar system → open space → another solar system.

Controlled loading or reconnect handoffs are acceptable. Every transfer must preserve the same player and character identity and authorized test data, including location, inventory, progression, ownership, faction, and currency.

The system must prevent duplicate characters, lost data, conflicting server ownership, rollback exploits, and simultaneous activity on two servers. It must safely handle retries, timeouts, disconnects, crashes, and unavailable destinations, then reconnect players to the correct region and subdivision.

Define how NPCs, vehicles, possessions, and other authorized persistent entities cross boundaries when required, and how visibility, interaction, movement, combat, and authority operate near boundaries.

Future-backend interfaces

Provide documented, replaceable interfaces for:

* Authentication, accounts, and character identity
* Player and world persistence
* Server registry, discovery, assignment, capacity, and health
* Region/subdivision configuration and orchestration
* Transfer authorization and reconnection routing
* Global factions, ownership, economy, communication, and world events
* Administration, monitoring, and logging

Temporary Unreal-only services may be used for alpha, but gameplay cannot depend directly on them. Identify every temporary component and explain exactly how the future backend replaces it.

Pre-implementation design

Before major implementation, submit an architecture for approval explaining:

1. Client, game-server, and future-backend responsibilities.
2. The four region types and their multi-server subdivisions.
3. Boundaries, entity authority, travel, transfer, reconnection, and failure recovery.
4. Data-loss and duplication prevention.
5. Adding regions, subdivisions, processes, and machines.
6. Handling overcrowded areas and population surges.
7. Scaling from 1 million to tens of millions of concurrent players.
8. Temporary alpha systems, backend integration points, risks, limitations, and unproven assumptions.

Capacity plan

Profile one server and document safe player capacity, CPU, memory, bandwidth, and simulation assumptions. Estimate game-server and infrastructure requirements at 1 million, 10 million, and 50 million concurrent players, including reserve capacity for failures, maintenance, surges, and uneven populations.

Identify bottlenecks, Unreal limitations, overcrowding strategy, and how each bottleneck can be partitioned, expanded, replicated, or replaced. Capacity must be retested as AI, vehicles, combat, and world complexity are added.

For planning only, 100 players per server would require about 10,000 active servers for 1 million players, 100,000 for 10 million, and 500,000 for 50 million. Actual capacity must be established through profiling.

Required alpha demonstration

* Packaged clients and headless servers operating outside the Editor
* Representative open-space, solar-system, orbital, and planetary regions
* Multiple server processes within representative logical regions
* Travel through all region types and between subdivisions of one region
* Identity and test data preserved through every transfer
* Recovery from an interrupted transfer and unavailable destination
* Reconnection to the correct subdivision after closing the client
* Protection against character/inventory duplication
* Server restart without permanent loss of test data
* New region or subdivision added through configuration without rewriting gameplay
* Clear connection, assignment, transfer, save, failure, disconnect, and reconnect logs
* Automated simulated clients where practical, load testing, and profiling results

Deliverables

* Approved architecture and capacity plans
* Complete C++ source, required Blueprints, server targets, and build configuration
* Configurable region/subdivision system
* Multi-server connection, travel, retry, recovery, and duplicate-prevention systems
* Temporary persistence and backend interfaces
* Packaged client/server builds and practical automated tests
* Profiling and load-test results
* Setup, build, launch, test, maintenance, and handover documentation
* Known limitations, temporary components, and future-backend requirements
* All files submitted to Perforce in frequent, clearly described changelists

Acceptance

The work is not accepted merely because a small test works or is called scalable. Acceptance requires packaged multi-server demonstrations, reliable travel and recovery, preserved identity/data, configurable expansion, profiling, documentation, and clean backend interfaces.

The Unreal-only phase cannot prove million-player operation without the production backend and infrastructure. It must demonstrate a credible route to 1 million, expansion to tens of millions, and no known fixed global ceiling requiring reconstruction.

Out of scope unless separately approved: production backend/databases, infrastructure/orchestration, final gameplay/combat/AI/art, production anti-cheat, final economy/chat, live operations, million-player deployment, and full-scale load testing.

Required experience

Advanced Unreal C++, dedicated servers, authoritative networking, replication/relevancy, multi-server architecture, cross-process player handoff, persistent identity, failure recovery, backend-interface design, load testing, Perforce, and technical documentation. MMO or distributed-game experience is strongly preferred.

When applying, answer:

1. What comparable production systems have you personally built?
2. Have you implemented player handoff or divided one logical region among multiple servers?
3. How would you structure these four region types and their boundaries?
4. How would you prevent duplication/data loss and separate Unreal from the future backend?
5. How would this expand from 1 million to tens of millions?
6. What cannot be proven until the backend exists, and what Unreal risks do you anticipate?
7. Provide estimated hours, milestones, rate, availability, portfolio evidence, and references.

Ordinary lobby multiplayer, listen-server, basic-replication, or Blueprint-only experience is insufficient.