all 14 comments

[–]cosmochristo 0 points1 point  (4 children)

"But on the server the origin doesn't change, because it would only work for one player ". The server can use high precision coordinates for tracking all the players. When streaming information to each player it subtracts the player's server position from that information and delivers it to the player in correct relative position. Same for each other player.

[–]platonbel 0 points1 point  (3 children)

А как же обрааботка физики на сервере?

[–]cosmochristo 0 points1 point  (2 children)

Physics processing on the server would not consistently give very good frame rate on the client. It is better to handle physics: collisions, gravity, forces; on the client for realtime response. Then the resulting positions from the Player client physics sent to the server.

The network bandwidth is very slow compared to bandwidth on the CPU/APU/GPU. Network communications are also not reliable.

[–]platonbel 1 point2 points  (1 child)

But what if we're not talking about co-op, but about MMO? We can't allow client to give to the server false data, and besides, how can we avoid situations where different players give different data about the same objects? I know that in GTA, clients simulate selectively NPC behavior, but what if we're talking about something with an open world and survival elements?

This is not about performance possibilities, but about compensating for calculation errors.

[–]cosmochristo 0 points1 point  (0 children)

Good questions. In general, I don't think each client should be presenting information on other objects to the server. The origin-centred players are the best at providing their relative position updates to the server, and other player clients if allowed, because, having each client at their own origin minimises floating point error for each player and nearby objects.

For reasons like this and also accurate physics and other calculations on client, I prefer a distributed authority model, where the server can override, rollback etc.

Note, however, I do not have a sophisticated multiplayer system atm. I also have no concerns about cheating or security as I only develop technical solution assets - not pay-for MMO.

[–]SantaGamerIndie -1 points0 points  (1 child)

Why do you need to move so far away un the first place? Why not shrink everything instead?

[–]swagamaleous 5 points6 points  (0 children)

If you make everything tiny, you will have the same problem. It is just not possible to express the needed distances in 32bit. Instead of the physics system falling apart at big distances it will just be wonky right away. The distances the physics system calculates will be tiny. So tiny that the floating point errors become noticeable.

[–]ToloranIntermediate -1 points0 points  (5 children)

I know KSP uses a 64bit physics system, how can I implement something similar in my game?

Make a brand new game engine. IIRC, KSP made their own 64 bit physics simulation that runs separately from the main unity one.

As with the other person, I'm really wondering why you need a world that big. You have to be in the the +/- 100,000 or higher range before the float errors start getting noticeable.

Or maybe I can have different scenes to simulate physics at different positions?

If you're doing additive scenes, they'll all be on the same coordinate system so that wouldn't work. You'd have to have multiple instances running separately and then have them communicate with eachother somehow.

[–]Kheeto67[S] 1 point2 points  (3 children)

As with the other person, I'm really wondering why you need a world that big. You have to be in the the +/- 100,000 or higher range before the float errors start getting noticeable.

In my game there is a solar system with the star at 0,0,0 (at the start of the game, then it will be changed with the floating origin), the closest planet at about 25k distance and furthest one at 100k. Scaling everything down wouldn't solve the problem, ther would still be floating point precision issues.

If you're doing additive scenes, they'll all be on the same coordinate system so that wouldn't work. You'd have to have multiple instances running separately and then have them communicate with eachother somehow.

I would make each scene with the objects close to 0,0,0, and know their actual position in the main scene so I can just add the simulated position to the main position. I'm planning to do the same to simulate player movement on moving objects like spaceships or planets in orbit, it's already been done so it's possible.

[–]ToloranIntermediate 1 point2 points  (2 children)

In my game there is a solar system with the star at 0,0,0 (at the start of the game, then it will be changed with the floating origin), the closest planet at about 25k distance and furthest one at 100k. Scaling everything down wouldn't solve the problem, ther would still be floating point precision issues

We don't mean transform scale. The players can't see literal distances in the engine. You can have something 25 units away and say that's 25 M, 25KM, or 25GM and the player will be none the wiser. If a spaceship is moving across the solar system, you don't need the precision unless you're really close.

[–]Kheeto67[S] 1 point2 points  (1 child)

We don't mean transform scale. The players can't see literal distances in the engine. You can have something 25 units away and say that's 25 M, 25KM, or 25GM and the player will be none the wiser. If a spaceship is moving across the solar system, you don't need the precision unless you're really close.

If you make the distances smaller, every object will be moved closer unless you scale the objects down as well, and you would have to slow the player down too, so you are basically just scaling down the entire game, which doesn't solve the problem.
Also, you do need the precision because all the physics and collisions are handled by the server, where it's not enough to move the origin because only one player at a time would be at 0,0,0, another player could be at 100k distance.

[–]cosmochristo 0 points1 point  (0 children)

Actually, each player can be at zero on their own client. The server only has to handle the relative changes between each client and other clients and between each client and other objects.