This week I made a revelation when it comes to network programming. Turns out it’s really really easy. Actually the revelation part happened on Saturday, so I had to set myself down and do some programming, so during the weekend I made a starting menu where we can select to start a server or connect as a client. As you can see in the screenshot below:
So the whole idea was that you have one dedicated server and then you have the rest of the players connecting as a player. So when you’re starting a server you’re asked for a name for the server and then ports to listen to. This is all really straight forward, basically the server just listens and once you have a player asking for permission to connect to that particular port, they are let in. Right now there’s no authorization, which is something that we might want to do later, also we might to make the server a standalone version so that you have one that you can start as a server and select port and you’re up and running. That however is something for later, right now we just want to have the game up so we can have an alpha that we can play.
Anyway after you connect you can select a role and if someone has selected that role the server let’s the client know it is taken by deactivating the button on the client side. Like the screenshot below shows (might have to click it to see):
“Coding”
So now down to the nitty gritty of the code and it turns out it’s not too difficult to get the network working as it should. Now there’s a lot of code behind the scenes that you don’t see, even as a programmer, now of course you can go deeper into the material, but right now we have decided not to write our own packets etc. It’s not that it is a problem, it’s just that it is more convenient to just let Unity handle all that stuff itself.
The first thing that you need is a gameobject with an attached networkview. Networkview allows you to call remote procedure calls, which basically are remote methods / functions. How you do it however is a bit weird, especially for me which is more used to c++ than c#. Another thing, we used uLink, but the basics are the same as with the unity’s own networkview. Anyway that networkview is attached to the gameobject you want to modify, but it needs to be on both the server and client, because think of it like a post office, you deliver the packet to the office, but although you have an address you don’t have a name or a box where it belongs to unless you have it attached to a gameobject. So that’s the first “rule”, gameobject with a networkview that resides on both sides, so you have your pitcher and catcher ready.
The next thing is inside the script, now this is what I had problems with, because let’s say you have a script on the server which calculates the movement of the character. In our case we have the server just take input from the clients, the movement then happens on the server, the movement is then sent back to all clients – even the owner. So let’s take that example with some pseudo code:
The client clicks the mousebutton on a coordinate.
The client sends that position to the server via a networkview call. And the weird thing is that you do that via:
Networkview.RPC(“SendMyMouseClick”, RPCMode.Server, somelocation); // somelocation is a Vector3
The server has then a keyword called RPC like this:
[RPC]
void SendMyMouseClick(Vector3 p_ClickedPosition){
vector3OnServerThatYouWantToChange = p_ClickedPosition;
handle the data here or use methods here;
}
The server then has a way to tell the clients where the clients avatar should be going.
networkview.RPC(“YourClientNeedsToMoveHere”, RPCMode.OthersBuffered, arguments to send back (normally vector3 for position and a Quaternion for rotation, maybe even an animation state)
The client then catches that also via a “tag”:
[RPC]
void YourClientNeedsToMoveHere(the arguments needs to match the senders arguments){
change what you want here. Update whatever. Just know that this is the client and not the server.
}
In any case that is in reality all there is to it, now I believe (not been able to test this yet) that you can seperate the code, just that it needs to be attached to the same gameobject. That said we have so far not done this, so we have both server and client code into the same file, but we separate the code with comments, so I don’t know if it will work, something that we want to test at a later point, I see no reason for it not working however.
In any case, hopefully we’ll have the first Alpha ready tomorrow, we have most of the code for it to work done. We’re just missing the network code on the commander, we’re missing a little bit of code to get the commander working right and we also need to make a GUI so that you can actually build stuff.
The rest of the week I’ve actually spent getting the players to update, getting the creeps to update on all clients along with the towers that we have placed out. So we have most of the networking code in the game right now, which has been my focus for this week. Once I figured out how it had to work it wasn’t that hard and I see now that coding in c# which also was a little challenge turns out to be reasonably simple compared to c++.
GAME student blog - Inge Olaisen 