So I’ve been slowly implementing basic multiplayer to a demo project of mine, currently nothing special. I’ve made a few games in singleplayer and have a decent grasp on the engine in that regard, and so far things are going well with my demo project. Outside of Godot I have limited experience in networking, and often when studying multiplayer I read comments in regards on how some people will try to use games to compromise other users PC’s and it’s made me paranoid on continuing to learn how to develop multiplayer games.
Before I become dedicated in attempting to make a multiplayer game, I wanted to know some not-so-obvious do’s and don’ts you may have in regards to creating a multiplayer game? I understand you want to put as much as you can behind the server and to trust the client as little as possible, but is there more to it than that? What are some ways to avoid making a product that can compromise user’s computers? Are the official starter documentation guides to developing multiplayer games in Godot safe ways to begin a multiplayer project? I worry that because I am not savvy enough with networking that I will miss something fundamental and cause harm to hypothetical/potential players.
Thanks for any response
Thank you so much for asking this question! More game devs should be asking, because it’s too easy to turn your game into dangerous malware for your players if you’re not careful.
So, implementing networking is a big topic. Networking is basically remotely sending instructions from one computer to another. This can happen either directly (Peer-To-Peer), or indirectly (Client-Server). Problems arise when a user can send instructions to another user’s machine that that the host does not want. These bad instructions can be extractive (the host computer exposes sensitive information) or destructive (the host computer deletes some critical information).
Unsafe games provide ways for malicious users to manipulate other users’ computers to do funky stuff. If you limit and control the type of signals the host machine receives and processes, you will have a more secure game.
Some common exploits include sharing user-generated content. Say, in your game, a user can upload an image for their avatar. This image is then propagated to the machines that the player plays a game with so that those users can see his avatar. A clever user can actually write a small program that can pretend it’s an image and can use an exploit in the software renderer to execute that program at soon as your game tries to load it into memory. Now they have remote code execution on that host’s machine. This is the reason why many multiplayer games don’t allow players to host images like avatars and graffiti tags anymore.
Another way you can improve application security is by taking care of the information you let a user propagate to all clients. Say a user needs to create an account in order to go online. They need to enter and verify some personal information to create that account. Some of that information might be critical to gameplay, like an IP address or geolocation or scoreboard, like an email or name and phone number might not be. But if you’re not careful you could broadcast each player the whole profile including sensitive information to all peers even if the client is not actively using that information. A clever user with access to profiling tools can scrape that sensitive information directly from memory.
Less harmful, but annoying consequences is dealing with DOS attacks, botting and cheating, performance and consistency. This is a problem for anonymous and real-time games or games that broadcast a full gamestate to all clients. There are plenty of resources on how that’s done historically.
You really need to be conscious of how your game can influence the host machine and what signals it can propegate.