Is there a reason most are NOT using authoritative and dedicated servers?

Looking at all the available options for unity networking lately, whether its UNET or Photon it appears to be that most developers are not using authoritative server logic or dedicated servers.

Is there a reason why? I feel like I'm missing something. Cost? Ease of development? Lack of tools?

These were two things I absolutely wanted for my current project but after exploring both it seems I'm losing out on a lot of other functionality. Whether its master servers or matchmaking. It seems any SDK with a feature set uses peer to peer / client as host models.

This seems very problematic with regards to cheating.

It seems almost all the tutorials are using client authority, even official unity demos, which just seems problematic. Am I wrong to put so much importance on server authority? Should I stop trying to fight the system or have I overlooked an obvious solution?

Any input and thoughts are welcome.

 

Can't speak about Photon, but I think it's because UNET was designed to make player hosting easy and failed. It seems great at first because you don't need to put a server up somewhere and deal with something like Unity matchmaking. When people can't get it to work, they give up and try peer-to-peer or move on. Speaking from experience, it's difficult for a hobbyist to find the time, knowledge and resources to build out the backend to do this properly. There are a lot more options than when UNET came along a couple years ago, but I think the damage has been done. I often recommend folks download the "Dedicated Server" asset just to see how simple UNET really is when you aren't trying to have a server and client all in one process and use the same classes on both ends...

 

BTW, as to client authority, it's a performance issue. If you have latency on the traffic going to and from your server, you can't wait for your input to get there, be processed and come back for anything realtime. When I do stuff that isn't realtime, it's 100% server authoritative, and if the client does send me something, I check it against the server.

 

I think this touches on my main issue at the moment. If I want to use server authority / dedicated servers I'm left with very little for backend options. Where as if I choose to go the peer to peer / client as host model, there are options like Photon that try and have an all in one solution.

Essentially this leaves me stuck in the middle where I'm having troubles making a decision on what is a better use of my time. Do I use dedicated servers and have to code my own matchmaker (skill/rank based etc). Or do I instead go peer to peer and leverage a solution like Photon that will help me with the rest.

I just wish there was a dedicated server solution with a comprehensive backend feature set. Or maybe there is, I'm just not aware of it yet?

 

This is essentially what I'm doing currently. I have some client side prediction and server reconciliation for input, while other non player logic / AI stuff is handled purely on the server.

Although this is server authority its still running as a host on one of the clients machines. Which seems like all the server authority logic is going to waste. If the client who is cheating, also happens to be the host, they can do anything they want and I can't stop them. Same as they could if I used client authority.

So I'm left with the decision. Move to dedicated servers and miss out on backend features, or leave it open to cheaters with the potential to leverage backend services like photon for other features I'm missing (matchmaking etc.).

 

I use UNET but don't allow player hosting, so the split authority works out ok for me. It's also possible do full server-authority with UNET (maybe that's what you're using now?)

There are backend services that support what you want, but you have to pay for them. I'm relatively ok with that, but need to be able to host at least some of the services, so a cloud-only solution like GameSparks doesn't help me. I don't know of anything about Photon that enforces peer-to-peer or client-authority models either, so it's up to you. I've been looking at open source stuff. Here are my three candidates:
https://github.com/angusmf/django-unity3d-example (forked to add features)
https://github.com/nVentimiglia/Unity3d-Foundation (currently attempting to port to .NET Core)
https://github.com/heroiclabs/nakama (only mostly open source)

 

I am aiming for full server authority. I still have some work to do but I don't see anything in UNET preventing me from achieving this. As an example, using the default network manager. I can run one instance as the "Host / LAN Server", and then have 2 clients connect via Lan Client for a 1v1 match. Its 100% server authority. I get around any input latency with client side prediction.

The problem is I don't have the same option for hosting when using the Match Maker. By default one of the clients must be a host. I believe I can get around this by (doing what I'm assuming your doing?) and hosting my own dedicated server / headless version. Then the matchmaking will hopefully find that server when the clients are looking for a match, and I can prevent the clients from ever being able to host.

If I do this though, then I need a way to spin up and down dedicated servers depending on concurrent users. Or now that I think of it, I guess I could just keep them up all the time?

Ideal 1v1 Scenario:
I would like 2 players to attempt to find a match. If their skill levels are relatively equal they get matched with each other. A backend service of some kind starts a dedicated server / server authority host for them to join. Then both players are connected to that match.

From what I can tell Unity has no solutions for this backend service. I have no way to spin up a server on demand, and no way to match players based on skill. So I either have to make something, buy something, or.... if I switch to peer to peer / client as host model I can get this backend capability with Photon.

From my understanding there is no way with Photon (PUN) to make a dedicated server. One of the players will always be the host. They have Photon Server, but from what I've read this seems like a whole other beast for people far more knowledgeable than me.

Also please point out anything that doesn't make sense or I am incorrect about. I've been struggling with this for months, so Its nice just to get it written down. Unfortunately I haven't been able to make any forward progress lately because I can't seem to sort out any clear path forward with obvious solutions.

Thanks for the links. I will have a look at these.

 

Oh, yeah, none of that stuff does matchmaking with dedicated servers I suppose. This is probably more like what you want:
Game Server Framework
https://www.assetstore.unity3d.com/en/#!/content/71391

It's all written in Unity, which is interesting, but it does the matchmaking and server instance management. Great project, very extendible. It's actually the other backend stuff that lacks a little, and his architecture doesn't quite work for me. I've talked with him a fair bit and the next version of his framework may be more applicable for what I want. Should work great for your needs as-is, I think.

 

FWIW, I'm thinking about doing a really simple matchmaking system using that Django asset. When a server is up and running, it will post its details to the backend every so often. A table will be updated with the server's ID, address, and last time of update. Anything too stale would not get returned when clients request a match. There could be additional parameters to match players by skill, location, etc. but I want to keep it pretty generic. It almost irks me that every backend assumes I want a leaderboard. What if my players don't have scores?

 

Ah yes, I have looked at that briefly and my next step will probably be to investigate it more thoroughly.

The original point of this thread was that I was surprised I hadn't come across more people discussing this topic or having similar issues. Seems most of the discussions resolved around peer to peer and client as host models.

This was creating internal concern that perhaps attempting this was not the best way forward. That perhaps I should completely re-evaluate how to approach the networking architecture. 26 reviews of that package vs 100s on Photons. Perhaps there was a reason I was missing for why others were not going this route.

 

I think it's just that there's no mature package for it rather than the approach being wrong. Like I said in response originally, I think it's problems with UNET itself being biased towards player hosting (and people being too cheap to spring for hosting, etc. --forum traffic is mostly hobbyist.) Photon has been around for years. MSF has been around maybe 6 months? The dev let me see the source before I purchased so I could try it out. Maybe you should send him a message. The biggest thing I didn't like about it was that it assumed that I only wanted to control one game (I want many games with common user accounts.)

 

Unity's UNET is not really built for a single server instance to handle multiple separate matches simultaneously. The HLAPI assumes everyone connected to the server is a player in that one match. I suppose you could come up with some creative solution for having separate matches actually take place in separate areas of the same scene, far enough to be out of view of each other, but that's not really what it is built for.

When I was looking at this issue, my solution with UNET was to create a custom matchmaker server. When all players are ready to start their match, the matchmaker server spins up a separate match server (literally runs a Linux command to launch a server instance), players wait a few seconds for their match server to finish loading, then connect to it and spawn player objects as with any basic UNET demo, all with server authority. When the match completes, players connect back to the matchmaker server, and the match server shuts itself down.

The problem with this solution is it doesn't scale as well as leveraging a player's own computer to host a game.

 

That is essentially what I'm attempting to do. I've found a couple packages that will help me with the back end portion and am currently investigating them. It would of course been nice if Unity provided that functionality out of the box. But at least there are others in the community working on solutions.

Thanks for the reply.

 

Just adding my 2-pence here: unity as a platform is designed to be accessible. Right from the fact that they put so much work into the ability to use a javascript-esque programming language (which is possibly the most widely known language, even though mostly at a basic level) to the fact that most of unity's features are based around convenience. This suggests that unity's philosophy is based around making things as easy and accessible as possible.

So, naturally, unet as a framework is introduced to you in documentation in a way where it makes the whole complicated beast of multiplayer games more appealing, and less daunting. Not only that, the peer-to-peer model can be used without any knowledge of how servers really work, or the cost of setting up your own servers, which is again something we can't expect the average joe to be able to do.

So, it's appearance is certainly that it is built to be used along with the peer-to-peer model, but this is just the cover of the book. Unet is perfectly designed to be used along with the client-server model (more so with the LLAPI than the HLAPI), and so if you know a little bit about how to implement the client-server model, I would highly recommend that you aim for that.

Note however that you already talk about matchmaking in your current concept. This complicates things a little bit for you because the simplest way to use matchmaking is to use something like the matchmaking service provided by unity, or similar vendors like photon/gamesparks etc. The way these work is to provide you with a server that keeps a record of your players and available games, allowing you to create/list/join players to games so that they can play together. In order for this to all work, the service needs to handle server instances of your game for you, meaning that a client-server model is either very difficult to set up, or realistically impossible.

What I would personally recommend, and this is because I personally would rather have the control to manage all servers myself (lowering costs involved plus many other benefits) is to set up your own matchmaking server to pair up your players, and your own game server(s) to host instances of your server-side. That way you can use the client-server model with your authoritative server-side running as instances on your game server(s) etc.

Hopefully this helps!

 

It's just that proper authoritative server implementation immensely complexifies game code, no matter what networking solution/package you're using

For example, when shooting a bullet in an online FPS game...

• P2P: You trust the clients, so the client checks on their side if they have hit an enemy, and then tells the other players "I have hit this enemy"
• Auth. Server: You can't trust the client, so the player sends his request to fire to the server, then the server receives the request, validates if it makes sense that the player could shoot at that time (to prevent fire-rate hacks) and rewinds back in time to the shot's timestamp to see how the world was at the exact time the player fired (this is for lag-compensation), and then checks if the hit would've been valid, and then informs all players of the hit and un-rewinds time to where it was initially.
  ... and we haven't even started talking about playing the audio-visual aspect of the shot instantly on the client (for responsiveness) while the server processes it, and possibly applies a correction later on if the server disagreed.

So I'm guessing many devs are just opting for P2P architecture, or a client/server architecture without real authority. Sometimes, if you can live with the fact that there will be hackers that will ruin your game, it can be worth it. Especially if your game isn't super competitive. You could realistically expect the development of an authoritative server game to be literally twice as long as a P2P game

But UNET does support all of these architectures (you can use the LLAPI for true P2P). The things like lag-compensation and shot validation that I described up there aren't things that UNET could or should manage. It's too game-specific. You need to handle this yourself

I think, sometimes, that inexperienced devs expect UNET to do things that it shouldn't do. I'm not talking about you, OP; just in general. This is true for almost all aspects of Unity, actually. Sometimes you can't do everything just by drag-n-dropping stuff. Sometimes you gotta code your game. The Unity community complains way too much

 

All great points.

It has been quite the learning curve for myself. I do think it would have been easier if there was a bigger focus on Server Authority from the get go though. Almost like I was lead down the wrong path, because it was easier, which made it that much harder to find the right one.

Reading, listening, and watching so many networking tutorials, talks, and presentations only to struggle to find anything related to server authority when referencing Unity.

I think my first post in this thread highlights that. So much seems to re-enforce the idea that P2P is the only way. Whether its official tutorials, or external tools for Unity.

I've gotten to a point where I "get it" now, server authority and Unet. So I agree, there is nothing in Unet preventing you from you choosing which architecture you want. But, it definitely was a journey.

For anyone who is interested, this is the package I've gone with to handle the back end for my current project (That's using server authority ). (Master server, dedicated server spawning and match joining etc) https://www.assetstore.unity3d.com/en/#!/content/71604

 

hi @SpaceMomo

I read all the posts in this thread, and feel like we are kindred spirits. I have spent the last 1 week researching all of the networking options, and was absolutely dumbfounded to find there's no clear Server Authority software available for Unity. It seems Photon Server and Photon Bolt w/ Server Authority all have almost ZERO documentation. Forge looks promising, but has a bunch of negative reviews on the store. GameSparks is WAY too high level for me and the pricing may not scale. I was really surprised to see how hard P2P is being pushed by the network tech available to Unity. As bad ass and high level Unity has made game development, I''m surprised that server authoritative game logic has not really improved that much at all in the last 10 years. I first got into game dev 13 years ago trying to create an 2D MMO using RakNet. At least RakNet had built in synchronize time to get the time deltas when you were on the server....

Anyway, funny enough, I've also landed on the Speltwine MSK kit and found I really love it A LOT. It so far is the most promising to me. I'm a little worried about being married to this low level solution if later I get stuck doing physics syncing though. I may regret not just going with the high level insecure stuff....

How have you progressed the last months since you wrote this? Would love to chat with you about it. I'm 'ddough44' on the 'unitydevs' slack room.

 

@drewdough
you can always go with LLAPI and try to do it yourself when talking about authoritative and dedicated server.

- One master with f.g. websocket (to use TCP, HTTP, SSL etc) with encypted data to send, such login, password etc running 24/7
- gameservers spawned by master with f.g. Proocess.start() and using uNET UDP to communicate with players during the game (there is pseudo TCP by using channels to be sure that important message will be delivered - like info to update Health on the client side)
- clients - players
Of course all of this in 3 defferent projects to not keep all coding in one build which will be available for all.

Solution where one player is a sever... yeah... hello in the world of cheaters ;p
So you have to add some validation of this player actions on the other clients side as well. Doesn't sound good for me.

But another problem is when this client+server player will leave, then you have to swich to another player (if possible with Unity) to be a server and this will not be smooth for sure. Other way all other players will be disconnected and game will be over just because of one guy - not funny.

 

I know this is a little older of a thread, but I'm surprised Smartfox Server wasn't mentioned. It supports all that you need. You can make an authoritative server and there are examples with Unity. Its free with the Community edition (100 CCU limit), has been used for many years by many larger companies and is quite well supported.
Here is the unity asset to download. https://assetstore.unity.com/packages/tools/network/smartfoxserver2x-multiplayer-sdk-17261
You can get the server here: https://www.smartfoxserver.com/

You can add extensions to the server code (in Java or Javascript).

 

I started out using Photon because it initially seemed to have everything I needed, and in the long run wasn't too pricey and also had a lot of support to it. I knew that a dedicated server solution would be the best for my case, but I didn't know how to go about it without the solution being super pricey, and since I'm new to networking in games, I thought I would like a free solution that I could pay for later if my game was a success or whatever. So in my case it was lack of experience, and a lack of understanding of potential tools.I got to a point with Photon where everything in regards to my base game kind of worked as intended, but there were some bugs in relation to the whole client-to-client way of doing things, that wouldn't be there using a dedicated server. I looked after tutorials, threads and googled what to do at this point, and I found a bunch of tutorials using TCP sockets in pure C# as server (TCP is definitely better for my case rather than UDP, there's no realtime action in my game) and thought, "I'll do this!" however, this meant a lot of fiddling with bytearrays and stuff that I actually have no interest in. What I wanted was to make a dedicated server in a HLAPI so I can work on the fun parts of my game ASAP. I found an asset called BestHTTP (https://assetstore.unity.com/packages/tools/network/best-http-10872) which was perfect for my case, since I have experience with NodeJS and socket.io was exactly a library fitting my type of game. So I cleaned out all my Photon code and recently started using NodeJS as my server instead. I could probably have saved a lot of time and frustration just using BestHTTP from the start, but I did learn a lot along the way, and looking back I felt it was risky to spend 60 USD on an asset I may or may not be using, when I could use a "try for free" solution as Photon was. Now I have full control on what goes server-side and what goes client-side, and everything I made in Photon that took me months to make, has only been taking days to weeks with BestHTTP. Likely due to my increased experience.

So to sum up, I chose Photon because initially it was free, I didn't know better, I wanted to get started ASAP, and I was completely new to network programming. Did not pick up BestHTTP due to risky investment early on (I felt) and lack of knowledge about other potential alternatives with HLAPIs and dedicated server programming for Unity.