I'm a web developer but I tried to understand how to build an MMORPG similar to World of Warcraft sometimes ago.
It turns out to build a solid solution that is largely overwhelming to individuals, and I yet to found an open-source framework that tackles these issues in a straightforward way.
To my shallow understanding, it's less about Unity, the game client, despite there are many protocol related works. Here are something I found really hard for me:
1. The first step is basically rebuilding all the game logic in the server-side, or you'll be facing endless cheating. The combat, the inventory, especially the map - you're going to model a huge 3D world on the server-side without existing client-side GUI helpers.
2. The most difficult thing is most of the states need to spread across the whole cluster like a distributed database, and keep sync because there might be interactions between those states (eg. shoot a fireball through the edge of the map to another map then hit someone), this usually done by modeling a quadtree across the cluster.
3. Players can randomly fight each other in an open world, and those combat needs to be dynamically grouped and disbanded. Players should only receive the state update they care about, instead of receiving every information of the world(area of interest), and everyone's interest might be different.
4. Of course, there are global clock and synchronization.
5. Many operations would require transactions, or players can trade and duplicate items when they cross the border of maps or directly disconnect.
> rebuilding all the game logic in the server-side
Start with the server side. This doesn't actually have to be a server application with no gui, but start with the simulation of an entire world. Then 'rebuild' the logic on the client side. This lets you be a little bit sloppy—though not too sloppy, obviously—because it's ok if the server 'cheats', since it has no ulterior motives (except for yours) and there's only one of it.
Real client-side verification and prediction is usually more complicated than just replicating game logic, you have to be able to restore the world to a correct condition after a wrong prediction in an elegant and unoffending way.
It depends on game/implementation but client wouldn't really roll dices on their sides. Someone shooting a bullet that does 5-10 damage would tell server to shoot bullet and server would reply "you did 7 damage"
Especially on an mmo, there is no point telling a player that his next fireball spell will also trigger a "random chance to put a burn status on target". The client would start casting a fireball, which takes a second to cast and in that 1 second duration the server would decide what is the damage and if the spell is going to apply burn and by end of 1 second, you would get that information so you can see the damage values and burn icon on enemy
Presumably nothing! But I imagine it was might have been impractical, given lockstep method is kind of predicated on "Do it because you can't afford to only compute and transmit from a central node."
In the era it was used, server chips weren't really a thing. So it was really just "the current decent CPU."
It's also a fascinating historical artifact of "when internet play meant orders of magnitude higher latency and jitter... as a base assumption."
Per memory, there's a bit where they've ferreted out all the sources of randomness, except one. And any source of randomness corrupted the downstream calculations, as they used global random generators.
There was some reason they couldn't just trace calls directly.
It turned out there was a line of code somewhere that said something like "if {rare condition} then rand.next {to figure out where to place an ornamental rock/tree}."
That was specifically related to their networking/syncing architecture -- deterministic lockstep simulation -- in which every client is running their own local instance of the simulation, and the only thing being passed around are interactions with the simulation.
So everyone has to have the same results and calculations at all times, because there's no authoritative simulation.
It's a common architecture for RTS's (interactions are far less numerous than individual entities) but not for general multiplayer games due to issues like everyone must be on the same timestep at all times -- so a single slow player slows everyone down. See https://gafferongames.com/post/deterministic_lockstep/
If you have an authoritative server, so the client is mostly a presentation/view of current game state, you don't need to be as careful about maintaining game state/randomness, since there's only one source of randomness (your authoritative server)
Ofc, if in an mmo you have multiple authoritative servers, you're back to the same problem, though I believe the more common solution is to have 1 server - 1 universe, and you just have more game instances (shards/servers) to connect to
There's a reason there were no complex-state MMOs at that time -- there simply wasn't the residential bandwidth to perform continual full state updates (latency aside).
E.g. grid & turn-based vs 3-D free-motion worlds
They say they specifically made the deterministic lockstep choice because it was the only option that (a) allowed the multiplayer gameplay they wanted and (b) fit within the computing and network resources of the time.
AoE uses classic lockstep simulation, as far as I remember. For a variety of reasons, most importantly, latency, this approach is not usable for genres other than strategy.
Right, so that's the challenging part about building a client. But you still want to build the server first, and let that be the authoritative source of gameplay design, because a desync for one person is not as bad as a desync for everyone but one person. (And that only becomes more true as the number of people on your server grows.)
note that in rpg you don't stimulate the physics. every tick of combat you send an effect packet that describe that turn action result and the client side plays whatever effect is needed
once a combat session is initiated you don't need that much prediction going on because where you move is uncorrelated to where a fireball hit or not, only player stats.
the real exception are are effect, as the client need to reconcile them, but the client can chat as much as it wants as long as the presentation matches the server player stats: it can for example position area effect that hit on the server in a position such as the player hit was in range.
the client only had to make sure action result are in sync, not the world physical station whole
That works for something like WoW, but there are exceptions: in EVE Online for example, damage depends heavily on the relative movement of player ships.
It's true for WoW, but many more modern MMORPGs have solid characters, attacks tied to animation (remember infamous Conan thing with female characters having lower DPS because of that), raycast hit mechanics, and yes, real physics.
Usually these mechanics are not as advanced and detailed as in single-player action games, but they do exist.
This isn’t just for MMO’s all multiplayer games today run everything on the server side the server side basically runs a client that is the single source of truth.
To improve the experience and compensate for lag player clients run a simulation and can update their state based on their player actions directly before the action is registered or acknowledged by the server client then they only get a confirmation from the server or they get a forced update if the action they performed wasn’t in agreement with the server.
As for other things like give mentioned you don’t usually have to run a full model on the server side of your world, you however hold a representation of it in the form of maps, these are usually huge arrays of coordinates with various properties they basically transform the 3D game world into a board game board.
As far as I know, MMO creators gave up and used static instances, which degrades most MMOs to multiple regular/non-massive multiplayer games stitched together.
Sadly true. There have been games with large, seamless, 3D worlds combined with multiplayer for a long time (late 90s at latest), but almost all new games use some combination zones (e.g. shared spaces, but broken up), or instances (spaces shared only with a small group), or phasing (spaces shared only when you're in a similar game state), or the Destiny-style "we'll have people show up whenever we feel like it" tech. That last one seems hugely popular these days, to the point it's showing up from the other direction -- other people showing up in your single player game.
I think it's because of a combination of technical difficulty and game design reasons dealing with overcrowding and camping and other bad behavior.
And I also think it's a total cop out and decimates any sense of "place" in these games, which I think is so important in games like these.
If anyone has examples of modern games that don't do most of these these things, I'd love to hear it. I'm not up on all of em, particularly the ones in the primarily Asian market.
Me too wondering if there are any games could have done it without phasing or any doing the equivalent.
It seems to be impossible to handle unlimited players that are crowded together, even despite all the design issues. Because the logic and synchronization could grow in superlinear complexities in those scenarios. Clustered states and dynamic instance provisioning could ease some degrees but that actually can only solve sublinear to linear complexity problems at most.
With that being said, I played the Elder Scrolls Online many years ago. There were definitely phasing mechanisms. But when it just came out, there were like one thousand users PVP in Cyrodiil. Compared to World of Warcraft which one hundred players AOE in a city could make the server crawling it's already pretty impressive to me. Not sure how they have done it.
EVE Online is still primarily one single shared environment, as far as I'm aware. They added instances for some content back in 2018 (from a quick Googling), but otherwise it's not sharded in any way, to my knowledge.
Eve has some advantages that let it avoid some problems. Space is split up into distinct solar systems with a "jump" required to transition from one to another, so a system can be controlled by a single process.
Within a system, your area of interest is always the grid you are in, which is equal for all players in that grid. "Grid" despite the name is a dynamic boundary that contains all nearby players that are likely to interact with each other. The game doesn't allow most cross-grid interactions, probably to make implementation much easier. I think they get away with this since solar systems are so large and you have to be relatively close to interact with anything.
Some of these designs became problematic.
Players can perform "grid-hacking" where they manipulate the shape and position of these grids so that they can suddenly cross a grid boundary to ambush or escape other players.
I haven't played in a while, so some of this might work differently now. The lack of server scalability within a system also causes time dilation, which besides making fights slower and boring also gives more people enough time to join and rejoin fights and cause more time dilation.
Since the "Massive" in MMORPG implies large scale, some things worth considering, plus some general thoughts:
* You checked in your .vs folder, my understanding is that it is the .suo equivalent and shouldn't be checked in.
* Pulling updates from the GitHub releases page will probably get your repository rate-limited if not taken down, you need to think carefully about how to scale that up.
* While the readme says it pulls updates from GitHub, I can't find any code that actually does it. As far as I can tell the Launcher folder is completely empty boilerplate.
* Using XAML for the launcher UI seems like it would negatively impact portability unless you're pairing it with something that supports Mac and Linux (I couldn't tell if you are). It would make a lot more sense to implement your launcher in Unity (as a separate executable) since the end-user already is using Unity.
* You appear to have checked in local copies of NuGet packages, which is a bad idea. You should gitignore that folder so developers' msbuild can restore the packages locally.
* It looks like you also checked in third-party Unity asset files? I'm not sure you should do that either.
* You appear to not be making use of indexes for many of your queries, for example:
var user = db.Users.ToList().Find(x => x.Name.Equals(name));
var user = db.Users.ToList().Find(x => x.Name.Equals(name));
It's even worse. This will literally retrieve all Users into memory and then iterate over it. Every time you want to find this single one.
Looks like the person who wrote it never actually wrote a single backend server using Entity Framework. It also does so synchronously, while async method is available. This means that this thread will be locked until it finishes this IO and won't be able to process anything else.
For unity users, "massive" means something like 64+ concurrent players. Because that's the limit for (custom engine) triple-A productions like Battlefield.
Many modern MMOs are instanced. Thousands in the world, but only a handful in each zone. So that does stretch the definition of massive a bit but it's how they cope.
I think FFXIV has a hard cap of around ~350 per zone, but you get some silly processing outcomes when everyone is in the same area (entities or attacks not being rendered, area of effect attacks randomly only hitting a portion of people within the target zone, etc).
I mean, most MMOs are only an illusion of MMO. You don't really play together with thousands of other players. Stuff like an auction house perhaps the only "massively multiplayer" part of the game, otherwise it is probably not much different a regular mp. Although numbers like 64 players is still above most multiplayer games support. MMOs get away with it by designing game in a way that minimizes the load on server and moving most stuff that should have been done on server to client side
You are right, definition of MMO is stretched quite a bit when you have such limitations. One could argue that counter strike is an MMO because you thousands of players are playing on same universe (I guess gun skins are the only real progress of the game :) ) and each server is an instance. I think calling something an MMO mostly depends on how well it is hiding that it is not really a MMO
350 sounds quite impressive. Looks like eve online handled 2,670 at some point: https://en.wikipedia.org/wiki/Bloodbath_of_B-R5RB . eve online slowdowns the server to a crawl when there are such large scale battles though
Just to add on to this: it doesn't often even make sense to have more people in one area even if your servers and net code could handle it fine. The players themselves will likely run into severe performance issues with too many people on screen. In an MMO you want player character models to be heavily customizable (costs lots of draw calls, but also effects budget), which means that the usual tricks for rendering lots of animated things on the screen don't work as well. As a result, basically every 3D MMO runs poorly if there are too many people in the area, even when the server runs fine. Some games will start just not drawing the models for other players. At that point it doesn't really matter if your game is instanced or not. You're still not going to be playing with thousands of players on the screen.
The funny thing is that the maximum number of people on the screen before performance issues really hasn't improved much in MMOs in 16+ years.
> The funny thing is that the maximum number of people on the screen before performance issues really hasn't improved much in MMOs in 16+ years.
They're probably pumping up the graphical effects and maintaining a stasis there. But there are also hard caps to how much data or how many position updates you want to be sending in packets before perceived latency degrades too.
FFXI in particular had a famous meme "PS2 limitations" where the game was being held back technically due to supporting the older platform, not to mention it was built with dial up internet in mind and a very low update rate. Many MMOs in general want to cast a wide net and will rarely improve to the point where players with older systems can't join in. That's for the sequel!
I don't think the network side is the issue in almost any MMO when it comes to the client. The amount of data that is sent and received is tiny. It's most likely the number of draw calls that is the performance bottleneck. A high end machine in 2018 can handle around 2000 draw calls per frame (remember, this has been single threaded until recently!). You could easily have a single draw call per player, sometimes even more. That alone could take a system to its knees in an MMO with lots of players.
You want to limit as much as possible what you share about all players, not just for performance but also for cheating reasons. Rule-of-thumb, any information that does not translate into something the player can perceive in his screen/audio for that frame, should not be sent in that frame.
The disadvantage of that is that you cannot do reliable client side prediction anymore, meaning you now need to send the full physics state instead of sending just an error correction signal.
Even then, if a server is even half full (1000+ players) the game becomes laggy for everyone. Furthermore, if you go into an area with hundreds of players, then the client can't actually render them all without huge performance issues. If you want to see this in action then go make an account in RS, play the tutorial and once you get to Lumbridge go to World 84 to the bank chest near the forge in Lumbridge. If you do it at European prime time and stand on the tile next to the bank chest then no other players will render on your screen. You'll still have a low frame rate though.
One MMO I played (Aion) was so bad at this that a prerequisite for open-world group PvP was to go into the settings and adjust the 'number of other players to render' slider down to 1. The fact that the game had a setting for this demonstrates that the developers had already resigned themselves to the fact that their engine couldn't actually handle high player counts. Under normal circumstances stuff was fine but once you had 1-2 dozen players running around, not so much.
In practice it wasn't utterly horrible to play this way, it was just very surreal to be running around engaging in combat with name-plates floating in the void.
This is standard though. You either suffer unplayable performance or you have a setting like that (eg Lineage 2 suffered from this - what many consider the predecessor to Aion). The main problem usually is the number of draw calls. Due to the customizability of players every player character is likely to have multiple draw calls. You can't batch them well either, because few of the players will likely have the same things on. This essentially means that every player is quite expensive to render. Hopefully dx12 and vulkan will improve this, because it should now be possible to do draw calls from multiple threads.
There are good solutions for combining multiple faraway players into one draw call. You first lod them and then copy them into the same vertex buffer using a compute shader. Afterwards, you can render something like 8 reduced poly players with the same performance as one full-poly player.
But, that method is difficult to get right in Unreal Engine and impossible to do with Unity. That's why you only see it in high end titles like Battlefield but not in any indie MMORPG.
> * Pulling updates from the GitHub releases page will probably get your repository rate-limited if not taken down, you need to think carefully about how to scale that up.
This is the default mechanism for electron apps to auto update, and I haven't heard any issues from it to do with rate limiting.
The purpose of this boilerplate is to make multiplayer in Unity a piece of cake, specifically for MMORPGs. The boilerplate consists of a launcher, a web server, a game server and a client. The idea is the user loads up the launcher, updates the client, launches the client, logs in to an account through the web server and then connects to the game server.
From what I've seen Unity (the client) can be ported to any device.
The launcher uses (Avalonia) which is cross-platform (Windows-Linux-MacOS), not sure about mobile though. Now that I think about it, I suppose there could be different ways to go about mobile and just avoid the launcher entirely.
I wonder if there really is that many people using Unity to build MMORPGs. Especially now that Unity has deprecated their only networking stack in favor of a (not yet existing) future replacement. But the Unity asset store is also full with MMORPG related things.
Albion Online is build with unity. It’s basically Eve Online in a fantasy more newbie friendly setting with league of lengends styles combat, ARPG styles solo PVE, 20 man raids, and, mining that’s actually fun.
Works pretty well, even in massive fights with hundreds of people involved. Frankly handles the MMO part of things better than most MMOs.
Yes, professionally I see a lot of commercial MMO projects targeting Unity as a client. It's network stack was never intended for MMOs anyway, it was always targeted for client-hosted session-based games with very limited scope.
The boilerplate uses ENet for the game server, I tried using Unity's networking solutions earlier but found out the hard way that those were really only mean't for P2P and LAN (imo).
ENet provides a middle line between reliable and unreliable packets making it perfect for MMORPGs. You want to send a packet that a player shot a bullet? Use reliable. You want to send position updates? Use unreliable.
How do you usually handle game state for online multiplayer games to avoid cheating? My background isn't on making games, but knowing more about this domain is something I'm curious about
I'm guessing you can use timestamp by having PlayerA and PlayerB send udp packets, but wouldn't that cause latency, even if you put the instance region zones close enough to both players? How about direct socket connection between PlayerA and PlayerB and sending some results to the backend, but how do you prevent cheating on the client side then?
This is a deep topic, and people write entire thesis papers on this topic. This is/was a major performance issue in Star Citizen for years.
Because cheating tends to be an outlier activity, some companies choose to invest more in identifying cheaters after the fact using pattern recognition and machine learning tools rather than outright prevention. Depends on if your game inherently resets between game loops (i.e. battle royale, deathmatch, MOBA, etc), or if you have a continuous persistent state that has to be kept stable (i.e. MMORPG).
Full security means validating every activity with a fully trusted server before broadcasting to other players. Full performance basically means full client trust, whatever the implementation ends up looking like.
There's a whole spectrum of solutions somewhere in the middle for most games.
It also completely depends on what kind of multiplayer game it is. If you're doing a simple turn-based card game, obviously you can run the entire game on the server, and have the clients just do input and display of the game state. If you're doing a fast-paced first-person-shooter, you need to run more logic on each game client and trust them more. Add a real-time physics engine and it gets even trickier, because now you need to make sure it's deterministic regardless of client hardware.
If you can solve the latter problem in a general way, you can easily build a company around it. There's already a bunch that do nothing but this. It's just a fundamentally hard problem because the speed of light is what it is, the distribution of computing hardware is what it is, and the distribution of players is what it is.
Depends on the game/cheat we are talking about really.
Some cheaters try to fool server/other clients. For example in a game of chess, a client can try to move his pawn like a queen. In this case a server would run the "game simulation" it self and would detect that the client is making an illegal move and a cheater. But this is not always possible/feasible. In an mmo for example it may not be feasible to run physics simulations on server and maybe a server can trust clients when they say "I moved from my old point A to new point B" but in reality there may be a wall in between point A and B
Not all cheats are about fooling the server. Some runs on entirely on cheater's side. A board game example would be battleships. A cheater can decide to "look" other side of the board and cheat by looking at opponent's ships. This kind of cheats are solved by only sharing necessary information with clients. For battleships, this would be server only responding the bombing coordinates a client sends and the answer would be a simple "hit/miss". Again, this is not always practical. In a game like counter strike, ideally you would share enemy positions only when they should be visible on someone's screen. But due to lag or not being able to detect this visibility information, a server can choose to always share this information and clients can cheat by presenting that information
A harder to catch cheat would be aim hack. In this case a cheater neither fooling the server or benefiting of an information it doesn't have. They usually catch these by checking programs that does this or via player reports or automated systems that catches players that are too good to be legit.
Any sensitive data (i.e. things you can cheat with) is generally server-authoritative. There are lots of tricks you can use for predicting/interpolating data to make up for the latency created by going from client -> server -> client
Edit: As cheschire said, it entirely depends on the type of game and what kind of actions the player is performing
Like with any Risk, the actions are: Prevent, Detect, Correct (and least used Transfer).
Rule of thumb that is used in banking, 'sanity check'. Cheap and effective way to see if the gains-number (e.g. xp/coin gain) is making sense. If a top player can make 100k per hour and you get a newbie making 500k/h, you better start reading logs/snooping. The value of equip when a player saves & exits would not be x100000 from the previous time he/she saved and exited (and other similar metrics).
It is an ongoing process to make and maintain a useful dashboard. Also (I've seen it happening in some MUDs), you start snooping random players at times (preferably ones with massive gains) and see what is what.
Imho the cheapest way is to detect and correct, not prevent cheating. Unless you have an army of devs scouring the internet looking for cheating solutions that can work out preventative methods.
The important two points are that the client must react immediately to a user's input, but at the same time the server has to have the authoritative game state.
One way of doing that is that the server runs the authoritative simulation and the clients send input to the server, but the clients also run their own simulations. In some games the client will try to predict what the server will do. If there's a conflict with what the client simulates compared to the server then the client gets rolled back to the server's state. This usually happens when there's a second player that interferes in some way.
I remember in World of Warcraft, your internet connection could drop completely and you wouldn't notice until you realized you hadn't seen mobs or another player for a while.
World of Warcraft is not fully server authoritative. There have been speedhacks going on. Also, an entire guild was banned once because they modified the client-side model files to remove the stairs in the dungeon, allowing them to fall down the pit and skip most of the dungeon.
I found this out recently when playing wow classic I somehow fell out of the sky, and survived when on a computer "controlled" Griffin, if I had any control of the bug I could use it to drop off in more convenient locations
I had that too, if taking the flight path from Goldshire to Stormwind and my game crashed/disconnected, I often found my character next to Stormwind gates.
While it's mostly about ensuring both clients have a smooth experience and how to achieve that (prediction, rollback, etc) many of the same techniques apply to cheat prevention - have the client "echo" or predict what it thinks will happen, but have the source of truth be the server. "Desync" is a common term for what happens when they disagree, the server keeps its version of events and kills the client connection. In peer-to-peer or direct connection games, one player is the server and this does present a problem, but keeping it random will reveal statistical irregularities.
In general, how it works depends on the cheat. You cannot stop someone running a program to automatically aim and shoot at enemies. The enemy data is in memory so pinpoint accuracy is simple to achieve. Usually, statistical analysis, recording, allowing an admin to view their screen, and other methods can be used. Often, anti-cheat software is installed to scan for known cheats or by using heuristics (much like anti-virus software). This is a bit of a hot topic right now as a recent game tried to install such a program in Ring 0 (lowest level device driver) in Windows, which runs at startup even if the game isn't running, and won't automatically uninstall. Some people reported it stopped their PC booting.
For informational cheats (such as seeing players through walls) that data is also in memory and is harder to detect if the player doesn't make any illogical plays taking advantage of it. You might ask why the client has player position data for people you can't see? That again depends, but IIRC in at least one case a game tried to suppress the information until just before they became visible but the cheaters realised that the game had to generate sound (footsteps) for the players and reverse engineered the directional sound back into positions.
In other cases, passing network data through a proxy defeats local anti-cheat. Packet scanning and direct injection can be used for superhuman speed (such as claiming unique monsters in an MMO before anyone else can).
In general, stopping cheats is largely impossible, it's more about how to catch them and policies to handle the fallout e.g. If I cheat and earn a bunch of ingame money then trade it to you, should you lose it? How do we know you're not an accomplice?
Staying on the "making games" domain, can anyone suggest some other simple way to create a game? I have done coding before, but never got engaged into making a game, I would accept any ideas for nature of games, anything between Shilla.org, flash games, anything that can be made and maintained by one person.
The best "easy to learn, hard to master" that I know of is PICO-8. You can get up and running with a simple game incredibly fast. The entire IDE/Engine is a single program. You write all code, draw all sprites/maps, compose all music/SFX, and play in one place. You will be surprised with what people who have mastered it can create.
Such a great way to test out some simple game mechanic ideas.
I'd been "planning on building a game" for probably a decade. Pico-8 got me to finally "finish" a few. The integrated graphics and audio system is super useful for cobbling something together.
Unity and Unreal Engine are the only realistic options for 99% of indie developers. Yes, you can technically program your own game engine, but if you are asking advice for simple ways to make games, that is not the best option for you right now. There is a lot of really good education content for those two game engines. Most importantly, people use them to make and sell games.
More important than any particular route you take is merely sticking with it. The choice of game engine doesn't matter that much as long as you make and finish games with that engine. Everything else is secondary and mostly procrastination.
Try GameMaker or Construct. They are the more intro level tools that will let you get things done without having to learn too much.
After there is the big engines, Unity, Unreal, and Godot. They all have their ups and downs, but are the next level of complexity up from the previously mentioned tools.
If you're into specific niches there are sometimes purpose built engines for it, like RPG Maker. They are usually much less complex, albeit limited to specific kinds of games.
Unity. Go download it and watch some tutorials on YouTube. I recommend someone like Brackeys. Pick a game making series and follow along. You'll very quickly get an understanding of how to do things and can go from there.
This is a popular enough way of doing it that it exists for most of the popular engines. Unity just tends to have the most.
There is the gamedev subreddit that contains plenty of helpful information and people.
Using a game engine like Unity you can create something pretty advances in a short time. There are tons of tutorials on YT.
If you prefer a free game engine, check out Godot.
If you're looking at doing it "from scratch", you should really consider starting out small with something like Pong or Tetris. The best resource I know is Handmade Hero for that, tons of YT videos and huge community.
Guys, don't forget Godot, you can choose unity or Godot for 2D games, Godot is the 3rd popular engine today, and will become more popular in the future.
Why almost all links are about years ago? Are not there any new technologies/methodologies for MMOGs that support 90fps, or even more?
Something hybrid which supports both server and client sides?
And mostly has developed for Unreal Engine or other well-known game engines?
It turns out to build a solid solution that is largely overwhelming to individuals, and I yet to found an open-source framework that tackles these issues in a straightforward way.
To my shallow understanding, it's less about Unity, the game client, despite there are many protocol related works. Here are something I found really hard for me:
1. The first step is basically rebuilding all the game logic in the server-side, or you'll be facing endless cheating. The combat, the inventory, especially the map - you're going to model a huge 3D world on the server-side without existing client-side GUI helpers.
2. The most difficult thing is most of the states need to spread across the whole cluster like a distributed database, and keep sync because there might be interactions between those states (eg. shoot a fireball through the edge of the map to another map then hit someone), this usually done by modeling a quadtree across the cluster.
3. Players can randomly fight each other in an open world, and those combat needs to be dynamically grouped and disbanded. Players should only receive the state update they care about, instead of receiving every information of the world(area of interest), and everyone's interest might be different.
4. Of course, there are global clock and synchronization.
5. Many operations would require transactions, or players can trade and duplicate items when they cross the border of maps or directly disconnect.