One of our final courses at The Game Assembly was a Specialization Project. Since my biggest passion lies with gameplay programming, and I was very intrigued by network programming, I decided to combine the two and add network to a singeplayer game we did in our first year at TGA.

The game I chose was Lazer Cat, which is a 2D shoot 'em up that I thought would be perfect for a 2-player co-op. I knew from the start that this would be a challenge, not only was it to network an already made game, but it also happened to be the first C++ game we made at TGA. But I was up for the challenge!

My main goal with this project was to get a better insight in what it's like to work as a gameplay programmer in a networked game and to better understand what happens on the Network side.

When we made this game, we were fairly new to C++: we didn't know how to use the language efficiently, or how to write managable and easy-to-read code. So, the first couple of days of the project were spent solely on refactoring code, and especially optimizing it.

Since I had already worked with dedicated servers in the Network course, I decided on a peer to peer network for this project.

Connection menu
connectErrors disconnect
Host offline/invalid IP/full game If client disconnects: wait for client.
If host disconnects: promote client to host.
The game is still playable at around 50% packageloss or 500 ms lag: it won't be the best game experience, but it is playable. Anything above that, and both players will be disconnected.

Handling the bad connection was the toughest case to handle: it was hard to know what was happening when problems occurred between two different computers and debugging was tricky.
This was one of the most educational projects I have worked on. I learned a lot when it comes to coding during this project, but I also got a lot better at structuring and planning my work. This was mainly because I put a lot of focus on time estimating tasks. After finishing a task I evaluated the end result, and then tried to apply that to similar tasks.

When I planned this project I didn't account for unforeseen problems or that tasks might take more time than anticipated. This forced me to revisit my plan several times and I ended up having to cut away a whole sprint. This was a very good lesson however, and is something I am going to bring with me to upcoming projects.

Now that the project is finished, I am very proud of what I have accomplished. Despite the short time frame, and having had to re-scope quite a lot, I am happy with the end result. I learned first hand how hard it is to network an already made game, but it was so much fun and I have learned and grown a lot, both as a programmer and a game developer.