Hey everyone,

So I tried to make a picture showing my problem:

I have a gameserver, but was curious if I need to run a physics engine on the server? I've been following some tutorials online and created some attack animations with a character and would love to create some sort of fighting online side scrolling game.

I know that the client is just supposed to be a dummy sending signals to a host server, however if my host server is not created with my game engine of choice (in this case, Godot's) but (nodejs, c++, elixir, etc), would it still be possible? I just don't know how to handle lag latency compensation. For example, since the character uses set_linear_velocity with a acceleration variable... The amount of time the command actually reaches other players, will have moved the character further than his actual value. That is, if we don't have a "host" managing where everyone really is?

Your problem doesn't actually exist, at least not in the way that you've formulated it. If Player 2 is always 150ms away from the server and Player 1 is always 50ms away, then it takes 200ms (plus some overhead) for the information to travel from Player 2 to Player 1. This total latency is constant and therefore nothing gets out of sync - if Player 2 presses the key, holds it down for 5 seconds, then releases the key, Player 1 will see Player 1 moving left for 5 seconds, just 200ms after it actually happened.

Of course, where this falls down is that those figures of 150 and 50 are not actually constant at all. They fluctuate over time depending on network traffic. So Player 2 moving for 5 seconds might appear, to player 1, as 4 seconds, or 6 seconds. It might even appear that way to the server.

Generally speaking, you do need a basics physics simulation on the server, or at least "have a "host" managing where everyone really is". You can't just broadcast out state changes for the reason above. I'd love to do my usual thing of recommending the simplest possible approach here, but I'm not confident it would work for a game in a genre that traditionally expects pixel-perfect combat resolution, and where 200ms is an eternity.

Of course, where this falls down is that those figures of 150 and 50 are not actually constant at all. They fluctuate over time depending on network traffic. So Player 2 moving for 5 seconds might appear, to player 1, as 4 seconds, or 6 seconds. It might even appear that way to the server.

Oh lord, this is exactly what I was trying to convey! So glad I am getting help on this, I've always wondered how to solve it.

"have a "host" managing where everyone really is".

Yeah, I think I'm going to do this then. Just run some type of host server to keep track of players locations and whatnot when they give the server a command. I can mess with client prediction stuff to smooth it out, but I need to definitely kink out the host server so it's at least somewhat in sync of positions and whatnot

However, it's hard because I'm using Godot as the client side physics engine. And I'm not sure if I can replicate EXACT details of how their physics world is simulated in an actual server network code world.

Like yeah, I can use a little physics server library netcode now that will work for left,right,top,down,jumping, etc. However the gravity and all that stuff, acceleration, imply_pulse commands and stuff that I use for dynamic combat in Godot is not something I can port over to a network server. Well, I could but I'm not smart enough :P

Also, is it possible to just send the state of players to the server? This would help bigly for performance, but result in massive cheating I imagine. But then again.. That doesn't solve the problem you've stated above without a host.

I need to stop thinking that I don't need a host.. I know for a fact I need a host. Losing my damn mind :o

It's possible to get away without a full physics simulation on the server, providing you have enough logic to be able to verify that what you're being sent is legitimate. It's common (although not standard) for clients to send their character's position to the server, and for the server to either accept that data or reject it. This works well for simple position updates (e.g. in an MMO), but significantly less well when trying to do full physics, where it is probably impractical to spot invalid data.

Sometimes it's practical to simply run the same engine on the server, but Godot looks to be quite under-developed when it comes to networking, and the only example I could find completely omitted any sort of physics.

Thanks hplus and Kylotan. This forum is pretty damn helpful.. for me just being a new user and you guys responding within minutes.

I've gone ahead with a 10-15 messages per second timer. It basically sends x, y and some other small information to the server. Then, the server broadcasts that data (once its properly checked), to the other players in the map at that same rate.

Then, I use lerping in my fixed_process in Godot and it's actually starting to come along nicely. There is a tiny delay but I can increase the msgs per second for a little bit more reactiveness but it seems fine for now.

Positives of this?

• No physics server. (A positive for me as I cannot code it!) is what I mean

Possible Negatives:

• Fly hacking (although, I can try to check the difference between movements on server, but meh)
• Extremely bandwidth intensive? This, I don't know but I'm thinking I'm going to need to spin up more game instances, which is fine

And the server still acts as a host. It will obviously store the players last location in a variable, so when new players join the game they know where they are.

However, this means if the player (client) isn't sending those update packets to the server, sadly they will need to be disconnected. Obviously I'll give a little bit of leeway of the amount as people who lag it might disconnect them falsely

That won't be a problem as anyone who is doing that, is probably fiddling around doing something dirty. Yeah, this is probably not the best way to handle this but with my knowledge the physics server will never get coded. Especially when it has to correspond to Godot's physics.

I think I am starting to grasp my head around this though. It's probably not ideal but for a small indie game I think it'll be fine?

The sort of updates you're talking about won't be anywhere near a bandwidth problem for a typical number of players. So don't worry about that.

Whether it's sufficient for a small indie game or not is down to other factors. Are you planning on taking people's money for it? If so, you'll want to consider how those people will feel if a cheater ruins their experience. I would suggest implementing at least a few basic checks, such as confirming that maximum velocity isn't exceeded (with some degree of tolerance - again, consider the jitter) and rudimentary collision detection against walls, platforms, etc.

Wow, you guys are loaded with information. Much more than I can ever attain. Am bookmarking this thread for future references.

Now, I was thinking a bit about this overnight. What if I made it so I still have a host, items are server-side, cooldowns, etc all the same as before. Except there is a catch. What if player movement was done via P2P? This would drastically remove some overhead, right?

Obviously this would open a yuuge can of worms in terms of fly hacking. But, this would drastically remove the overhead, and make the game seem even smoother than how I am currently interpolating x,y positions.

However, there has to be a big drawback to this which I'm probably not thinking of... :ph34r: