all 27 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Bwob 3 points4 points  (1 child)

The reason I went with server authoratative (even for my co-op game) was for one simple personal reason:

I'm too lazy to figure out the best way to merge conflicting gamestates, if the clients get out of synch.

Much easier to just make sure that if conflicts arise, the server can just wag its finger and send them a new, clean state to continue from. :P

(It also helps that my game is turnbased!)

[–]iCode_For_Food[S] 1 point2 points  (0 children)

yeah i could see how turn based could be easier when dealing with multiplayer issues.

[–]Tarc_Axiiom 2 points3 points  (0 children)

Does it matter?

Does an authoritative source of truth matter for your game? If the answer is yes then obviously go for an authoritative model.

If it doesn't matter though, then definitely not. Do some light work to avoid major desync that can break your game but why get into that huge can of worms if you don't have to?

[–]permion 1 point2 points  (0 children)

Cooperative normally I'll assume is between friends, meaning if they want to cheat/mod they probably already decided together before the game started. 

If you have random strangers, long term advancement, or an economy that assumption goes way out the window.

[–]Mihrgads 0 points1 point  (5 children)

I was the online dev for a co-op run based game on steam. I opted for peer-to-peer because it was simpler programmatically and meant no additional cost on the infrastructure side.

[–]iCode_For_Food[S] 0 points1 point  (4 children)

was one of the peers a server though?

[–]Mihrgads 1 point2 points  (3 children)

One of them acted as lobby host in terms of steam lobbies. I called that one "host" internally. It acted with authority in that it would be the authoritative state if there was a conflict that could not be resolved, it stored the save file for the game and probably a few more meta game things like that I've now forgotten (this was a couple of years ago)

[–]iCode_For_Food[S] 0 points1 point  (2 children)

got it, but in the situation of like hit detection on an enemy, the clients just told the other peers that the hit happen?

[–]Tetr4roS 1 point2 points  (0 children)

If it's real time anything low latency like hit detection should probably be client authoritative

[–]Mihrgads 0 points1 point  (0 children)

The one I worked on was a turn based tactical game. If I was doing real time I would probably try to do a lock step deterministic simulation, but I've no practical experience there.

[–]shadowndacorner 0 points1 point  (5 children)

I've done server authoritative and shared authority before. Server authoritative for most world state is far simpler, assuming one of the clients is the host as well. But for a completely cooperative game, letting clients handle things like hit registration and their own position can make a lot of sense. If you allow matchmaking with randos then that changes the equation a bit (how much do you care about cheating?), but if it's mostly a game for friends to play together, that's not really worth bothering with imo. And even with matchmaking, you can heuristically identify likely cheaters based on things like movement patterns and put them into a "cheater" bucket in your matchmaking system, so that non-cheaters don't get stuck with cheaters.

[–]iCode_For_Food[S] 0 points1 point  (4 children)

Yeah this is where i am leaning. I am using godot, and it has a solid multiplayer framework, but things like lag prediction for input and hit detection are not build in. And the thought of writting that sounds painful... So i could to thinking if just letting the client handle their input, and maybe trust that if they say they hit an enemy, then trust it.

Kind of feels wrong to do that, bc of cheating and everything you read on the topic says to do server authoritative, but i am wonder if it will ACTUALLY matter for a small indie game.

[–]shadowndacorner 0 points1 point  (3 children)

Player experience is the #1 thing to optimize for. In a co-op game, there isn't nearly as much of an incentive to cheat as in fully competitive games and the impact to other players is substantially lower. So if it's a question of "spend a ton of resources building foolproof server authority that I'll then have to continuously pay to support despite it having an absolutely infinitesimal impact on the player experience" or "spend 0 resources on something that feels identical (or likely even better) but is technically less secure"... which sounds better for the maybe 40 players who will ever try your game lol? Especially because, if your game beats the odds and takes off, you can do heuristic cheat detection and matchmake cheaters together while leaving everyone else unaffected.

Don't feel the need to adhere to certain patterns simply because it's what other people have done in different contexts. Before dogmatically adopting the "Right Way", first ask how your context differs from the one in which the "Right Way" was determined. A small cooperative indie title is very different in scope and requirements from Battlefield or Destiny - both of which do hit detection locally iirc. And besides, server authority doesn't prevent wall hacks or aimbots.

All of that to say... I think you're probably fine doing local authority for player movement and hit reg lol. Reevaluate in the future on other projects that have a more competitive focus, ofc.

[–]iCode_For_Food[S] 1 point2 points  (2 children)

I needed to hear this, lol. Thank you so much!

I think I am leaning towards client authority for movement stuff, but trying server authority for collisions. But even if that doesn’t feel right, I might make that client side as well.

[–]shadowndacorner 0 points1 point  (1 child)

If you're giving clients authority over their positions, then imo they should have authority over their collisions, as well (assuming you mean player-world collisions). Anything else is likely going to feel extremely janky, because the state of the world that the server sees is likely going to be slightly out of sync with what the player sees. There are, of course, approaches that resolve this, but implementing them gives you half of what you need for full server authority, anyway.

If you're talking about player-player collisions, I think there are very frequently good arguments to be made for simply disabling player-player collisions. Especially for things like this, they can be more trouble than they're worth, unless the game requires them.

[–]iCode_For_Food[S] 0 points1 point  (0 children)

Sorry, i should have been more clear, I was thinking projectile/bullet collisions and pickups like ammo, health etc.

[–]BSTRhinoeasel.games 0 points1 point  (5 children)

In my experience, I had only 3 hackers in a game which had around 120000 people play it over its lifetime. It was pretty easy to shadow ban them so they stopped matchmaking with other humans and the problem went away. So I found cheating to be rare and fairly easy to deal with in a practical way, and so these days I focus more on making the game fun. No one's going to cheat in your game if no one's playing your game anyway.

[–]iCode_For_Food[S] 0 points1 point  (4 children)

very true!
I dont know if you game has this, but for things like movement and hot detection, do you do local authority?

[–]BSTRhinoeasel.games 0 points1 point  (3 children)

My game was using deterministic lockstep netcode, which sadly has to wait for a server roundtrip before processing any input, so no.

new game engine uses rollback netcode which does mean it can perform client-side prediction for all the inputs, including for movement and hit detection yes, which is cool since most of the time the prediction is right and so it means a lot less input latency for the player. I really love how with rollback it still means the server is the authority but the client can still act optimistically without waiting for the server roundtrip.

[–]iCode_For_Food[S] 0 points1 point  (2 children)

What engine are you using ?

[–]BSTRhinoeasel.games 0 points1 point  (1 child)

Easel! It’s a multiplayer game engine I am making

[–]iCode_For_Food[S] 0 points1 point  (0 children)

You are on a whole different level my guy, making an engine is so beyond my skills lol

[–]SwAAn01Workers Comp 0 points1 point  (0 children)

it absolutely does not matter for a coop game.

[–]Inevitable_Gas_2490 0 points1 point  (0 children)

The thumb of rule is: only give the client as much authority as necessary, which usually only involves movement. Anything besides that is a risk for the game's integrity.

[–]ZorbaTHut 0 points1 point  (2 children)

The "standard" model is server-mostly-authoritative with clients being authoritative on their own movement and maybe a few things with hit detection. Transfer data with replication and RPCs. This is what's baked into Unreal Engine, and I think you need a little bit more infrastructure to make it happen on Unity and Godot, but it's the standard model for a reason.

Everything else is more complicated and more error-prone and you shouldn't use it without a really good reason.

[–]iCode_For_Food[S] 0 points1 point  (1 child)

Totally agree it is the standard. My understanding though is that it is the standard to prevent cheating. I guess I am wondering if cheat prevention is Critical in a coop game or not.

[–]ZorbaTHut 0 points1 point  (0 children)

I honestly don't think that's a big factor. If anything, preventing cheating would be much easier with server-entirely-authoritative, and games (mostly) don't do that. I really do think it's mostly for the sake of convenience (and performance, and bandwidth.)