- Home /
Seperate server/client project network problems
I am currently creating a fps game, that is going to revolve around multiplayer. Here is my set up: 2 different projects, one for client, the other for server. (I plan to make master server an addition for later, so a couple of friends can make a private server)
1)I would like an explanation to rpc's. I know it stands for Remote Procedure Call. But the way it works? It takes the function and acts as if its on the other side of the network? Such as a server useing RPC for a client function, does the function from the server get temporaly created and called on the client?
2)The client is where it holds all levels, the server just holds one for starting it and whatnot. In order to update player movements and objects in the server, do i have to have to that level in the server? Then would I have to have all the assets to go along withit, then that kind of defeats the point of a server.
3)Having an object stay in multiple scenes, lets say for the client, it has scene one, and scene 2. Could i make an invisible object thats always running one script for the server be the same on multiple scenes?
4)I would like to learn about port broadcasting (or whatever method it is) used for automaticly finding servers and displaying
5)Player names, A string in a script that the server has to access through an RPC call then store it in its on list? (example please)
Thanks so much for helping, let alone reading all of this. As I am very interested in unity.
Answer by Bunny83 · Jun 07, 2014 at 08:24 AM
First of all, that are way too much questions for a Q&A question at once. I could write about 2 pages for each question. Things like networking requires time to understand and to implement, so don't hurry it.
RPCs are simply speaking network packages which contains a string which tells the other side which method should be executed. The RPC function has to exist already. You never transmit "code" that way. In addition to the actual function name Unity sends the parameters in a serialized form to the other side so they can be passed to the receiving function.
Well Unity, or more specific the Network interface, isn't really designed for dedicated servers. So Usually the server should have the same assets as all other clients. That's why it's not recommended to have seperate projects for client and server since it gives you tons of additional problems.
Of course you can create an object, use DontDestroyOnLoad and it will stay there until you destroy it manually or the game ends. You have to be careful since if you place such an object in a scene and you load the scane multiple times, you end up will multiple instances of the object since the old ones aren't destroyed when you load the scene again.
Network broadcasting is a huge topic on it's own and has barely anything to do with Unity. It has to be implemented with the System.Net classes of Mono. Keep in mind that broadcast detection only works in local area networks since broadcasts aren't routed through the internet. Usually UDP packets are used for broadcast discovering. Search the net and you will find a lot on that topic. Sockets are Sockets, so it works almost the same in most programming languages. You should understand the concept.
The player names are just one thing you might want to synchronise across all peers and yes, using an RPC is the usual way to do that.
Some additional information about Unitys Networking solution (RakNet):
If you call an RPC either from the server or the client the RPC function has to exist on both sides, client and server. That's a (strange) limitation of the RPC implementation. That's also why it's recommended to use the same project for client and server.
Depending on your type of game it's usually recommended to do most logic on the server to prevent cheating. That's why things like collision detection, movement, ... should be done on the server. It's way easier to have each client just report it's own possition in his world to the other, but that way a client can teleport / fly as it wishes or simply "kill" the other player that's not even in sight.
One thing to realise is that each player / peer (client or server) has it's own world and it's own local objects. Those aren't related to the objects on another players PC. They can move independently and could even be destroyed independently (which should be avoided of course ;)). Only the NetworkView builds a link between two objects on different PCs. Client and server need at least 1 object that is "connected" from the very beginning in order to communicate through that object. This can be done by loading the same scene on all peers so they have the same object loaded. Another way is to do a Network.Instantiate so everyone instantiates the same object. Both ways requires that client and server have either the exact same scene or the exact same asset. Exact doesn't mean it looks exactly the same. More in the sense of unique asset id. Another reason why seperating the server and client project would just cause problems.
If you haven't any experience in network programming i strongly recommend to read a lot and maybe watch some tutorials. You have to understand the concept or you won't get it working or introduce tons of bugs and exploits. As i said in the beginning, it takes quite some time to grasp all those things.
Good luck.
Your answer
![](https://koobas.hobune.stream/wayback/20220613151002im_/https://answers.unity.com/themes/thub/images/avi.jpg)
Follow this Question
Related Questions
Emulating authoritative-client behavior (like NetworkTransform) for SyncVars 0 Answers
Authoritative Server / Player Communication 1 Answer
Unity networking collisions with client authority 1 Answer
Unity Editor Crash !!! 0 Answers
Choppy player movement on clients' devices but not on authoritative server using UNet 0 Answers