6 ms·

Since the "Massive" in MMORPG implies large scale, some things worth considering, plus some general thoughts: * You checked in your .vs folder, my understandin

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)); This will stop scaling almost instantly.

fxtentacle 6y ago
For unity users, "massive" means something like 64+ concurrent players. Because that's the limit for (custom engine) triple-A productions like Battlefield.
- deathgrips 6y ago
  Today I learned that Runescape is where the real men write backend game servers.
  - Mirioron 6y ago
    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.
    - kevingadd 6y ago
      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.
      - Mirioron 6y ago
        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.
        fxtentacle 6y ago
        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.
- shultays 6y ago
  That sounds a very unimpressive amount to be called massive.
  - 0xFF0123 6y ago
    If you share data about every player to every player, every frame (or tick) then it adds up pretty quickly.
    - Jare 6y ago
      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.
      - fxtentacle 6y ago
        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.
  - hnick 6y ago
    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).
    - Mirioron 6y ago
      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.
PudgePacket 6y ago
> * 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.
atraac 6y ago
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.

fxtentacle 6y ago

For unity users, "massive" means something like 64+ concurrent players. Because that's the limit for (custom engine) triple-A productions like Battlefield.

deathgrips 6y ago
Today I learned that Runescape is where the real men write backend game servers.
- Mirioron 6y ago
  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.
  - kevingadd 6y ago
    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.
    - Mirioron 6y ago
      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.
      - fxtentacle 6y ago
        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.
shultays 6y ago
That sounds a very unimpressive amount to be called massive.
- 0xFF0123 6y ago
  If you share data about every player to every player, every frame (or tick) then it adds up pretty quickly.
  - Jare 6y ago
    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.
    - fxtentacle 6y ago
      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.
- hnick 6y ago
  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).
  - Mirioron 6y ago
    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.

PudgePacket 6y ago

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

atraac 6y ago

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.