Above are a few examples that demonstrates the variety of some of my work. Although I have a fairly broad skill set for making games, my primary areas of interest are gameplay programming and network programming. For this blog the focus will be on the latter.
Unity offers an assortment of tools to aid in the development of games, one of which is the inbuilt networking system UNet. This new system was recently released replacing the old system, with which I had a vague sense of familiarity. The downside to my sense of familiarity with the old version is that I learnt it through a series of youtube videos and what i could manage to understand from the unity docs, which admittedly was little as I hadn’t take then time to read through it properly. The result was code that I had a very minor understanding of at the time and making changes to was something out of reach.
Looking back and reading this code now I find that I have an understanding as to what I am doing but the question of why I was doing those things is something I still didn’t have that great of an understanding of.
As network programming is an area of great interest for me and an area I would like to take my career into, learning the new system is something not only interesting but also enjoyable for me. Unfortunately, I had no idea where to start or how much difference there was between the two systems. Being someone still new to industry the solution was to ask someone who could have more knowledge than in me in this area and as such I got in contact with Steve Halliwell. Thankfully Steve was able to point me in the right direction and provide me with three links to use as reference points to figure out what on earth is going on with UNet.
Turns out there is quite a bit of required reading to gain an in-depth understanding of the way that UNet works. Although there is a large amount of reading, often there are examples provided on how elements can be implemented. With unity having a heavy emphasis on components the implementation of networking can be done with minimal amounts of code for basic functionality. Having an option to use the components to setup a quick version of networking whilst I learn to implement the network through code is incredibly valuable to me as it offers insight otherwise unavailable. By setting up networking with a heavily component orientated approach and a version with a programming orientated approach, the benefits and detriments of each system become more apparent and also allow for a quick basic setup while testing a concept.
Through reading the sources I received from Steve, my understanding of the way networking is implemented has grown dramatically (as expected when starting from almost nothing), however, it has not just provided insight into how the new system works but also in why I was doing things the way I did for the old system.
In the above screenshot of some old code of mine, I was calling Network.Destroy and checking if the networkview component was a local player’s. When writing this code all I knew was that Network.Destroy destroyed the gameobject on the server and that checking the networkview was local stopped the code running on every player in the game, what I didn’t understand was why it did those things. With the new system and my switch to writing in C#, the layout and syntax of getting the same operations to work has changed but the reasoning behind doing these things makes sense to me. For example, the Network.Destroy function appears to do the same thing as a Gameobject.destroy function, however, in a server authoritative setup, just destroying a gameobject in your local scene won’t then destroy it for everyone else. In order to do that a command is sent to the server telling it to destroy the gameobject for everyone.
Sources from Steve Halliwell: