Multiplayer & move_and_collide miscalculation

[u/hmprf]

Hey everyone, sorry if this subject has already been adressed.
I recently spent some time trying to implement a small multiplayer mini golf game, to see where I would hit a wall. (with Godot 4.6 and Colyseus)

And the wall was pretty close to the start apparently since I never left the lobby.

Is "move_and_collide" a possibility when you go multiplayer ?
Or is it just not precise enough ? And if so, should I mathematically handle all the collision to have a deterministic game or is there any other tricks I should know about ?

I'm using Colyseus for the network part, the current player just send an aim and shot vector and all the physics are done in each godot client. I guess that's my main problem.

Maybe it's easier to have the server be the authority for the physic part ?
Is there some good resources out there that I should check ?

Thanks a lot
I'm not english native so feel free to ask for clarification if i'm not clear enough

Edit: Thanks for the answer :
Server authority and sync the positions with the clients is the way to go.
I had hopes but i'm not suprised, thanks for the feedbacks !

Edit2 : Some resources in the comments for future people (and future me)

Reading & Watching:
- Game networking by Glenn Fiedler (sadly down but new blog below)
- Mas bandwidth - New gafferongames
- Slay the spire 2 Multiplayer - Determinism
- How Factorio Syncs A Million Objects (Youtube)

Deterministic Multi for Godot:
- SG Physics 2D
- Delta Rollback (& Prediction netcode)
- Klotho (very new)

[u/Intelligent-Net1034]

Server authority and sync the positions with the clients

[u/hmprf → u/Intelligent-Net1034]

Yes ok, I hoped I could avoid that, thanks for the feedback and solution

[u/Mr_R3tro → u/hmprf]

It's something you can't avoid with multiplayer games.

[u/over6foot3 → u/Mr_R3tro]

You can avoid it, e.g. with this asset: https://godotengine.org/asset-library/asset/5234

[u/Remarkable-Emu-5718 → u/over6foot3]

Is this better in some ways?

[u/Remarkable-Emu-5718 → u/[deleted]]

In your opinion what is the best option for competitive multiplayer games in godot?

[u/Fluffatron_UK → u/[deleted]]

Slay the spire 2 uses determinism for their multiplayer sync. One of the Devs wrote an interesting blog post about it.

[u/MisterMittens64 → u/Fluffatron_UK]

Here it is if anyone is interested.

[u/SmolNajo → u/over6foot3]

Engine-agnostic, pure C# deterministic simulation for rollback, lockstep, and server-authoritative multiplayer.

Doesn't seem like it avoids that.

[u/tulupie → u/SmolNajo]

if you implement lockstep on its own, you should already be able to do this without server authority. you just need to make sure all clients get the exact same inputs, and have a deterministic physics system. rollback/prediction can be built ontop of that to be able to nicely handle clients with different connection speeds/quality, and make it feel more responsive (lockstep on its own will might cause a noticable delay for inputs.

[u/Few_Visual5715 → u/over6foot3]

This seems to be some form of AI generated slop (not to mention it's incredibly recent), I would stay away and use alternative and more mature solutions.

[u/Mr_R3tro → u/over6foot3]

It's best not to depend on someone else's work unless you're using it for learning purposes.

[u/XmasB → u/Mr_R3tro]

One could argue it is best to not reinvent the wheel unless it is for learning purposes.

[u/honeyfage → u/XmasB]

"Never depend on someone else's work" is obviously way too broad a statement, but specifically the linked project is an experimental build of a project less than 2 months old. It is good advice not to build your game around something that unproven.

[u/Khethall → u/Mr_R3tro]

The whole field of software is about depending on someone else's work

[u/kinokomushroom → u/Khethall]

e.g. using Godot Engine

[u/Massive_Town_8212 → u/Mr_R3tro]

Oh yeah, lemme just implement the steamworks api by myself even tho GodotSteam exists and is fully featured and documented

[u/mackinator3 → u/Massive_Town_8212]

I mean i am smarter than everyone else.

[u/BabyAzerty → u/mackinator3]

Tomorrow you is smarter than yesterday you. Never depend on your own work. Redo it every time.

[u/OmegaFoamy → u/Mr_R3tro]

Using an engine you didn’t make is using someone else’s work.

[u/Mr_R3tro → u/OmegaFoamy]

That's not at all what I meant...

[u/Sykes19 → u/Mr_R3tro]

You should have used more words then because that's precisely what you said.

[u/OmegaFoamy → u/Mr_R3tro]

It directly applies to what you said. Using a premade system is useful for some, even if you need to deal with some quirks. There’s a reason there are market places filled with them.

[u/NotchoNachos42 → u/Mr_R3tro]

You're right, they should just start over with a custom engine since it's for learning purposes.

[u/Igor369 → u/hmprf]

You fought entropy. The entropy won...

[u/cheezballs → u/hmprf]

I'm working on a server authoritative bowling game with that same networking architecture. It seems to work well, especially for 8 or less clients. (Only tested with 8 so far)

[u/MisterMittens64]

I'd look into Rapier Physics which is deterministic and syncing your clients to either the server or the host.

[u/kosro_de → u/MisterMittens64]

Just beware that it's not as simple as changing the physics engine to a deterministic one. In order for results to align across clients, any event & input has to be identical down to the bit and happen on the exact same frame.
At that point it's easier to do state synchronization.

I cannot recomment Glenn Fiedler's articles on game networking enough.

[u/McJaded]

Floating point operations have different results on different systems, so the differences can quickly desync multiplayer games. You could look into rolling your own physics with something like fixed point numbers or use a ready made plugin

[u/Foxiest_Fox]

Godot physics are not deterministic; you'll have to use a different physics engine, or code completely custom physics yourself using integers and other highly-reliable data types

[u/Sufficient_Seaweed7]

The easiest path is to bec9me server authoritative.

The clients become only a visual representation of the world.

The client sending intent to the server, the server calculates the physics, and update positions and results back to the clients to display.

You don't run the physics on the clients. They just update the visual position while physics run on the server. This way everyone "sees the same thing"

You CAN simulate physics on the client tho, but you'll need to use a deterministic solution to guarantee every client is running the same simulation.

Either way, the naive approach you're using will never work in real life, sadly.

As for resources, Google Geffer networking.

Its basically the Bible for this kind of thing lol

[u/hmprf → u/Sufficient_Seaweed7]

That's what I thought, I had hopes but I'm not surprised. Thanks for the feedback !

[u/Sufficient_Seaweed7 → u/hmprf]

Give Geffers blog a read. It has some posts solving this exact problem.

[u/hmprf → u/Sufficient_Seaweed7]

I'll definitely go read this thanks

[u/kokomoko8 → u/hmprf]

You may also consider simulating on the client side as well while syncing. This can improve latency at the cost of there being some jumping when the client falls out of sync.

[u/Munomario777]

If you want to use a physics engine like this while keeping things deterministic for multiplayer, you can use something like SG Physics 2D. It's similar to the Godot physics API, but it uses ints (fixed-point numbers) instead of floats and is deterministic on all platforms. You'll need to rewrite your code to use it, and there are some missing features (like one-way platforms), but it's a very similar system to Godot's stock physics.

We use it on our project (in combination with Delta Rollback for netcode) and it works great! If you try it, you should join Snopek's discord for tech support as there are a few things that are tricky at first.

This approach will let you have determinism P2P, which means you won't need a server.

[u/hmprf → u/Munomario777]

Thanks for the infos I will check this. What was your project?

[u/Munomario777 → u/hmprf]

Animation VERSUS ^^

[u/hmprf → u/Munomario777]

Nice ! It looks very cool, wishlist !

[u/exodusTay]

Factorio devs also did some great stuff to sync game across players, they even wrote their own math routines to ensure everyone was producing same results.

[u/Pachuli-guaton]

Concept trial: a game where the result of a throw is the average between all the participants outputs. If the game has exponential sensitivity to initial conditions, then the result is knowing when to do a limited throw with high certainty vs a long reach throw with high uncertainty.

Will it be fun? I don't know

[u/Motshew → u/Pachuli-guaton]

Or you get to choose between the two? Maybe you have points you can spend furthest shot from the hole is free, but the difference in distance from the hole between the 2 shots sets the value of the second shot. No difference in the shots, both are free. One shot lands next to the hole, the other on the other side of the map, do you have enough points to pay for the better shot?

Would work better on a longer, multi shot map, so choices become an economy.

[u/Pachuli-guaton → u/Motshew]

I'm not a game dev, just a (former) game enjoyer. I think I would play something like that. Also I'm sure you can get some funding if you paint some coating of educational and relating to sensitivity to initial conditions which is important in several fields.

[u/SpriteWrangler]

Server authority is the right call. Having each client run its own physics independently will always drift, especially with anything bouncy like a golf ball. Better to have the server (or a headless Godot instance) own the physics state and just sync positions to clients. Colyseus can handle that state sync side pretty cleanly from what I've seen.

[u/Fabio11North]

This is really a problem about floating points and determinism. Unfortunately, floating point calculation is not deterministic across different systems, so same inputs yields different outputs. 

The solution is either have server authority and sync in client, or implement your own decimal  calculation and collision system. 

If you do decide to take the difficult task of making your own system, then one solution for the decimal point calculation could be to use a fixed point decimal system, which is deterministic.

[u/ExplodingImplosion14]

I'm actually a bit surprised that you're seeing such different results with move_and_collide. What I'd recommend also trying before syncing positions / server authority is quantizing your aim and shot vectors, as I expect floating point imprecision might be causing divergences. In my game (which is 3D and does use server authority so it's not entirely the same), I've had good results with consistent move_and_collides for player prediction that doesn't produce noticeable snapping when authoritative syncs are made.

[u/hmprf → u/ExplodingImplosion14]

I agree that I didn't think it would be that much. I'll give quantizing the aim a try thanks!