For the past few weeks we’ve been working on adding a second Giant, Nick the Robot, into the game. The Robot Giant is similar to the Engineer in Team Fortress, someone who can build turrets! (55 sec mark on the video) The turret detects enemy within range, and rotates to the target and starts shooting. In this video, you can see how it works, as well as the chaotic action that can occur between Giants from different teams. I was running all three games (server, player 1, player 2) on my laptop so the game gets a bit laggy sometimes which caused synchronization issues – something we continue to optimize. Also the 3D model for the Robot giant is still in development, so we are currently borrowing Lerp from the Unity3D tutorial for prototyping. :)
Creating multiplayer game logic for My Giants turned out to be a very challenging task. There are many concepts and different layers of complexity that need to be addressed in order to get good results. For us, the major decision was which kind of server logic we want to build: non-authoritative, authoritative or semi-authoritative.
A non-authoritative server exists only as a kind of proxy between all the connected clients. The server relays messages sent by clients and doesn’t know anything or very little about the game logic. All of the game logic is implemented on a client. Such setup is prone to hacking and cheating, since it is possible to change the original game logic on the client. Hacking software even exists that can automatically search and modify important game variables like lives, score, etc… On the other hand, since all the logic is on the client side, the server requires much less cpu and memory resources than an authoritative server.
Authoritative servers are the most secure in terms of cheating because all game logic runs on the server. The server contains proper game state at any moment and it can detect and override possible client’s attempts to cheat. For example, on the client side character speed is hacked in order to gain advantage over the other players. However, this does not make any difference for other players, because the server calculates the movement of the hacked player and only the server result is relevant.
Semi-authoritative server is a blend between the two aforementioned approaches, giving some authority to the client over certain aspects of game logic. For example, in semi-authoritative setup, client reports to the server when an opponent is hit and should receive damage, and the server keeps track of a player’s health status and decreases it accordingly.
In the course of a few months our networking game logic went through many iterations of improvement and experimenting, trying three networking technologies:
I’ll try to give an overview of our experience with the three technologies, some of the difficulties we had and a few core differences. Our networking logic is still in development and there will probably be other observations as we progress, but this is as good time as any, to share some of the things we picked up along the way.