There are two options for networking: use a package like Boost that implements core networking functionality, or implement your own directly on top of sockets. Groups have done both over the years. Neither option is clearly better than the other, both have tradeoffs. Below are reports from groups about what they used and what their experience was.
Even though every resource says not to use TCP for games, ignore all of that advice and use TCP. We are in a high-bandwidth, low-delay networking environment, and we only have 10 weeks. You want to use a reliable, in-order transport protocol from the start, you do not want to implement your own. If you are using sockets directly, be sure to disable Nagle's algorithm (set TCP_NODELAY).
[Jungwoo] For our game, we implemented the network protocol from scratch via Winsock, and I definitely would recommend trying this out to everyone rather than relying on a library. You will learn how to put into use the skills you learned from networking classes such as CSE 122/123/124 and see it in action in an entertaining manner. Moreover, the added flexibility allows you to adjust the protocol in a timely fashion without having to refer to documentation. However, if you do not have the preexisting knowledge from other courses, it may also be a good idea to use an existing library, given the limited timeframe of the course.
We used Boost ASIO for networking in combination with Boost serialization. I think boost asio is a good library and definitely enabled our cross platform development since we didn’t use Windows sockets, but there are some caveats. First, a lot of the examples online show the asynchronous versions of the send / receive functions, when you really should just be using the synchronous (blocking) versions for 125. And second, boost is a large library and might add some significant overhead to your initial build if you do what we did and clone and build boost from source using CMake FetchContent every time you had to generate the CMakeCache.
Networking on the other hand is something we’d definitely use a library for. At the end of our day, our underlying networking code just works, and not much more than that. Using a networking library that hundreds of people have worked on gives us reliability and performance. Plus, if we were making an actual game, we’d of course use UDP over TCP to avoid the overheads of TCP, and a networking library might abstract away the technical differences of TCP vs UDP.
We used Asio, the networking library that is included in Boost. It is important to note that Asio is its own standalone networking library, and does not need Boost to run. I used the standalone Asio library, without Boost. I would definitely use it again, it was extremely simple to set up the netcode for our game. It does have a gotcha around queueing writes but there are solutions on stackoverflow. It was a stable and simple implementation that only took me a day to finish, so it was definitely worth it.
Networking: we figured that since we were guaranteed a good, hard-wired connection, and we mainly only cared about having a decent game loop without any sort of complex messaging system, we didn’t need to utilize any networking libraries that exist. And it was a fun challenge optimizing the network code
As far as the networking went, the back-end team was pretty pleased with Winsock.
We used the Boost Asio networking library. We would definitely use it again since it simplifies a lot of the work we have to do regarding sending network packets from computer to computer. At first it was hard to understand how the library works, but after looking at the example code and fully understand its internal workings, it was much easier to alter the code to suit our game networking needs. After setting up the network, it was relatively easy to add network data. We did encounter some issues using the library since we were pretty unfamiliar with it, such as having issues with implementing and using the data structures provided by the library, but after overcoming the issue, it was straight forward from there on.
We used the Boost library for networking, and it was a challenge because there were many functions that accomplished the same thing but in subtly different ways. Sometimes the documentation didn’t really describe why some functions were used instead of others, so we implemented the networking in 3 different ways before finding out the configuration that worked best.
We used the network library of SFML along with its other components. SFML was very convenient for our cross platform methodology as it handled the byte order corrections for many common types. The only problem we ran into was because we used an uncommon feature of SFML, non-blocking TCP, we ran into a bug late in development that wasted 2 full days of our tenth week. Using a low level networking library is definitely a good idea but remember, all software has bugs.
The SFML sending packet network bug was one of the most difficult we faced as we were unsure of what the problem initially was, nor were we able to reproduce it a will. It seemed to only be gotten on the upstairs machines, although this hypothesis later proved to be false. Luckily, we eventually figured out how to reproduce the problem and Bowen was looking through the source code and able to figure out why the bug was happening. What was happening was SFML sends the size then the packet, which can cause the server to believe the packet send was unsuccessful, while the client can receive the packet size and believe the packet was received successfully. The client and server will then go out of sync and are never able to recover. With the help of the professor we were able to overcome this issue. [GMV: that was a tough bug at the last minute, stressful at the time]