
Show HN: Unity MMORPG Boilerplate – Multiplayer in Unity Made Easy - valkyrienyanko
https://github.com/valkyrienyanko/Unity-MMORPG-Boilerplate
======
namelosw
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
> 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
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
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.

~~~
hinkley
What keeps the client from peeking at the next few values and scheduling
actions to line up with 'good rolls'?

~~~
shultays
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

It is better to keep clients dumb if possible

------
kevingadd
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
For unity users, "massive" means something like 64+ concurrent players.
Because that's the limit for (custom engine) triple-A productions like
Battlefield.

~~~
shultays
That sounds a very unimpressive amount to be called massive.

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

~~~
hnick
> 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!

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

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

~~~
NanoWar
Looks like a Dektop only version. Any plans for mobile?

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

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

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

~~~
dukodk
A good video of it from 2016
[https://youtu.be/x_4Y2-B-THo](https://youtu.be/x_4Y2-B-THo)

------
kevindeasis
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?

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

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

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

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

[https://www.lexaloffle.com/pico-8.php](https://www.lexaloffle.com/pico-8.php)

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

------
ReD_CoDE
What about these two? [1]
[https://github.com/ketoo/NoahGameFrame](https://github.com/ketoo/NoahGameFrame)
[2] [https://github.com/ocornut/imgui](https://github.com/ocornut/imgui) ,
[https://github.com/ocornut/imgui/issues/3075](https://github.com/ocornut/imgui/issues/3075)

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?

------
nallo
Started working on a text-based MMO a couple of weeks ago
[https://github.com/johlits/rpg](https://github.com/johlits/rpg)

I do authentication from another service and send encrypted commands to the
server which carries them out and encrypts the responses back.

Even for a text based game it is tough but I keep it simple as long as I can!

