So, we all know that playing online games with your friends is fun, but how about making a multiplayer game?
While I've had the luxury of working on an online FPS at High Moon Studios as a multiplayer engineering intern, the rest of the team has never developed an online game, ever. It's been super interesting (and yes, fun) to be "the networking guy" responsible for either A) networking the entire game alone or B) teaching some team members how networking in Unreal Engine 4 works.
I do not want to network an entire game alone, especially not an FPS. This particular genre requires some of the most intensive net-code; it has to be responsive, clear, and completely synchronized as accurately as possible. To do that alone in this time-frame would require all of my time, and that just can't happen. So, I've been teaching as I go through with developing the core network systems of the game, leaving instructive comments and various documentation in my wake. I also try to give people one or two tasks that need a networked component, and then have them attempt it on their own. Since we're all developing in blueprints (I'm going to return to this later), they can use my work and replicate those patterns to solve their own problems. It definitely helps that the programmers (except me) are all taking a networking course right now, but UE4 has a very high-level API for networking functionality, which this course doesn't cover for awhile.
I know that one of the programmers has been having good success networking on their own, although they're only handling server-side operations for their developer tools, so they haven't gotten the chance to take on client-server communication. Another programmer, however, has been finding it a bit difficult to wrap their head around. Since network programming in Unreal handles client-side and server-side code in combined files, you have to program in all the versions at once. This makes for confusing execution paths, especially when dealing with Blueprints. I'm not really sure how to help clear up that thought pattern, although if they need help on another networked task, I'm going to show them a method that I use when proof-reading net-code. I'll go through all of the possible execution paths based on server or client permissions, acting our a specific test scenario as either a client or a server. I can usually catch the vast majority of my logical errors, and even issues with client-server communication and execution order. Doing this little process feels a little slower, since I spend a lot of my development time reading and re-reading all the code related to my feature, however, I spend so much less time debugging and testing broken net-code (which is often frustrating).
Now, back to the blueprints note from before. In pretty much every case, we should be developing core systems in C++ and exposing the necessary members & functions to blueprints for our front-end team to implement in gameplay. That's the more computationally efficient and safer method of development. We chose to develop primarily in Blueprints way back in September at the start of the project, because only I had experience in both blueprint and C++ development in Unreal. The rest of the team had only placed assets before. I pushed for blueprint-only development due to its low learning curve (as opposed to Unreal's C++ API), as well as the prototyping speed that blueprints give. Unreal's C++ pipeline is fairly slow, especially when compared to Unity's C# compiler, but blueprints can be compiled nearly instantaneously, and have much, much clearer error and warning messages. Additionally, there are way more UE4 Blueprint resources than UE4 C++ resources. It turns out that this initial decision was the best one to make. Everybody is developing using the same tools, so we can all bounce off of each other for bug fixing and just general advice. Our designer who's been implementing most of the weapons is able to ask our UI programmer about how to implement the UI, and both understand blueprint syntax well enough now to be able to communicate easily. If the UI programmer only had real experience in C++ and no blueprints, that communication can't happen as fluidly.