here is very interresting quote from UE4 forum
I'm sorry for the slow reply. We aren't planning to move the Atlas MMO framework to UE4. We are incrementally improving parts of UE4 related to networking, large world support, server performance, etc, to better server MMOs and games with MMO-like elements. For past MMOs built with Unreal Engine 2, 3, and 4, teams have generally used one of two approaches:
- Implementing a completely custom MMO back-end framework handling all gameplay logic including object movement, and interfacing it with UE through networking: The client purely runs in UE, and the server purely runs outside of UE, and they are coordinated through a custom networking layer using either UDP or TCP. This approach is generally best for MMOs looking to support thousands of players per server, where UE's high-precision approach to player movement and collision are overly-expensive compared to tile maps and other simplified techniques.
- Using UE's built-in functionality for implementing both the client and server components of an MMO, and extending the networking and level streaming code to support new features such as simultaneous connections to multiple servers responsible for separate streaming levels, and coordination between servers to allow seamless movement of actors between them.
NCSoft took approach 1 with Lineage 2 and various other projects, while Sigil Games took approach 2 with Vanguard. For a small project, I'd recommend approach 2, as it's easy to get up and running in a prototype prior to making engine-level improvements needed for scalability.
Lineage 2 is quietly old game. Does anyone know what approach is used in new mmorpgs designed to have thousand of players on one server? Is it still best to handle "everything" on server side because as in the quote the physics etc. interaction is very costly when there is many players?