I was wondering if anyone tried this and if this is allowed (open source project)?
By seeing some questions about MMO games last few days i put myself to the test to try make a bare MMO in UE4.
For the login & world/realm list i created a custom online subsystem with IdentityInterface, SessionInterface (only able to browse/join sessions), TCP NetDriver & NetConnection which communicate with a boost asio tcp socket server for login and server list.
This was the easy part (no logic / database implemented atm, just dummy responses) and only Login/ServerBrowser slate screens in an empty startup map on the client.
Now comes the tricky part, the actual world server.
It’s probably not that hard to setup a simple socket communication between the external server and UE4 client, but on the server i want to be able to load the UE4 map and use RPC.
So i need to use parts of the engine for that …
I have researched this topic in deep, sadly there is none ready available solution that can be used. Not even a single post mention any success doing something similar.
But I have been thinking about creating a ue4 render window 1x1 pixel and then all the rendering is send to render target texture, and this texture is used to paint the external application. But I haven’t started anything yet.
You can’t ship anything that is using editor parts of the engine, but you can share the changes to other UE subscribers (typically via a github fork). Otherwise you can always fork and modify the engine itself and use your fork for shipping games, just remember that sharing code from the engine itself can be only shared with other UE subscribers. Plugins that build on top of the engine that are your own additions and can be shared more freely, e.g. on the marketplace.
Otherwise you need to shard. The main reason for this is that the bandwidth cost is exponential with the number of visible players. One way to mitigate this problem is to have logic to stop transmitting data when player’s can’t see/interact with other players, but even with that eventually you will hit a limit for a single server, so you shard to cover more players.
Classically sharding was done per ‘zone’ basis with a server for a region of about 100-200 players across zones (sometimes in busy zones, just one server per zone). In modern MMOs you can probably have a few more players per server, but the main difference is the need for seamless worlds and you can handle this with UE’s level streaming and have a small handoff region where it is connected to both servers.
So IMO the best approach for this would be to have a master custom server and then slave ue servers for regions with up to about 100 players. The master server could be a custom UDP socket server and it would do the hand-offs between slaves as players travel. You could even have this done in socket.io with a c++ client for each UE client and server, despite its javascript nature, it is very scalable and can handle 1000s of concurrent connections (drewww/socket.io-benchmarking @ GitHub).
In terms of the binding to UE, make a custom function library or component and consider having that master-slave network structured like a plugin, then you would use the functions exposed (e.g. to c++ or blueprint) to communicate with the master server as if it was another part of the engine. There shouldn’t be a need to actually modify the engine source with this approach.
Im not planning to schip it. Its more or less an experimental project cause its something that interest me. Before using UE i spend a lot of time writing a MMO server system. Master server, Char server, world server, clustered world node servers. Also experimenten with clusterer simulation servers running on physcX. Also made a test on Unity3D to connect the cliënt to the servers. My main issue there was RPC. I like UE much more and c++ is more stable as mono (seen many posts about people having crash issues with async sockets on Unity3D)
So if using parts of the Engine is allowed and possible, mainly being able to use RPC with custom sockets subsystem would be great.
About replicating to visible usere, thats the responsability of the server. When i tested with unity i only spawn mobs/Players on clients when near visible and de spawn again when out is range. Not only for bandwith but also performance.