Deciding on multiplayer architecture for Steam

Godot Version

4.7

Question

Hey all, I’m working on a new online multiplayer game idea that I’m quite excited about, but I’m conflicted on how to structure the multiplayer architecture. Preface: I’m a pretty seasoned software developer, but new to game development (200 hrs of experience?) and very very new to online multiplayer (never done it). I’m getting the sense that if I just build this game in single player first without having a super clear idea about the multiplayer architecture, I’m going to create massive rework for myself in the future.

The end goal is a PVP battle game launched on Steam only that relies on launching projectiles at each other with a zany, Gangbeasts-style physics feeling. As such, I was planning on using a variety of projectile objects as RigidBody3Ds and I also want to have ragdoll mechanics for players. I realize that the physics are going to be non-deterministic if left to the clients on their own, so there has to be a plan in place.

At the moment, in the spirit of simplicity and being “good enough” in most cases, what I am thinking of doing is leveraging GodotSteam and using a host-authoritative structure where the host player as both a battling player and the authority on the physics for the rest of the players. Other clients would interpolate the projectiles and other physics things going on based on the host player, while the host player runs code to register valid hits/misses. This seems dramatically simpler to me (which is a real consideration when trying to launch my first game end-to-end), but I won’t do this if it’s a massive misstep.

It seems like server-authoritative would probably be the better fit for this game style, but just taking a look at the process of creating and deploying a dedicated server for the game, the overhead and dev complexity seems obviously much more significant.

Do folks have recommended resources or videos they’ve liked on this subject and the tradeoffs for each approach? If I do go with host-authority P2P, are there any major pitfalls I should watch out for for this style of game? Basically just trying to make sure I’m headed off in the right direction before I get dozens of hours into the project.

Thanks!

Hacking. Basically the host player has control of the physics server and can do all sorts of packet injection or other things to hack the game. But as long as your leaderboards are just for bragging and no item acquisition, game credits, or real money changes hands you shouldn’t have a problem.

Glenn Fiedler is a good resource. https://www.gdcvault.com/play/1022195/Physics-for-Game-Programmers-Networking

He also has an article series on this talk as well.

“state synchronization” is his solution for non-deterministic physics. Just send state fast enough from the server to mitigate client physics deviation.

In regards to structuring your game i think a clear separation of synced data from behavior will set you up nicely for multiplayer code. Input is a good example.

But considering self hosted servers you can always use multiple multiplayer api nodes in the scene tree to segment your “dedicated server” from the client on different scene branches (here is my postponed tool ). Or you can spin off a server process easily from the host client. You will still need a central hub for players to find eachother or match making. (I assume you will use steam api)

If you want to implement some sort of reclamation to replay a physics state on late input data. I havent seen a good solution yet for godot, since no one has tried to man-handle the physics engine or… run your own temporary physics steps? Not sure whats feasable.