Heho,

i need some thinkin' help. so imagine a 2d multiplayer space game with physics. each player controls a spaceship, there are asteroids.

i'm trying to wrap my head around how to handle collisions when pings are high.

in a techdemo i implemented state-sync multiplayer with client-side prediction/correction, server is always right.

client plays ahead of server-time and has immediate feedback on his own inputs.

(tried sending client inputs with future-timestamps also, but that feels sluggish to the player)

now i tried different approaches of displaying other players to the client.

extrapolating them is bad and results in desyncs basically everytime the other players move/act.

then i tried to show other players in the past, so i can interpolate from known states.

this looks nice as long as there are no collisions. for instant-hit shots i can use past positions on server to determine true hits.

but if the local player collides with another player there will be desync, because of the difference in time and thusly position compared to the server.

no matter how i put it, at one point the lag will make proper player/player collisions impossible.

think of two players trying to push each other away - i either have ping-sized delay between input and visible action,

or i have instant results from local players, but delayed movement from the others and with that predicition errors/desync.

testing this with RTT around 280ms, and it is maddening. i am starting to think the only way might be to not have real player/player collisions, and just make the ships explode or something when they touch.

but even then - if i want players to be able to ie bounce around asteroids using their ships,

or if they tried to push the same asteroid around, i end up with the same problems.

for example: [spoiler]

both players with the same high ping stand still with an asteroid between them.

at the same walltime both start to push the asteroid in order to smush the other player with it.

after ping/2 ms the inputs reach the server, which sees both players pushing the asteroid, so it's a draw and the asteroid stays still.

while for ping ms both players see themselfes pushing the asteroid and the other player doing nothing,

them victoriously smushing the other player with said asteroid.

after ping ms both players receive the servers state of them and the asteroid,

and have to revert to the moment when they started pushing the asteroid at ping/2,

having to realize they have not really smushed their enemy.

[/spoiler]

i guess this would even apply to a game of pong with high pings. to have proper collision on clients i need to have both players on the same timeframe, to have that i would have to show them in the past compared to player input.

am i missing something? or is it really not possible to have immediate applied player input with precise player/player-collisions on clients in high latency networks (ie the internet)?

how about making player controls LESS responsive, thus giving the server the time to sync by adding artificial lag between the player input and the players ship reacting?


Might sound crappy, but that could actually be quite cool if integrated into your design correctly, because nothing gives the player the impression of weight and massive size like an object that moves like an oil tanker. And Oil tankers actually take quite a while to respond to steering commands. Make the whole turning maneuver equally slow and lumbering, make sure the player gets audio and graphics cues of his ship starting to turn (which is something that doesn't need to be synced), and the lag is actually "expected".


Of course, your game design needs to be okay with that. If you design your game around the idea of super-agile ships and insta-hit rapid fire lasers this isn't a solution.

thx for taking the time.
realtime over network adds a lot of constraints that aren't that obvious to the uninitiated.

will have to form game design around that.

as with most ideas, there are reasons it hasn't been done.

in this case: design needs to allow space for lag to hide in.

thx for taking the time.
realtime over network adds a lot of constraints that aren't that obvious to the uninitiated.

will have to form game design around that.

as with most ideas, there are reasons it hasn't been done.

in this case: design needs to allow space for lag to hide in.

IMO the more your game is "twitch based", the harder your network code has to work. When you can move the mouse quickly and crank down the sensitivity, that will work fine for camera movement, or aiming that doesn't need to be synched over the network.

How well it works for interaction between players you already talked about in your OP.

Lucky for you with VR and more and more reliance on physics, twitch controls will have to become rarer and rarer... sure, some would-be pro gamers might totally think if your toon ingame will no react with splitsecond accuray to your inputs you cannot show off your skill in the game. Yet many games, even in the arcade game scene, have lately come to market in which the translation of input commands into physical reactions (which are never twitch-based, inertia prevents that) is the one core defining game design element.

Think about all the arcade tank games (WoT, AW, WT:GF), or even more extreme, world of warships. Without inertia, these games would SUCK! Because they aim to combine a sim-like expierience (which includes the FEEL of driving a tank/ship, which means things NEED to be much slower and thus harder to control) with an arcade like simplification of controls (no switching gears or stuff like that).

The fact that such a "slower paced shooter expierience" originally helped wargaming build WoT with not-so-high-tech middleware, which included an off-the-shelf networking solution from bigworld.

With VR one of the Problems is that any kind of vision movement not possible in real life will cause players to feel motion sickness, so all VR games will HAVe to adapt a slower, more physical approach to their camera movement at least... I guess making the rest of the game "more physical", thus all objects having inertia, is a logical next step to synch your vision movements reallife-like behaviour with the rest of the game world (which would look out of place without inertia now).

So expect that gamers acceptance for inertia and physics driven/restricted controls will only grow over the next few years... which is not only great news to people wanting to break away from the "direct controls" "twitch based" approach of more traditional FPS, but also for people trying to network games.

Everything is easier for the game dev when your ship is turning like an oil tanker... the only real hurdle is making this ship FUN to control when the player has to wait seconds before the ship is REALLY turning (ship might start to turn instantly, but for the first second or so that is hardly noticable as the rudder shifts (and thus might hide the synching lag)).

Might not be 100% comparable to a spaceship game, but IMO World of Warships did a fine job in making ships feel like 10'000 ton beasts of metal by giving them quite realistic feeling mobility (in RL the turning radius is most probably even worse), including a high amount of inertia and long rudder shift time. It just FEELS right, and after a short time it feels natural to control your ship. By making sure shots fired have their flight speed tweaked (shells seem to fly slower than in RL, and gun max distances certainly ARE lower than in RL), by tweaking the sighting distances and map architecture, everything plays nicely together to make for a gripping expierience not in spite of the not-so-direct controls, but thanks to it.

Nothing more breathtaking than having to evade a torpedo salvo that just appeared in front of your battleship and having some tense seconds of "steer into or away from the salvo?", "will I be able to make the turn to drive just between these 2 torps or will one of these hit me?", "do I need to shift rudder now to not oversteer or is it too early?". All the while if you don't start the turn like one second ago, your hulking giant will get hit anyway because your turn radius is like 1 KM.

So by tweaking your game design to not only hide the lag, but actually use it to enhance tension and fun for the player, you might be able to achieve a win-win situation. It will certainly be a different game, but it might be just as enjoyable.

Of course this will shift not only the feel, but also the gameplay of your game, making it more about tactical decision making than lightning speed reactions, which in turn will shift your demographics. If this is acceptable to you or if it will hurt your games success, you need to decide for yourself.

I have played through a bunch of possible scenes/events in my mind, that i would like to be experienced by players,

considering the massive-ship-with-slow-accelerations approach. And i can very well imagine that to be fun and exciting.

So i played with different factors considered when player-input is converted to forces that accelerate the ship,

and as expected the magnitude of corrections needed is directly correlated.

Giving immediate but slow control increases predictability of movements and thusly decreases differences between prediction and "reality".

I will spend some time trying to find a sweet spot where player's movement feels good and collisions result in an acceptable amount of jitter

at max RTT (aiming for 500ms max, above will get disconnected).

To get there i am playing with offsetting non-local players back in time on the clients, sending playerinput with timestamps set into the future,

changing the rate at which corrections are applied - and of course changing mass and acceleration of ships.

While fiddling and thinking i came across another idea that plays right into this.

I found that controls like this make it rather hard and boring to have a ship lift off of a planet (or other sources of gravity).

A tiny bit too much movement to the sides and your ship would slowly but inevitably start to slide sideways just to crash into the planet.

As i wanted them anyway, i thought about implementing boosters again.

To make them work with lag they would have a charge-time of max RTT, ie 500ms.

- player presses button and a clientside charging animation starts.

- the buttonpress travels through server to other clients where the lag of that event is

hidden by playing the charging animation for a shorter amount of time (or not playing it at all, only on the acting client).

- by the time the charge is complete all clients and the server know about the event and they can all fire of the ship's boosters at the right time.

So, for actions that result in fast acceleration a charge-time that covers maximum RTT,

and actions that require immediate results to feel right there is slow acceleration - so slow that within maximum RTT the change of movement is small enough for corrections to neglible.

Each with clientside feedback so that the player knows it's happening, and has a feel of applying enormous forces to enormous masses.

There will still be some janks and jitters, for example collision with high speed and corners/pointy-parts touching first.

Where a small difference in rotation or such may result in a different direction of collision-response.

Still, a lot better then the jumpy mess i have now.

Good ideas, and enough to get me out of that dead-end feel and try out some more stuff. Thx!

Glad my advice was useful...

About gravity, maybe it is also helpful to just visually communicate to the player where they need to start correcting for the gravitation... some kind of a "gravitation effect", or a UI warning? You could make the ship correct for it automatically, though many players might not like this kind of loss of control.

Or if planets are and should feel MASSIVE in your game, atmospheres and gravitational wells should also feel that way. Maybe start gravitation effects further out, but start with a very pull. Players will have more than enough time to notice it and start their maneuvers before they hit any kind of "point of no return".

Maybe if you adjust the "scale" and reaction time of on entity in your game world, you should rethink the "scale" of other entities in your world (for example strength and falloff of your gravitational pull).

Might NOT be realistic (because when the effect shows up in reality, ships are pretty much beyond the point of no return, at least when fuel economy and limited engine power comes into play), but an "atmospherical entry" kind of effect where the ships starts heating up and burning would be a great effect to communicate to players that they get dangerously close to a planet.

About the Corner cases, could you "hide" this somehow by adjusting the graphics? For example, by giving fast ships some kind of a "motion blur" that elongate their sprite size, and then adjust the position of the sprite slightly so it looks to be further forward along its motion vector than it really is in code.

This might eliminate the cases where ships collide when they are not touching graphically. the other cases, where ships are not colliding when touching are easier to explain and thus overlook by players because they might be slightly offset in the third dimension... maybe add some cues (like shadows or somesuch) to strengthen this.