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.
Thanks so much for the reply!
Yeah, I think that’s a really important callout. For this game, I’m actually not really planning on having a leader board or true progression tree of any kind. I was planning on doing unlockable cosmetics, which I suppose could be enough impetus for some people to hack. I think the ethos of the game is primarily just to be one-off rounds for fun, but perhaps it’s still naive to believe that will not motivate people to still hack.
Probably a big reason why folks don’t mind this pattern for online co-op as much as online versus.
Thanks so much for this resource. I’ll give it a look!
I think what you’re getting at with using multiplayer api nodes in the scene tree is essentially something like this:
This was something I was conceptually thinking through but haven’t fully wrapped my head around just yet. Your repo looks like an awesome resource for digging into this. Thank you for sharing!
The only downside for a “branched” multiplayer setup like that is it means you will be running a host and client on the same thread. Which might get you into trouble at some point, especially if the game gets really complicated. You can easily spawn multiple processes from the editor with debug “run multiple instances” option and provide command line arguments or a feature to designate a server or a client. That will give you two process on different threads at least.
In that video Glen talks about snapshot-interpolation as the preferred option, saying that (the video is from 2015) in 10 years you can get away with snapshot interpolation when the world has higher bandwidths. We definitely have higher bandwidths, but the consideration you need to make is would the host have enough bandwidth to support all your players. But you will still may need some state synchronization for the remote player to give the illusion of actions happening immediately.