Since we essentially wanted to make an FPS game since our group was created, a lot of the
networking research was done with this in mind. The first place that we went to was the GDC vault. Though there were not many results by searching for “networking”, we found one talk that was immensely useful for us, especially in regards to tips for creating a functional, lightweight networking architecture. The talk “I Shot You First: Networking the Gameplay of HALO: REACH” by David Aldridge gave a lot of insight into the approaches of AAA developers for writing the networking for FPS games. One main takeaway from this talk was the idea of each object that needs to be networked having a priority number. Data from high-priority objects gets sent over the network more often than low-priority objects. However, the idea is that all objects get synced up and gets their data sent eventually. As a result, the networking architecture becomes “scalable”. Players with lower bandwidth will have a smaller amount of data sent to and from their machines, but they will get all data eventually. The difference between high-bandwidth and low-bandwidth players is that low- bandwidth players will receive mostly high-priority object data, where as a player with almost unlimited bandwidth will receive all data regardless of bandwidth equally. The talk also goes through common simplified approaches to networking, such as deterministic networking, the TCP protocol, and the Quake method of constantly sending all game data in one blob. Finally, the talk goes into detail regarding the networking protocols of Halo: Reach, and ways to integrate these protocols into your own game. This part was especially useful regarding ideas on how to structure our networking architecture. If we were building our own engine, we would likely base our networking architecture around a simplified version of how it is done in Halo: Reach.
36
One problem with the Halo: Reach networking architecture is the fact that networking is done through clients acting as servers, with no central server involved. If we needed to host a server, we would take advantage of server space given to us through Microsoft Azure, and as a result, we looked at client-server architectures used in FPS games. The main example that we found was the Source Multiplayer Architecture, in which the server takes precedence over state events and positions of objects. One main tactic were planning on implementing before using the Unreal Engine is server- side lag compensation. The way this works, is that the server keeps a record of where all plays are from a second before the current time, up to the current time. When bullets are fired, the server estimates where the other players were on the client’s computer when these bullets were fired, and attempts to calculate a hitbox to see if the bullet hits anything. This way, we can tell if the player shoots who he thinks he shot, even with significant lag. By reading the Source Multiplayer
Networking documentation, we were given insights into how to handle problems like low bandwidth and lag. Since the server code is open source as well, we have downloaded the code and are planning on taking a closer look at it to get a good idea of how AAA-grade networking architecture is
constructed from a programming standpoint.
Finally, in order to get a good handle on creating an engine’s networking, we first needed to get a good handle on game networking and learning all that we need to understand in order to have our networking layer running as quickly and smoothly as we can. Our main tutorial on setting up a networking interface was Glenn Fieldler’s tutorial, “Networking for Game Programmers”. Glenn Fielder currently works at Respawn Entertainment. This tutorial starts at explaining the difference between TCP and UDP (and which protocol we should favor, goes through concepts such as virtual connections, reliability and flow control, and multiplayer debugging, and ends with a brief history of FPS multiplayer games, and the growth of the genre.
Overall, though there aren’t many super-advanced strategies and algorithms learned from this tutorial, this base of knowledge is of immense help in the development of the networking component of our game.
Upon beginning of our capstone project in the Unreal Engine, much of the research dealt less with designing a networking architecture and more with researching how to best utilize the Unreal Engine in the context of our game. Unreal has networking “built-in”, but a lot of the documentation surrounding it consists of a series of tutorial videos and definitions of the classes involved. Though this may be excellent in getting a basic game running, extending this architecture to include features such as an in-game lobby was a full-time task. Implementing many networked menu features using the Blueprints feature available in Unreal Engine 4 proved challenging, especially since the testing and documentation for the Unreal Engine was not as plentiful as that for the Unity Engine, for example.
The main resource utilized for learning Unreal Engine’s networking architecture was Billy Bramer’s Blueprint Networking Tutorials, found on the Unreal Engine’s website. This resource consists largely of a series of YouTube videos, starting with basic networking terminology, then running through simple networking demos, then finally running through adding networking features to an existing Third Person Game template. This site was an excellent source to get started on Blueprints in Unreal, as well as how to properly structure your code so that it does not get too unwieldy. However, one issue was the lack of supporting documentation on the project if you did not want to watch a YouTube video. In addition, the videos did not delve into a lot of the modules and pieces of the Unreal Engine that you would need to work with to create your own networking features. Overall, this site gave us a good start into networking with Unreal Blueprints.
38