Daily news, dev blogs, and stories from Game Developer straight to your inbox
Sponsored By
Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.
P2P Network decisions of Jobchanger Brigade
Given the difficulty many people have with starting up networking for their games, I've made available the reasoning behind many decisions of networking programming in my game, alongside resources I found useful.
6 Min Read
Disclaimer
I'm not a networking specialist nor have I ever shipped an online game, although I have shipped other games and have also made a small game with similar gameplay and online support. Also, the online structure of the game currently requires one of the players to be the server, although changing that to allow the server to run as a separate process would not be too hard.
Introduction
Designing a good network structure for a game is tough. Building a game, even without networking, is tough work too. So making your first game networked does not strike me as good idea. Also, the difficulty of adding network support will often depend on the game. MMORPGs and fighting games are both difficult, but for very different reasons, for example.
Jobchanger Brigade is an co-op action game. So there are a bunch of things which I don't need to worry about, which you may have to worry for your game (like having 300 players in a city, good luck with that). So I believe one of the first steps would be to do some research on how similar games handled it. For Jobchanger, I found that Terraria was fairly similar and found this resource on how networking worked.
It served as good reference but I ended up doing many things differently. It goes way more technical than this post so it'll likely end up being a better resource if you're making your own network structure. Here is another good resource by Gafferon Games (dude ended up working on Titanfall), especially if you don't know what sockets are. Finally, some footage (a bit outdated) of the game running 4 times on a single machine in P2P.
Technology
You must be aware of how the framework you're using handles networking. If you can get access to a TCP socket you should be set to start. But if you can get something higher level on your framework, please consider using the higher level solution, because it can save you time and maybe help avoid bugs (it could have the opposite effect though), so do some research if the higher level solution is suitable.
My game uses LibGDX, a Java game programming framework, so Kryonet (a very good Java networking library) was a very fitting solution. I don't ever have to touch the sockets directly and the code is very understandable.
Client-side logic and Server-side logic
I believe this is the toughest question and the one that made my head spin while thinking up the code. How smart should the client be? How much of game logic should the client hold? Every decision you make here will imply a lot on how the game handles and on things like cheating: the smartest the client, the easier to cheat.
For Jobchanger, I decided to not worry about cheating and just focus on finding an easy, clean way to adapt my existing code (the one I reuse between projects) in to networking. This resulted in a very smart client, which has two effects: connectivity issues like lag and latency won't affect gameplay so much and cheating may be a bit too easy to do. This will be made clearer on the implementation examples.
Multithreading
Another thing to keep in mind is that you'll likely be working in a multithreading scenario when networking. Which means bugs will pop up and they might be bugs that appear under some very specific conditions. The more you concentrate logic in a single thread, the more you'll be avoiding multithreading bugs. I'll illustrate some of those bugs I have found so far in the implementation examples.
Implementation examples
Movement: instead of sending input data, like which buttons the player pressed to move, I opted to send in the player's position. This assures that everything is where it's supposed to be at every frame. I also send in the velocity, to make it smoother in case of a possible delay.
As for the player's movement animation, I send an message whenever a new animation starts, which solves all animation problems for good. Those messages are sent to the server and propagated to all connected players.
Multithreading bug encountered: at first, as soon I received the message with the player's position, I would set it directly. This would make the game crash because I was using an physics simulation framework called Box2D, which crashes when you try to mess with the physics during it's inner calculations, something that happened sometimes since I was working on two threads at the same time.
Attacking: attacking occurs normally as in the offline experience. Only an attack id is sent to the server which then propagates to all players. This means that the entire attack logic is running in every player present, the difference being that the only attack which causes damage is the one of the original attacker. This ensures that damage will only get counted once. This also means that a cheater could kill all the monsters in the game if they could fake the message.
The advantage of this is that a player can receive damage feedback of his own attacks as soon as it happens, instead of waiting for the damage confirmation to come from the server. I might add some cheat detection to this in the future or even move it to the server entirely, although I enjoy the current system.
Multithreading bug encountered: similar to the bug in the movement section, bugs were caused by running attack logic from the networking thread, which would cause physical objects to be created during inner calculations, crashing the game.
Monster AI: this part only runs in the server. Monsters in the client-side just stand there doing nothing while waiting for instructions from the server-side monsters, who can actually initiate attacks and take action
Monster attacks: similar to player attacks, the entire logic runs in all players, but they can only hurt a player in their own game. So if a player gets hit in somebody else's game but not on his own due to whatever reason, he won't get hit. This sacrifices a bit of the overall synchronization of the scene for a better individual experience. This is a necessary choice for this design because an important focus of the game is on enemy attack dodging and running that anywhere else would ruin the game.
Final considerations
My implementation is very naive but it's also very flexible and not too complex so far, so I hope those pros outweigh the future issues I may have to face in the future. Hope this helps anyone who's having trouble getting started with networking.
Read more about:
Featured BlogsAbout the Author(s)
You May Also Like
