5 ms·

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

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.

moonchild 6y ago
> 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.
- golergka 6y ago
  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.
  - ethbro 6y ago
    Per the infamous Age of Empires multiplayer write-up (I think?), never use independently random code. Everything should be key-based pseudorandom. Much easier to sync keys and play forward vs syncing at every Rand call.
    - jl258 6y ago
      What was this write up? This one? http://richg42.blogspot.com/2018/02/some-lessons-learned-while-developing.html http://richg42.blogspot.com/2018/02/some-lessons-learned-whi...
      - ethbro 6y ago
        It was linked to in that one. Pretty sure this is it: https://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php https://www.gamasutra.com/view/feature/131503/1500_archers_o... 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}."
        setr 6y ago
        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/ 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
jon_elbrook 6y ago
>It turns out to build a solid solution that is largely overwhelming to individuals, and I yet to found You need to proof your post.
- ccmcarey 6y ago
  There's no need for that.
dogma1138 6y ago
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. For MMO’s specifically while there aren’t many good open source frameworks there is something quite good and that is private server clients for popular MMO’s like Mangos https://github.com/mangoszero/server/blob/master/README.md https://github.com/mangoszero/server/blob/master/README.md
k__ 6y ago
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.
- boardwaalk 6y ago
  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.
  - daeken 6y ago
    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.
    - hinkley 6y ago
      I haven't looked in a long time, but EVE used to be sharded, which is easy to do when there are gateways between areas of the map. The problem was when everyone decides to hang out in one shard.
    - singron 6y ago
      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.

moonchild 6y ago

> 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.

golergka 6y ago
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.
- ethbro 6y ago
  Per the infamous Age of Empires multiplayer write-up (I think?), never use independently random code. Everything should be key-based pseudorandom. Much easier to sync keys and play forward vs syncing at every Rand call.
  - jl258 6y ago
    What was this write up? This one? http://richg42.blogspot.com/2018/02/some-lessons-learned-while-developing.html http://richg42.blogspot.com/2018/02/some-lessons-learned-whi...
    - ethbro 6y ago
      It was linked to in that one. Pretty sure this is it: https://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php https://www.gamasutra.com/view/feature/131503/1500_archers_o... 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}."
      - setr 6y ago
        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/ 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

jon_elbrook 6y ago

>It turns out to build a solid solution that is largely overwhelming to individuals, and I yet to found You need to proof your post.

ccmcarey 6y ago
There's no need for that.

dogma1138 6y ago

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. For MMO’s specifically while there aren’t many good open source frameworks there is something quite good and that is private server clients for popular MMO’s like Mangos https://github.com/mangoszero/server/blob/master/README.md https://github.com/mangoszero/server/blob/master/README.md

k__ 6y ago

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.

boardwaalk 6y ago
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.
- daeken 6y ago
  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.
  - hinkley 6y ago
    I haven't looked in a long time, but EVE used to be sharded, which is easy to do when there are gateways between areas of the map. The problem was when everyone decides to hang out in one shard.
  - singron 6y ago
    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.