Has anyone here actually made a finished MP game? Link please?

I see a lot of the same people here on the forums, and they seem very knowledgeable. And I start wondering about the games they've made. Do you have any games to show for all that knowledge? Can I see?

 

I am fairly soon to release a game that is built with unet. We're waiting on the patch that is going to fix a few performance issues and bugs with the new 5.6 updates before we go ahead with the release, at which point i'll be happy to share links etc.

Some info though:

• can handle up to 300 players, even though it mainly targets mobile devices
• cross platform (mobile/desktop/webgl clients all connecting to the same server)
  
• data is averaging at around 1kpbs, and peaking at around 2kpbs
• sending messages around 10 times per second, for thousands of objects on the server

I've been quite impressed with what i've been able to achieve with unet. Granted, I don't use many of the HLAPI features (such as syncvars, rpcs or commands), and I built a simple framework on top of unet to help me build a super-efficient networking solution (i'm happy to provide more info on this if you want to know more). So a huge amount of my focus has been on keeping the networking super lean and light-weight, which wasn't easy and definitely wasn't done by unet, that part was on me.

If you want to know more, let me know!

 

This is what I'm working on with UNet: https://steamcommunity.com/sharedfiles/filedetails/?id=811431868



I've avoided the relay servers and matchmaking stuff, but use the HLAPI quite successfully so far. I'm only targeting small numbers of players per server, but there's quite a bit of data getting thrown about with the world & inventories.

It's certainly not been perfect, and the learning curve was pretty steep back when it was launched. That said I'm hopeful the remaining kinks can be worked out by the time I want to release my game, and I don't regret jumping in and committing to UNet.

 

Hey! What kind of solution did you built? Seems very interesting.

 

Me too !

 

Could be using NetworkServerSimple class and his own object based network messages. Certainly, sounds like a win there.

 

@Wobes @DungDajHjep I can't really give too much information away at the moment about the game itself since we're expecting many clones to be built as soon as we launch the game! So we're holding off on that until release. I will definitely post up links/access to it as soon as it's ready though!

If you want to know about the technical sides of it, or how I achieved some of the points mentioned in my response above though I would be more than happy to go into detail about that. So if so, let me know what questions you have and I'll be happy to answer.

 

Yeah, that's one of the main things that I did. I initially, about 6 or 7 months ago when I started the project, started off building a simple framework on top of the LLAPI, because I wanted to avoid the bloat of the HLAPI entirely, knowing from the start that I needed as much performance as I could get to support the target 300 on mobile devices. I came to a pretty tough stumbling block a few months ago though when I discovered that the LLAPI doesn't support websockets on the client-side (when calling NetworkTransport.Connect) and went hunting for a fix. I found that by using the NetworkClient and NetworkServerSimple classes as part of the HLAPI, I was able to get websocket support while still avoiding the unecessary bloat and ultimately get the performance that I wanted. You can read about this in detail here: https://forum.unity3d.com/threads/client-side-websocket-support-with-the-llapi.457081/#post-2966247

Another benefit of the NetworkServerSimple class, is that it is not treated as a singleton/static class. The NetworkServer, you cannot have multiple instances of it like you can with the NetworkClient. So in my case, where I wanted to have two "servers" (basically two ports) for udp clients and websocket clients, this was a problem. Being able to construct instances of the NetworkServerSimple class ultimately solved that problem. I still had to do my own handling of "peers" though, because having two instances makes it a little more difficult to handle messages being sent to all peers, because they can sometimes belong to different hosts... so the framework that I built on top of unet was built with this in mind.

As for "object based network messages", that's a no-go. The framework that I built on top of unet is designed for performance, it had to be. So, it has zero support for the sending of objects, like how you use MessageBase instances in unet and serialize/deserialize the properties of the object to send them over the network. I avoided this for two reasons:

• No matter how you do it, you always have to construct and initialize new instances of the object on either side, in order to serlialize/deserialize, which means cpu, ram and added garbage to the garbage collector. When doing this alot, the garbage can become a serious issue
• With the construction/initialization of the objects aside, just the fact that you have to deal with objects is more cpu/ram intensive than if you just dealt with simple values

If you've ever used photon or similar frameworks (where I started learning about multiplayer games many years ago) you'll be familiar with the request/response/event pattern, where the client can send requests, and the server can respond to those requests and/or send events to one or all peers. This is sort of how my messaging looks:

Code (CSharp):

1. NetworkWriter nw = peer.PrepareEvent(EventCode.revengeListUpdated);
2. nw.Write((byte)this.revengeList.Count);
3. foreach (Revenge rev in this.revengeList) {
4.     nw.Write(rev.playerid);
5.     nw.Write(rev.timeleft);
6. }
7. peer.SendEvent(Channel.reliable);

Alot of the above wont make sense, because the method calls are all part of the framework that I built, but ultimately this is what has made my game be able to perform the way that it does. I first return an internal cached instance of a NetworkWriter as part of the "preparation" of a request/response/event, write any payload that I need to (based on what the unet's NetworkWriter.Write method supports). The SendEvent message simply sends the prepared event. So the above is super efficient because no objects had to be constructed, no casting, no reflection. It would obviously be a nightmare for anyone to use this that was new to networking, but again, this is designed for performance.

Let me know if you want to know more about the technical side of things, I will be happy to share

 

Thanks. Very good information! In your opinion, how many clients can hold HLAPI server using lightweight Commands and RPC, which hold Authoritative Inventory System and Interactions like Shooting System etc.

 

Honestly, it's really hard to give you an answer for how many clients the HLAPI or unet in general can handle. While I was developing though, I found the two main bottlenecks to be cpu and bandwidth. My cpu issues though were very rarely anything to do with the networking but it's worth mentioning that here because the more "clients" that you support, technically the more objects you'll be handling on the server and you'll probably find the cpu bottlenecking first as a result. As for the bandwidth, from the testing that I did on different devices, aiming for 1000-2000 bytes per second on mobile/wifi will keep you right, and a maximum of 10k bytes per second on high-end devices with good internet would be my recommended maximum.

So ultimately, it comes down to how much cpu you want to pay for (my "server" is a "small" google cloud compute instance, which is 1 shared cpu and 1.7gb of ram for around $14 pm. It rarely goes about 50% cpu) because more cpu will allow you to run more game logic. Using the above bandwidth recommendations, you should be able to look at the stats for your current game and see where you are in the scale of things.

Hopefully this helps, let me know if you have any further questions

 

Thanks, very helpful

 

What are the server costs like at that usage?

 

Apparently, google)

 

I mention that in my response:

But that is for just one server. I have it set up so that it will spawn additional "small" google cloud instances running the server-side of the game when it needs to. So basically I'll be paying around $14 per month for each 200-300 active players.

 

As promised above, we've just released the game that was discussed in earlier posts and here's how you can get your hands on it:

web version: https://frogar.io
google play: https://play.google.com/store/apps/details?id=com.jadoku.frogario&hl=en

We are still waiting on some performance improvements on the networking side of things, but overall we're pretty happy with how the game runs on mobile. It's a little choppy in the web version but that's to be expected with the limitations of WebGL. Any feedback though is very much welcomed!

If anyone has any technical questions about the game, I will be happy to share what I have learned.

 

http://brokeprotocol.com
Open-wold thug life sim I guess with hundreds of players online now. Works pretty well on the network side- but "no free events for message in the queue" will be the end of me.

 

Did you use UNET or photon?

 

We have a game in early access on Steam. We initlaly released with Forge as the network SDK. But soon ran into problems so we switched to a custom framework using Steam UDP under the hood. Took about 1.5 man months to switch to the new system.

Our game is a 6vs6 shooter for VR. We sync almost everything including physics so its a very special case. Here you can see were we sync items thrown between players (Old video so it shows some glitches that are now fixed, thats on the old Forge SDK by the way).

Here you can see the level of sync, we basically sync everything It's alot of work to make sure network utilization is kept at sensible levels and that the experience is rapid enough.

Our game lets players connect at any given time, and syncing the state for some of our more complex items have been a challenge.

 

We're using UNET for this. I like photon, and the other products that exitgames provide, but if you try the game out you'll notice there's a fair but of custom things going on (particularly related to persistent data). On top of that, the game can support up to 300 players per server, on mobile, which just wouldn't be possible with a framework like photon which is designed to make things easier than performant.

Ultimately, I built a simple framework on top of unet (to make the low-level stuff a little easier to use, while avoiding the bloat of the HLAPI) that focuses on network performance. If you'd like more information on this let me know

 

Hey, in your opinion, proper HLAPI code could handle over 100 players per server? Oops, I'm already asked the same question before, thought that you are a different person

 

Hmm it's tricky to answer that. It probably could if at a push if you are cautious about your send rates, and optimize everything as much as possible (use as few syncvars as you can, be "clever" about how you keep things in sync rather than just be lazy and sync everything... etc etc). Ultimately though, the HLAPI is a convenience solution. It is designed to make your life easier at the cost of performance so you will naturally get better performance (and the ability to handle more networked peers) if you are able to avoid the majority of it.

Again though, I reckon you could probably get around 100 peers with the HLAPI, but it would take a good bit of work to get there.

 

Yep, I have a bit SyncVars, PlayerPosition, Rotation, Camera Rotation. Also, I don't need to sync whole player Inventory via SyncVars, I could just have a local coppy of it on Server and transmit it via byte[] to only one specific Client. The Client can only send commands about Drag&Drop from which slot to which slot he wants to drop item. So it's something like Authoritative Inventory, where the client can only send commands about his intentions.

 

@Wobes it sounds like you are thinking along the right lines, as most of your time spent doing network programming will be spent finding problems that can be solved, and it sounds like you've already been doing that! So yeah, I'd stick to what you're doing and if 100 players is your target, you should be okay.

 

Thank you so much for your kind words!)

 

@donnysobonny
Hi, how you made authentication process ?
As far as I know there is no such thing inside NetworkTransport.Connet() function.
You can eventually disconnect user but after OnServerConnect() is called what is poor approach to let everybody connect to your server and disconnect them in the next step.

 

@TomPo if by an "authentication process" you mean something like logging in a user to the server you wouldn't actually do this using real-time networking. UDP, the protocol that is used in real-time networking (which is what you're using when using UNET) is not secure, it doesn't have the ability to transfer messages securely like you can with TCP/HTTPS/secure websockets etc. So ultimately, I would recommend not using UNET to build an authentication system unless you are using secure websockets (which I recommend you don't do either due to the technical limitations/annoyances of websockets!)

In Frogar.io, if that is what you are referring to, there is both a web-server back-end and game-server back-end. The game server handles all the real-time volatile data and processing (such as moving the frogs around, keeping scores etc) while the web-server handles all of the persistent data (such as storing scores on the leaderboard, handling player data and more importantly: authentication). Web servers are typically served over HTTP or in this case HTTPS, allowing the ability to securely transfer messages between the client and the web server. I wouldn't recommend doing authentication any other way.

There are third-party services which can help you here, such as things like google play services, but the back-end of these services are managed by the service provider so it can be tricky to provide any sort of customization, hence why we opted for our own custom back-end using a web-server.

If I have misunderstood your question let me know, otherwise hopefully this helps!

 

@donnysobonny
ok so step by step because maybe I'm missing the point here. It may be the longer post so sorry for this
Right now process looks like this (at least in my head)
1. Player run the application
2. Client is connecting to the server using: NetworkTransport.Connect()
3. In this moment client is already connected to the server because OnServerConnect() is called
4. server is waiting for next event from this connectionID to get login and password and after timeout (or wrongly provided) disconnect the client.

Above process looks like very poor approach and anyone can connect if only know IP and the Port and my concern is that the server for 90% of the time will be just connecting and disconnecting some bots, spammers etc.

- what is missing for me here is a buffer (byte[]/string[]) inside Connect() function from step 2 to send the data (login, password - encrypted of course) to validate this connection by checking in database.
Additionally we can implement if byte[] is empty means request came from outside Unity client (assuming that we implemented on the client side some checking to not send empty buffer) and this way we can add such IP into black list for example.

So my question is, how you manage to let only authorized clients connect to the server?
But as I said at the beginning, maybe I'm just missing something here with this uNET approach

 

@TomPo please refer to my previous reply on this topic. By the looks of things you've clarified that what you are trying to do is use unet to build a login authentication system.

Referring to my previous reply, using UDP is not secure, nor can it be made to be secure. This means that anyone can "eavesdrop" into the transmissions and (for example) see/extract the username and/or password that is being sent. A username and password should NEVER be transmitted insecurely and therefore you should look to change your method (ie: don't use UNET or a real-time networking framework to build an authentication system, use a web-server or some sort of third part authentication system like google play services).

Sorry that I can't offer much more in terms of advice here but suggesting how to build an authentication system using unet would basically be teaching you how to implement bad practices

 

donny, hi there, it's me again. Do you have a minute?
Is it possible to make a custom library for example: ServerCode.dll which will containt compiled network code of Commands and RPC + SyncVars, it will be used for updating the server build without building whole server over and over, so just copy&pasting of ServerCode.dll will pass to the Server new updated network code.

 

@Wobes hmm not without the server where you upload the .dll to being able to build the application for you.

A .dll file isn't particularly useful on it's own. I assume your background is in the web, where you can just drop files in because in that environment the files are compiled during run-time. Unfortunately though in .net your .dill files are compiled during build-time.

So in short, in order to use a .dll file within your project, it needs to be added to the assembly of your project (unity does this for you) before the project is run through the build pipeline. To my knowledge, it's not possible to simply drop a .dll file into your project after it has been built.

Most developers in .net are pretty used to this though and you don't tend to see .dll files changing too often so you shouldn't have to re-build your project too often.

Hopefully this helps, let me know if you have further questions about this.

 

Thanks.
The thing is that I don't know how to compile the network code into single .dll.

 

@Wobes if you are primarily working in unity, you wont actually be creating .dll files. Unity developers that build plugins or re-usable code will do so in c#/unityscript scripts which are imported into unity using unity packages. This is the primary way that you package up code to be used across multiple unity projects.

If however you are talking about using code that will be used within unity and outside of unity, then you are most likely building a standalone application (which it doesn't sound like you are?) in which case your project should be creating .dll files for you (if for example you're building a console application in visual studio).

Let me know if you need further clarification.

 

Okay. i'll try to explain my view. I'm working on standalone app. As you know, Commands should be registered on server and client in order to work. On HLAPI if you marked [SyncVar] or [Command] it will generate an OnSerialize and OnDeserialize methods. What I want to have: a Server which has the map and objects. Server will handle physics stuff and packets send/request. But also, I want to have compiled library for client and Server which will contain the network code which I'd like to compile and which would work for client and server but without building the whole server, pretty much client builds only.

So for testing I should have the next:
1. Compiled server only once.
2. Building only client side in Unity, compiling .dll file with network code.
3. Updating server with .dll drop.
4. Testing server and client on the same version of .dll.

Thanks for your time!

 

@Wobes hmm okay so your issue will be 2. Unless you are willing to go into the assembly of your project and tweak what unity does during the building of the unity project (I don't recommend doing this unless you know what you're doing) then you're going to struggle to get unity to give you a .dll that you can drop into your standalone application.

What I would recommend instead is build ALL of your networking within a single networking library as a standalone application (for example, a console application in Visual Studio) and include unity's own UNET server.dll so that you get all of the unet functionality in this standalone library. All of your client-side and server-side functionality would go in this library. Then, have the library generate a .dll file (simply build the project) and import this into the unity project within a Plugins folder, and also into your standalone sever application.

This will mean that you manage your networking code in a way where it can generate a .dll file which cna be "dropped" into both your unity application and sever application.

Hopefully this helps.

 

My game has gone pretty far using UNET

However right now at some point late game it seems the relay server gets overloaded and it just stops working, hope signing up for the Multiplayer services is going to fix that!

 

Haven't replied much. I expected way less games. Looking good @Rungsted93 and I'm blown away by what @AndersMalmgren created.

 

I did a quick video yesterday showing off the strategy that I use in my game Frogar.io, if anyone is interested!

Cheers

 

Next level of networking, networked rope physics. We only network the tip of the copper wire, rest is client side, but it looks relally cool!

Sorry for the dark pictures.

 

That looks super fun!

 

Thanks Alkanov,
Sorry for spamming But here is a better better video to show network code Its our new trailer, if you have any questions about the netcode Im happy to answer