Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

173 Neutral

About Heg

  • Rank

Personal Information

  • Interests
  1. I´ll use the stuff explained in this topic. I hope that it will be sufficent. I´ll have a look into delta compression. Thanks for the tip I do not really get that part. Lag compensation or not, you should always see exactly what happened on the server only with a delay. Lag compensation just makes it smoother. At least that is how I meant it. You just draw all entities at the same point in time and do not do any client prediction. [/quote] Oh, sorry about that. What I was trying to say is that trapping other players is a matter of gameplay, therefore I have to test it with real players. I tested the current state against my A.I. players, and the delay is noticeable. The thing that automatically happens is that I am anticipating the delay and because of that I am still able to trap the players. This happens, because I am the programmer and know that the delay is there. I have to see how it affects other people, whether it is annyoing or not and how often it occurs in a series of matches. Only after that I can decide if some sort of lag compensation is needed or not. If you suggested that I shouldn´t interpolate or predict the players at all and just show them at there last recieved position, I tested that as well. That works horrible over an internet connection, because the delays are very noticeable.
  2. I am not talking about Client-Side Predicition anymore, i.e. the prediciton of my local player. We went a little bit offtopic, since my prediction is working fine at this point If you are talking about predicting the movement of the remote players, I am not trying to do that. I just want to show 'old' movement data of the other players, so it will look smooth on the local machine. I didn´t, because the lag compensation is not implemented for explosions. In the current version you will die when the server detects you in a fire, even though you didn´t stand in the fire on your local machine. That is horrible and will drive players insane, that is why I couldn´t make some real test runs. I have to refine my entitiy interpolation and implement lag compensation for explosions first, then I can test how bomb planting feels. I´ve got my hopes up that it will feel okay as it is. We´ll see ;)
  3. Okay, so what I would try to do now is the following (I am only talking about displaying the opponents, i.e. the remote players, in a smooth movement, not client-side predicition): 1. I estimate the current server time by using timestamps and package latency. 2. Each player movement in the game update send by the server gets a starting time which indicates when the server started to process the movement. 3. To play the movement of the other players back, I set the current time on the client to renderTime = estimatedServerTime - Latency * 0.5 - 1.5 * UpdateInterval. All queued up movement data will be executed when renderTime >= starting time. 4. If an update arrives way too late, i.e. over 1.5 update intervals, the starting time of the movement will be way behind the current render time. If the movement still takes place during the current render time, I will either speed up the action or cut it off, so the movement will jump to the next position. Is this a sane approach, or did I miss something? And before I forget: You guys are a big help, thanks alot
  4. I think I failed to explain my problem. In valves networking wiki, under Entity Interpolation, they state that the actual render time is 100 ms behind the client time, so that basically all other players get displayed to the user 100ms in the past to allow smooth movement. I do understand the basic concept, but what I don´t understand is where the client time begins in the first place. When do they start the client time? On the first recieved update package from the server? Also, to adapt this behavior I would have to shift my "rendering time" 200 ms into the past, since my update period is 100ms. This would just be too much for my taste. Is it viable to set my update interval to 50 ms and use valves technique? Or is there a better way for me to do this?
  5. Okay, I have yet another question: I tested my interpolation a little bit more, and it doesn´t work well with variating latencies (unfortunately I forgot those in my testing ). Currently my game updates include movement data in a format like this: "At position x,y the player moved up for 30 ms." and so on. I did this, because you can turn instantly in the game. The client just needs to set the player to the given position and execute the same movement code as the server did to reproduce the movement. I am sending out updates at a 100ms interval. So if the client gets an update, it views the movement of the update for the next 100 ms. If a new update arrives during that time, the action gets queued and displayed afterwards. So far, so good. But what happens when an update arrives to late? I could display the movement until the next update arrives and then jump directly to the next update. But how do I realize what updates are too early and which are too late? Basically what my question is is, how does the time synchronizing work between server and client? Currently my idea is that when the client recieves the first update, he starts his internal "client time" and expects the next update 100ms later, since it should be send out 100ms later relative to the first update by the server. This whole idea falls flat when the first update arrives too fast. If for example a package needs 150 ms to arrive at the client, but the first one arrived after 50ms already, the client would render the first state for 100 ms and expect the new update, but that wouldn´t arrive for another 100 ms. This gives me a real headache and I think I missunderstood something along the way. Please help me clear up my head
  6. I think you understood the problem quite well, so no video is needed These two choices you speak of (rewinding or not rewinding the server) are basically the once that are giving me trouble. Not in terms of implementing, but in deciding what would provide the better gameplay experience. I´ve got a friend who always manages to punish players immediately for walking into a potentially trap situation.. You walk into it, and boom, he trapped you and you are doomed. On the one hand I consider this a high skill move, and therefore it should be rewarded with a kill. On the other hand this gets very frustrating for players with high latency. Maybe they moved into the trap knowing that the other player is too far away to trap them in time.. But little do they know that the guy is way more ahead on the server... I don´t think there is a perfect solution to this, I think I have to decide what´s the lesser evil.
  7. As I said I am currently working on the Lag Compensation and I would like to hear your opinion on one special case.. In Bomberman you only die when you get hit by an explosion. This means that other players can´t kill you actively, like shooting you in the face with a gun. Instead they can trap you by planting bombs at the right position, because you can´t move through bombs. An example is illustrated in the picture: [sharedmedia=gallery:images:2830] So first of all I am incorporating bomb explosions into lag compensation. You only die if you are standing in an explosion on your screen. This can result in players moving through flames on the other clients because of the latency. But the trapping situation is giving me a headache.. It is an important part of the gameplay, but the latency makes it kinda complicated. Consider the example in the picture again. The trapping player can plant a bomb perfectly infront of his opponent to trap him, but on the opponents machine, the bomb won´t get planted right in front of him, since he already moved to a different position on his machine. What do you guys think would be the smartest thing to do in those situations? When a player only gets trapped when the bomb is appearing on his screen, trapping players in close positions gets almost impossible, but otherwise you will get trapped even if you have already moved out of the dangerous position. I hope the problem is understandable.. If it isn´t, please let me know.
  8. Heg


  9. Sending redundant client input is a brilliant idea! I already implemented it. The client now sends input, which is still waiting for server correction, along with new input to the server. I also added some simulation routines to my network layer. A package loss of 10% isn´t even noticeable when looking at the movement of the client. However the opponents do jump occasionally, because of the missing movement information. The next step would be to implement Lag Compenensation. After that I need some animation to hide the delay between the planting bombs command and the actual appearence of the bomb, and the delay between running over an item and the time when it´s actually collected. I really want to wait for the server response before drawing bombs or collecting items.
  10. Yes, you can also generate arbitrary latency for testing how it affects your game. Usually your game update is staggered. First, Receiving packets, then updating your game (server or client), and finally sending your commands / states at the end of the update. It's one easy way to manage your game loop without adding unnecessary latency. You can have a virtual network layer that can queue sending and / or receiving packets, as well as simulating packet loss, duplication and out of order (all of which should be invisible outside your lower network layer) for testing purposes, or if you lack the resources for proper internet testing. Then you can use renderless client-bots / servers, or just basic loopback networking with one player, like in Quake3 and many other Unreal / ID / Source games). [/quote] Yeah, I already got a few testing functionality in my network layer, such as latency and packet loss. I am missing functions for duplication and out of order though. I´ll make sure to implement that. While we are at it, how do you guys handle lost or out of order client input? I would say client input needs to be ordered, but that would also imply that you would have to wait for a resend of lost client packages, since it´s not ordered when you are missing one package. Should I really wait for such packages, or should I just let the client input get lost? This would result in a correction of the movement on the client, since it predicted the movement wrong. Current state of the game: Client-Side Prediction and Interpolation seems to work quite well in my current implementation, but I am not reacting to lost, duplicated and out of order packages yet. That´s my next step :-P
  11. Yes, it does! This is why CS:S servers running at "tickrate 67" or "tickrate 100" are popular among the low-ping addicts. On consoles, you typically can't get away with better than 20 times a second (every 50 ms) and many games do it less (every 67 or 100 ms.) Seems to work well for them anyway. The trick is to tune the display and gameplay to work well with whatever your chosen network parameters are. [/quote] Okay, so I rely heavily on my client-side prediction, lag compensation and interpolation then. Maybe it´s even a good thing that lag even affects local games. That makes it waaay more easy to test and requires me to work really hard on the networking stuff, otherwise the game will suck for everyone, not just for the guys with slow internet speed.
  12. I´ve got one additional quick question: Best practice is to send out game updates from the server and input from the client at a fixed rate, say every 100ms. When we define the "effective latency" as the time between issuing a command and the response from the server, this technique does increase the latency by quite a big deal, doesn´t it? For example: Server: |----------|----------|----------|----- Client: --|----------|----------|---------|---- The | are the sending points and the time between them is 100ms. If the player on the client issues a command right after input has been send to the server, it would take almost 200ms to get a response, even when the packages arrive instantly. The first X marks the input time, the second one the response from the server: Server: |----------|----------|----------|----- Client: --|-X--------|---------X|---------|---- This is noticeable even on a listening server. I fear, when there is actually traveling time needed between the server and the client, that this will have a too big impact. What are your thoughts on that? Is a 100ms interval simply too big?
  13. Hm, I could make my guys "bend over" or something in order to plant the bomb :-P A translucent bomb will most likely look odd!
  14. Yeah, I agree with you. I already programmed a low level UDP layer including an acknowledgement system and all that stuff. So I will definitly use UDP only. I had just some issues around client-side prediction and packet loss. On important game decisions, like planting or exploding bombs, I´ll just wait for a server message and see how that goes. One thing I have to accept is that my game won´t work well when the internet connection is bad. I think there is nothing you can do about that.
  15. You still should send the commands on a reliable channel, your UDP stack fits in here. Just remember the last X send commands + sequence number and the server will send acknowledge messages about the last valid sequence number from time to time (the client can clean up the command queue up to this number). Although the server should send resend-requests when it detects a gap asap. You can even re-send the same command (unique sequence number) multiple times, using the space left in a UDP for best use and on the server side it doesn't matter at all. [/quote] I´ll keep that in mind. I´ll let you guys know how it turns out ;)
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!