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