![]() ![]() P2P connection gave us a lot of headache during tests, because the servers were behind the router and the NAT punch-through functionality didn’t work as expected. At that point, we only used peer to peer connection and we didn’t even think about the idea of having a headless server running on a cloud or VPS. We had basic movement and animation synchronization done in a matter of days. M2H Tutorials), which helped us a lot in the beginning. There are a lot of examples and nice tutorials to learn about Unity networking (i.e. Our intention was to create a working prototype in a fairly short amount of time. Through Network Views, using State Synchronization and Remote Procedure Calls, any kind of multiplayer game logic can be implemented. Network Views are components that make game object network-aware. Unity Networking is nicely integrated into Unity and works very well for rapid development. With almost no prior experience with multiplayer games, we started using Unity built-in networking as it seemed the easiest approach. 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. 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. In the course of a few months our networking game logic went through many iterations of improvement and experimenting, trying three networking technologies: 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. Semi-authoritative server is a blend between the two aforementioned approaches, giving some authority to the client over certain aspects of game logic. 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. For example, on the client side character speed is hacked in order to gain advantage over the other players. The server contains proper game state at any moment and it can detect and override possible client’s attempts to cheat. 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.Īuthoritative servers are the most secure in terms of cheating because all game logic runs on the server. ![]() Such setup is prone to hacking and cheating, since it is possible to change the original game logic on the client. All of the game logic is implemented on a client. The server relays messages sent by clients and doesn’t know anything or very little about the game logic. For us, the major decision was which kind of server logic we want to build: non-authoritative, authoritative or semi-authoritative.Ī non-authoritative server exists only as a kind of proxy between all the connected clients. There are many concepts and different layers of complexity that need to be addressed in order to get good results. ![]() Creating multiplayer game logic for My Giants turned out to be a very challenging task.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |