To contribute to the discussion on how well UE4 is suited for MMOs, I think it would be most accurate to say that UE4 is not inncompatible (so yes, compatible) with creating MMORPGs. However, what makes an MMO is that they are scalable to any number of players, and you will have to do a lot outside of UE4 to achieve that. Consider this: no one PC is strong enough to manage hundreds, let alone thousands of players in an interactive world. To host an MMO world, you must have the ability to have a group of computers working together to host what the player perceives as one world. Lets take World of Warcraft for example, they (like all MMOs) do all kinds of stuff to be able to split the task of hosting the game world:
- Spread the player base over what they call realms (also known as shards). These players can never interact.
- Spread the player base in one realm across different instances, you’ve got the different continents and all the dungeons. These players can never meet each other without a loading screen.
- Even the task of managing the same instance (like one seamless continent) is split up across different servers where each server is in charge of a different area
So you have groups of servers that host one realm, and within a group, the responsibility of handling one player’s game experience is constantly shifted from one server to another. The architecture for this is not something that UE4 provides, it would be way too specific towards MMOs. However, UE4 can still be useful for you in creating your MMO-like game. Here is how:
Option 1: Use UE4’s replication features. You can use UE4 as a game server that hosts a part of your game world and build something overarching that, when appropriate, sends the player to another server that is in charge of a different part of the world. In this case you would use UE4’s replication (multiplayer) features which will help you a lot in creating a synchronized multiplayer experience. you can use UE4 as game client as well, just connect it to the server as usual. You can see this as having a large multiplayer game, with the option to travel from server to server as part of the game. One downside here is: you cannot seamlessly connect to another server without loading screen.
Option 2: Do not use UE4’s replication features. You would use UE4 to simulate the game world, both on the server and client, but handle the synchronization yourself. So you make UE4 think its in a single player game, yet simulate all kinds of actors based on incoming custom network data so that it results in a multiplayer world. Why in heaven’s sake not use UE4’s replication you ask? Since in this way you can easily transfer a player’s connection from one server to another seamlessly (without loading screen). But underestimate this not, doing the networking yourself is a huge ton of work and you have to know very well beforehand what kinds of interactions you want in your game.
At any case developing an MMO is a huge commitment which I wouldn’t advise anyone unless the experience of attempting so would contribute to your studies or your desired profession, even if you fail. If you really have your mind set on making an MMO, go for it. I would advise going for option 1 first. Just make a big multiplayer game, say one that can support 64 players. add the option to transfer from server to server, while still part of the same game experience. Get an in-game chat working so that players can communicate even between separate instances (also requires networking outside of UE4!). If you can send a player from one server to another from within the game, you can send them to any server so by connecting servers to each other you have an MMO albeit with many loading screens. Keep your game worlds small, so that you don’t need to host an entire continent on one PC. Lastly, since you’re going to be an indie MMO developer, you need a community. Start a community fast and let these people help you by giving you feedback. It would be a real waste if all that effort goes into a game that no one is interested in. Good luck!
