Hello and welcome to this session,
where we'll be talking about multiplayer games.
We'll cover the netcode options,
what a matchmaker is, and what it does,
what to consider when thinking about where to host your game,
and how to keep your players communicating in-game.
♪ [MUSIC] ♪
My name is Arturo, and I'm a Developer Advocate
for Operate Solutions at Unity.
Please feel free to reach out to me if you have any questions
about these or want to chat about anything related to Unity.
Today, we're going to talk about multiplayer games,
more specifically, about the pieces that allow you
as game creators, to develop and operate
live multiplayer games.
The ultimate goal for this presentation
is that if you're thinking about making a multiplayer game
or are looking for solutions to successfully operate it,
you have guidance on key parts of the process.
You'll learn the key components of operating a multiplayer game,
and also get some inspiration by successful multiplayer games
operated using Unity's solutions.
This will be a short session, and the agenda is concise too.
We'll be discussing netcode, matchmaking,
game server hosting, and in-game communications.
You might be wondering, why making a multiplayer game?
To start, because in 2020,
the most successful games are games that are multiplayer.
You can see
and by successful we mean
by the number of players, but also by the revenue.
Take a look at this report. Most of the games
that you see there have a multiplayer component,
and a lot of them are just over the network multiplayer games.
Is it more challenging to develop and operate
a multiplayer game than a single-player game?
I would say that yes, it is.
You'll have to do all that a single-player game does,
but also make sure that several players can share an experience.
It is more difficult, yes, but is not rocket science.
And we have seen a lot of growth
on the number of multiplayer games across all the segments.
Let's walk through the key components and technologies
available to make, create, and operate
over the network multiplayer games.
The first thing that comes to mind
when thinking about making a multiplayer game
is how we're going to make the game to connect
and to talk between each other,
the multiple instances of our game.
Basically, we need to allow the transfer of data
between the different instances, so different players,
different instances of people playing,
and think about what objects we need to synchronize,
how we're going to deal with network latency,
how we're going to scale, how we're going to prevent cheating, etc.
We know there's a lot of passion and interest in this topic,
so we have an entire session by Brandi House
dedicated just to it,
however, I can share that
it is key to find the right solution
for the specific genre that you're developing for.
For instance, a first-person shooter game
that is running on a dedicated game server
with server authority for preventing cheating,
so let's say,
will have a completely different netcode requirement
than a MOBA running on a P2P topology
with deterministic rollback for cheat mitigation,
in this case, like
While we are still working on shipping
a first-party netcode solution
to contribute to the ecosystem,
there are multiple solutions in the market,
thanks to the talent of Unity's open-source community,
as well as our partners.
I will recommend that you check this blog post
and the PDF for more information,
there is the link down below,
if you're, of course, using Unity.
Long story short, the step one to start working on a multiplayer game
is to evaluate and implement the netcode options
that can solve the problem for your specific genre,
see which one is the best fit for what you're trying to achieve.
If you're using another engine,
take a look at the solutions offered for those other engines.
Are you playing
and having a lot of fun here,
and
Okay, talking about matchmaking.
We have created a game
that can host multiple players at the same time.
We need players. We assume
that we are not talking about getting new players,
we already have players, but we want
to put our players against each other.
This is where the matchmaker service kicks in.
By the way, the matchmaker usually is not tied to any netcode solution
or any engine in particular,
so you can use it with your preferred toolset.
Back to matchmaking, in a nutshell, the job of the matchmaker
is to take the pool of players
and help them find a good group to play with.
You connect them, and they can start having fun.
The challenge here is to define what "good" really means,
and it really varies depending on the game.
Think about this: the better the quality of the matches,
the more fun your players will have
and the more likely they will be to keep playing.
Again, I insist, we need to think about what good really means.
And since there's no easy answer, it is important to think about
the matchmaking problem as a game design problem
and not a technical one,
and this will be important later when we choose which service
or which solution to use for our game.
Do you want to match players with similar character evolution patterns?
Do you want to match people who are in the same geographical region?
Do you want to match someone
to an easy match to keep them more engaged?
Or all of the above?
That's why it's important to choose the right tools for these,
because flexibility in the case of matchmaking is key
since you might be taking many iterations to get it right.
What data points should you bring into consideration
when designing these functions to assemble the groups?
Well, this list is not comprehensive
because it depends on the platform, the genre, etc,
but you can start thinking about things, such as
the player skill;
the ping they have to a particular server location;
the geographical distribution of the players;
the players' win streaks, if someone is already winning a lot
or if they are losing a lot, things like that;
the reputation of the player is also important;
the inventory they might have at any point in their journey;
their level; and also the waiting times.
And up until this point, I hope that you're now thinking
of what other data points you would use
in your game to assemble these matches.
Remember that ideally this is a game design problem
and not a technical one.
Even small mismatches have the potential
to upset the game experience and to just frustrate the players,
and the more complex the games become,
with more skills, equipment,
the more complex the matchmaking process is,
and the result is more critical to get a match right.
The matchmaker server can also be different
from the actual servers hosting the game.
After we have the groups ready to start playing,
we need to request to basically start a match,
so players can start playing together.
The better the matches, the better the experience
and more likely your players will enjoy the game,
stay longer, and hopefully bring new players to the game.
Here's a question for you: Have you been playing
Rogue Company
I have been playing on my Switch and having a lot of fun,
it's great.
They're using Unity's multiplayer architecture to host the game.
Now talking about game server hosting.
There are multiple stories out there
of how games went viral overnight
and jumped to millions of concurrent users
in just a matter of hours.
In the best-case scenario
these games already had a great backend infrastructure,
and could keep up with the demand.
But there are cases where the underlying
infrastructure of the game simply could not hold
to the demand of too many concurrent users,
and people simply gave up trying and left the game.
And it's nearly impossible to assess the impact of this.
You don't want to lose players just because the backend didn't scale
or was not up to the job.
Game server hosting is a pretty complex topic,
and we're just going to focus on the things
that you should be considering when thinking about the solution
for hosting your games.
Remember that we are making games,
not backend and server hosting solutions,
so you should be focusing on creating great gameplay experiences
that your players love and have fun with,
as this quote from Gordon B. Hinckley highlights nicely:
"You cannot have a great building on a weak foundation,"
and it makes a lot of sense.
When choosing the architecture and the approach for hosting your game,
you consider the following:
Does it scale, either up and down?
If more people are joining your game, you want to scale up,
but if at some point during the day they stop playing,
are you able to scale down?
Or is your server service is able to scale down?
Also think about the performance and, again,
this comes with other things to consider
and other solutions and architectures,
but think about the performance.
Also, about the support, whether you're using a third-party service
or you're doing this in-house,
how is the support going to be for the hosting?
Is the platform that you're targeting proven?
Do they have some track records of doing this great?
How reliable it is?
Basically, you want your game to be available 24/7.
Also, the monitoring tools, do you have the right tools
to monitor how the game's doing, etc.?
One important thing is the cost.
The operating system, the hardware, all these things are important.
Also, how easy is it going to be to roll out updates?
How much help is the vendor going to provide you?
Again, if the vendor knows about the game industry,
and if they have a good track record.
There are many ways to tackle the challenge of game server hosting.
Ultimately, you just want to put your game somewhere
and being able to allow your players to connect to the game,
and just scale up and down
and allow them to play and have a great time.
In these different approaches
you could roll your own tech, right?
You can get your physical servers and configure them,
actually buy them, and put them under your desk.
You get full control over everything.
And while control is good,
there is also this thing like overcontrol,
because you'll be ultimately investing a lot of time
on building, maintaining, patching the servers,
and this is a time you're not using to make the gameplay better.
Given the time is limited, you should choose wisely
where you want to invest the time,
whether it is operating or creating.
Another path is to use a generic solution,
maybe even a hybrid solution
where you get servers managed for you.
You don't have to actually have the physical servers in most cases,
but all the services that are related to your game,
they have to be developed either in-house
or by using another third-party solution.
And lastly, the other path
is to use a game server operating platform,
which sounds like something interesting, right?
And that's what, for instance, Unity's Multiplay offers.
It's a product with bits and also humans.
That means that we have a team that tests, launches,
patches, upgrades, and encrypts titles
for the biggest AA and AAA titles out there.
We offer this, it doesn't really need to be
the option that you choose,
but it's another approach, and this is the one
that basically allows you to use a service
that is focused on games and is operated for you.
Also consider that in any route that you take,
there will be costs in both
and that these costs have to be aligned
with the business plan for your game.
Making sure that the cost of operating the game
ultimately is less than the revenue that you get.
It makes sense, but it's important to consider that.
And also consider that the right solution,
the right cost, the right everything,
can help you grow your revenue by providing the base
for an excellent gameplaying experience,
which is ultimately what we want to create.
Perfect. Now I just want to ask you
if you play
or when you're competing,
do you talk with the people you're playing with?
They are using Unity's Vivox.
Now let's talk about one thing that helps with player retention.
And in this case, for multiplayer games,
it's communication what we're going to be focusing on.
Retention basically means keeping your players coming back for more,
keeping your players returning to play and playing,
not every day necessarily, but you get the idea.
And one thing that we have observed
is that players who communicate in-game have a higher retention
and longer play sessions on average, which is great,
and this is consistent across all types of games.
In addition to retention and engagement,
the other key benefit of in-game communications is immersion.
Thanks to in-game communication,
games like
they can offer a more immersive and compelling experience.
They can let their players strategize, cooperate and feel part
of a richer multiplayer experience.
The technical challenges are here too.
Think like, how to support cross-platform communications?
If I want my players to play everywhere
and still be able to communicate,
another thing to consider is,
how to deliver a great quality of voice?
Once again, most game studios want to invest their resources
in making games that are fun to play
and not necessarily the tools to handle these communications.
Again, not extensive, but here's a list of things to consider
when implementing a solution for in-game voice communications
for multiplayer games, but it also applies
for text-based communication,
but mostly to voice communications.
The cost of operating, again, this is important
and this is key to know that the cost makes business sense
for our game and our company.
Also, the support, it has to be 24/7.
It even has to be supported across the globe.
Also, the cross-platform capabilities,
you know that we, Unity, the engine allows you to deploy,
a lot of platforms and other engines,
they allow you to do a similar thing.
You need to support players on multiple platforms
and being able to communicate.
Also, the processing and memory footprint is...
You don't want your game to spend a lot of processing
and a lot of memory just for communication,
you can use that in effects or in physics or AI, etc.,
so that's another important thing to consider.
And also a key thing is the regulatory changes,
things like accessibility, compliance, security, etc.
These are things that you have to consider.
Finally, the development of new features,
you want to make sure that new features come,
and ultimately this becomes better sessions for your players,
better gameplay experiences.
That's it for this session.
I really hope that you found this information useful
and that you take a look at Unity's Operate Solutions
for your current or your next game.
Just to summarize, if you want to learn more about the topics
that we discussed, I invite you to take a look at Vivox
if you're interested in in-game voice chat.
If you're interested in knowing more about matchmaking
and game server hosting, keep in mind Unity's Multiplay,
and also, don't forget to attend Brandi's presentation at Unite Now.
Remember, all the services that I mentioned are engine agnostic,
so if you're using Unreal, or using your own custom engine,
you can still use our services to operate your multiplayer games.
Thank you so much, and I hope you keep enjoying Unite. Bye.
♪ [MUSIC] ♪