koobas.hobune.stream
RPC custom server best practice
Hi to all,
We are currently kicking off our first unity project and I want to know what the best practice for networking would be. The game ( and hopefully games) involves no state synchronization for game objects, simple RPCs are sufficient, as it is a board game. We want to use an authoritative server, which has some simple logic like login, chat and the actual game with logic. For the networking I identified three options:
Use Unity networking for both server and client. I really don't like this option, for obvious reasons - we will be bound to Unity on the server. I want us to use our own server technology, as i want us to have full control and be able to easily bind "external" things like DB connections, control scaling, load balancing, etc.
Use TCP Sockets in Unity and code our own protocol and server. This is my preferred way to do it. The only negative point is that we have to implement low level in Unity. As we are new to Unity, but have a lot of experience with webservices, load-balancing, etc., it might not be a bad idea to do the heavy lifting on the server side. Which brings me to the third option:
Use Unity Networking in client and implement connection and RPC protocol on our custom server. This option will be great, as unity code will be kept very simple. Implementing the Unity network protocols should actually be no problem for us, but unfortunately i cannot find any documentation on the subject. I only know that unity uses raknet, but they also don't have any protocol documentation.
So my questions are: Which would is the best practice for networking not involving state synchronization? Is Unity's networking protocol reliable? If so, is this protocol documented somewhere?
Any inputs on the matter will be greatly appreciated.
Regards, Emilian
$$anonymous$$y suggestion : •Use Unity networking for both server and client.
Separating Server and Client into 2 projects will be find.
RPC is reliable but don't use it in Update function.
Unity's network is a closed box.
If all you do is shovel messages between the server and clients, I suggest you either
a) write your custom server
b) use one of the many excellent third-party server solutions available such as SmartFox or ElectroTank. This Google doc holds every known third-party server solution with integration to Unity, I believe.
In any of these ways you'll get rid of the need to run a Unity build as your server, which is good for numerous reasons, not the least of those the facts that from tests I've conducted Unity can't handle more than 100 concurrent users and is limited to sending 5Mb of traffic per second.
As a nice bonus you'll also free yourself some system resources.
Hi and thanks for your reply. I think solutions like SmartFox are too expensive for what our current projects require as functionality. What i would like to find out is, what underlying protocol Unity is using for it's networking, so i can replace a Unity server, which as you said is not a good idea, with a custom server we program. The benefit would be, that we can use our own server without having to code extra on the client side. With "close box" you probably mean that the exact specifications of the protocol are not public and we would have to reverse engineer?
Exactly so, I'm afraid.
I suppose looking at the RakNet official documentation could help, but I don't know how the folks at Unity wrapped it up.
Writing your own solution may prove the easiest way.
