… is to be considered a normal practice to do it?
Recently I am playing (and I am a really frustrated player) a FPS multiplayer game, that suffers big networking lag problems on certain machines. I have a Mac, and as developers said they do not develop on Mac and use the only Mac they have only to testing and compiling. The game is based on open Quake engine.
I submitted my problems: one of them is that if I disable client side movement prediction my character behave like if he were skating. Normaly, in this game, there is a little innertia at the end of every movement, though with lag it become uncontrollable.
During my forum discussion with the developers, they revealed me that this is caused by the fact that my character continue to be affected by innertia until he recive back a response from server. So if I have 100 milliseconds of lag my character skates for 100 milliseconds. Moreover, during those 100 milliseconds, keyboard inputs does not affect my character.
Other times my Client predicts me to be in one position, but the server updates my actual "remote" position and I find myself projected 2 meters haead or pushed back 2 meters backwards.
I am surprised by that. Is it not a bad implementation, in your opinion?
In my opinion, events that should be passed to the server should be weapons shuts; current player position; piking ammo, armor, health or weapons. Server should respond back for enemy players hited by player fire, and should update clients about other players positions, ammo, armor, health or weapons respawning. Giving the server the task to give permission to a client to move (or stop) is character is something more like a MMORPG.
I am not expert, though. What do you think?
Yes, I agree in full.
Keeping the stopping factor at the server is just dumb, I wonder what their thought process is behind this. They might actually have a good reason, even though the client should do a quick double check (there should be AMPLY horsepower client side) of the server response time for this critical value and apply if the time is too long.
Yes. And I forgot to say that the servers I refer were hosting max 8 players.
I think that the reson to add this Server side permission response, is caused by the innertia they added at the end of the movement. Probably it is used to register exactly player position with the effects of innertia, to have a more precise collision detection if another player shuts me.
Though, in my opinion, if I had to deal with such a big problem I would prefer to avoid innertia and leave only uniform movements.
Moreover they register to the Server also when a player picks up a weapon or ammo. I can see it because when I pass over them animations freezes for an instant, if I have a lot of lag.
If I should implement it by myself I would send only a message to Server from Client that notices I have picked up that weapon. And Server should notice all the other Clients.
I could implement an error handling if using UDP to request a Server confirmation, but the Client player character movements should not be affected for the waiting of the confirmation.
This is my idea.
Hey
My opinion is from server side view, never trust what clients send. The client should only send deltas, like current active actions ("Moving forward", "Shooting", "mving mouse"). The server then calculates what happens (Collisions, spawning entities etc.) and sends absolute data to the client.
(As far as i remember the original quake 3 code does this)
What the client renders does not depend on these steps - there should be deadreconing etc at client side. So the user should normally not recognize things like (minimal) lags.
A good example for sending deltas is Battlefield 2. If u have a lag, u cant even change your view with your mouse or you have a jittering in your mouselook… (The BF2 netcode is bad in my opinion)
Regards
snareoj2 said:
What the client renders does not depend on these steps - there should be deadreconing etc at client side. So the user should normally not recognize things like (minimal) lags.
It seems that your view (that seems in the middle between mine view and the actual game approach) is a little different from the one of this game. In this game Server response waiting actually affects Client graphics and gameplay performances. In your view, instead, Server does not affect them.
Though, one thing that lag can influence, in a FPS, is to verify if a bullet actually hits a player. With this game it often happens that my bullets go through other players without hiting them, as like as they were ghosts. Of course, you can imagine how can be frustrating playing this way. ;)
This never hapened me playing the original Quake or Unreal. I know, they are commercial projects, and servers are probably more performant and well configured servers. Though, considering the hardware that a single person can have at home in this times (Core Duo, Dual Core, Quad Core + Gigas of RAM, with broadband connections) at a accessible cost, it seems strange that 10 years ago servers run better.
Is it based on the Quake or Quake3 enginge??
Because Quake is Old Skool indeed 
Pyrrhus said:
If you want actual examples, take a look at how Quake3 and Half-Life deal with issues - historically, they've been two of the best to deal with latency.
Thanks.
Considering that the game I talk about is based on Quake engine, exactly the Darkplaces modification, it is strange that they have been able to get such a bad networking architecture.
Quake. Though looking at the code, it is basically, plain C (for the engine) and the QuakeC for AI and Logic.