Tag Info

Hot answers tagged

10

Problem analysis Real-time communication over a high-latency connection is obviously impossible. You can of course attempt an illusion (as you're doing by making the remote player appear to have passed an obstacle when it's not yet known). When that illusion fails (as yours does when the remote player didn't actually pass the obstacle, but died instead) ...


6

Just send some 'ping', write timestamp of that packet/session, wait for 'pong' response and get timestamp 'now' and divide the difference by two.


6

Lag results from the speed of light limitation, and the processing speed of network protocol translation and switching in intermediate networking devices and at end points. From yours and your players' point of view, these are invariant factors. Game that deal effectively with lag do so by adjusting player perception of the impacts of lag. One example is in ...


4

To complement Anko's answer, you can change a bit your game design by adding the consequence of the failed obstacle after the failure, for instance, a failed jump results in landing in a puddle of mud which disqualifies the player. This way the other player notices the failure by seeing the other fall in the mud, while the player who fails sees it right ...


4

You can safely throw out Ping from the board. Lag compensating can work relying on just number of ticks for which commands were received (including NoCommand commands) and confirmed. Since the game is p2p (via server or not it does not matter), each client has number of packets from other clients queued for execution and confirmations of packets he sent. ...


4

Any drawing API function called from the CPU will be submitted to the GPU command ring buffer to be executed later by the GPU. This means that OpenGL functions are mostly non-blocking functions. So the CPU and the GPU will be working in parallel. The most important thing to note is that your application can be CPU or GPU bound. once you call glFinish the ...


3

OpenGL never updates the screen, technically. There is a window system API that is separate from GL (e.g. GLX, WGL, CGL, EGL) that does this. Buffer swaps using these APIs generally implicitly invoke glFlush (...) but in some implementations (e.g. the GDI rasterizer on Windows) it does a full glFinish (...):       *On the left ...


3

Prediction is the way to go. It still works with 360° movement. All Quake games use it for example. The thing with prediction is that it fails as soon as the direction of movement of a predicted object changes (significantly). If this happens very frequently, prediction can't help you much. There is no other "magic" to fix latency, other than trying to ...


2

The general gist is that you have two concepts of "state". Local state (your client) Ghost state (the server) You take input from your client, and update your local client state (and send this to the server). You then "predict" what happens to everyone else, assuming some amount of spatial consistency to last frame. When you get information from the ...


2

I have an idea of where the jittering comes from with vSync and triple buffering. The easiest way to show this is visually. The first example would be 30fps with a 60hz refresh rate vSynced with Double buffering. The pipes are new frames and periods are duplicated frames. |.|.|.|.|.|.|.|.|. This gives an even ~33ms between each new frame, which makes it ...


2

I assume you're familiar with this experiment? Essentially John Carmack was doing something similar, recording the screen and timing pixels sent to the screen. He found that a good deal of the latency came from the screen. Other factors were the input delay from the keyboard, video drivers and or course the execution of the program itself.


2

It adds latency because you've got 3 buffers involved instead of 2, so it takes one more frame for your rendered image to get to the screen. I have no idea what kind of "jitter" Carmack is talking about here, though. EDIT Maybe, just maybe, this could make sense in a highly variable framerate context: frames rendered with a given delta-time but displayed ...


2

Is it totally necessary to manage reload times server side? Often the simplest way to do this is on the client side for both fairness and responsiveness. I'm no expert but what I would predict is that the current system encourages spamming and the server has to check whether each request is valid before discarding it, taking up more processing power. ...


2

I highly recommend you study the TCP model; it is very mature and has many features built in over the years, making it a jack-of-all-trades networking protocol. It will likely have features that address any follow-up concerns you may have. The scenario you describe is also known as packet loss; Player_A has sent a confirmation to Player_B but Player_B ...


2

With a multiplayer >2 game like StarCraft you can do a best out of X to figure out who's lagging. With a 2 player game there is no way to know who's at fault as it's a single connection, its that one connection that is having issue. Again, there is no such thing as player B being disconnected as the one single connection gets broken, both A and B gets ...


1

Your intuition about #1 is correct: don't trust client timestamps. Even without cheating, timestamps can be wildly wrong. Best approach is to ping, and divide the ping time by two. The lag may be asymmetric, but there's no way to verify that from the server. If you already have a persistent connection (TCP), that channel is fine. For just a ping, a no-setup ...


1

You don't need to correct the errors on the client right away. If you interpolate the current client info with the incoming server info, the client info will converge to the server info in the next few frames. Since you are expecting the server info arrival to be less granular than the client update, when some info arrive at the client it will have enough ...


1

Is it that important for the local player to know the exact position of the remote player's death? Let's say the remote player couldn't jump over one of your obstacles, and thus died. The dead player would see their death immediately, and would continue from the location of the accident. Nothing magical here. The local player (the one still alive and ...


1

I would suggest first reading this great article about networking. It explains fairly well the kind of lockstep issues that you are experiencing. Here is a great series of articles explaining fast-paced networking. These are actually the same techniques that I employ in my own game engine. Now I cannot suggest one solution over another for your exact ...


1

Latency is not only about distance but about the player's connection speed, and the quality of their ISP's infrastructure, and that of the host of the server, and the traffic on the network. So, you could theoretically balance things out by locating a server at the midpoint, but I expect the benefit from that would be dwarved by other factors. You're usually ...


1

I have a few suggestions : Shouldn't you handle network updates on every frame ? What's your status of GameTime.IsRunningSlowly ? Did you try to profile your application ? Here are some links for you : The Indiefreaks Game Profiler for Xna is here! this one might be of interest What Are Some Good .NET Profilers? Plus, on Visual Studio you have Menu ...


1

I think what you are asking here is whether to use authoritative servers or non-authoritative servers. Unity network documentation has a nice discussion about each mode. Also if I'm not wrong, some people call semi-authoritative to a mixed approach where some state is handled by the server and some by the client. I think Unity discussion should give you a ...



Only top voted, non community-wiki answers of a minimum length are eligible