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).
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.
[Brian] For networking, we used WinSock which was provided as a skeleton code by the professor. I personally would use the WinSock code again. We had to set up packet types and structures which was really interesting. John and I learned this from 123 which was really helpful. After the initial setup of WinSock, we really didn’t know how to have code to actually work over the internet like using sockets and IP. The skeleton handled that really well for us. I would like to learn how to set that up myself eventually and get it to work on other operating systems. After working with the physics engine Bullet, it made it easy to see how stuff should be done like handling physical objects like planes or rigid bodies. I originally wanted to start with a self built physics engine, but we defaulted to bullet. It has brought a lot of insight and would love to make our own in the future. For bullet, don’t use mesh objects to represent OBJ files.
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.
Having completed the network in week 2, I didn't really discuss networking with any of the other groups. My networking code worked well enough.
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]