• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Heg

Members
  • Content count

    23
  • Joined

  • Last visited

Community Reputation

173 Neutral

About Heg

  • Rank
    Member
  1. [quote name='papalazaru' timestamp='1348754703' post='4984353'] Generally, you need some 'a-team' style clock synchronisation. Can be as simple as using timestamps to measure roundtrip latency (and half it) and convert local time to to a global shared time (maintained by the server). I don't have an algorithm at hand, but it should be easy to work out. Being aware of drift, and especially if you base your clocks on timesteps (imo you'll be better served with using the cpu tick counter for that). [/quote] I´ll use the stuff explained in [url="http://www.gamedev.net/topic/609269-synchronizing-server-and-client-time/page__st__20"]this topic[/url]. I hope that it will be sufficent. [quote name='Inferiarum' timestamp='1348772788' post='4984458'] You can do your game state updates as soon as the packets from the server arrive. The entity positions at render time are then calculated as the interpolation between two game states. Thus it is maybe also better to go back 2.5*Updateinterval, so you can still interpolate the positions when one packet is lost. For the game state updates from the server you could also use quake3 style delta packets so you never miss any information and you only have a problem if two packets in a row are lost. [/quote] I´ll have a look into delta compression. Thanks for the tip [quote name='Inferiarum' timestamp='1348824812' post='4984670'] [quote name='Heg' timestamp='1348746338' post='4984320'] 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 ;) [/quote] 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. [quote name='Khatharr' timestamp='1348705778' post='4984174'] I didn't speak clearly. (sleep deprivation, lol) Yeah, I didn't mean screen updates. I meant updates of client positions, etc. Otherwise interpolation would not be possible. There's no reason to render 2 ticks behind. (That's the opposite of what you're looking to do with prediction, isn't it?) [/quote] 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. [quote name='Inferiarum' timestamp='1348735063' post='4984279'] concerning the problem with trapping players with bombs etc. Did you try how your game feels without any form of client side prediction? That is, the player just has to live with the delay. I guess that should work quite well for a bomberman clone. Afaik this is also how it is done for most Dota like games, e.g. League of Legends etc. [/quote] 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. [quote name='hplus0603' timestamp='1348704225' post='4984171'] In general, the client will attempt to estimate the clock of the server by using time stamps in packets. There are various ways to accomplish this, discussed extensively in other threads on this board. The actual delay from "server" time when using "perfect" interpolation will be one-way transmission time plus (average) one and a half times your update rate. The reason for this is that you need the "next" point to interpolate towards, to start moving towards that point away from the previous point, and you want a little bit of receive buffer to account for jitter. In practice, the quantization of your game loop, and the game loop of the server, may add additional latency. Additionally, your client will send data to the server at your one-way transmission time plus average one tick time ahead of time, for the data to be sure to be there when it's needed on the server. Thus, the time that other players are behind the client input is going to be at least your round-trip-time, plus two ticks' worth of time (and usually, a little bit more than that.) Yes, you can set your network tick time to 50 ms. Or 16 ms, if your graphics and simulation will keep up. This will reduce the "plus tick times" part of the equation, but not the "transmission time" part of the equation, which is generally the bigger part unless you have really good internet and live close to the server. [/quote] 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 [i]player movement[/i] in the [i]game update[/i] send by the server gets a [i]starting time[/i] 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 [b]renderTime = estimatedServerTime - Latency * 0.5 - 1.5 * UpdateInterval[/b]. All queued up movement data will be executed when [b]renderTime >= starting time[/b]. 4. If an update arrives way too late, i.e. over 1.5 update intervals, the [i]starting time[/i] of the movement will be way behind the current [b]render time[/b]. If the movement still takes place during the current [b]render time[/b], 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 [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
  4. [quote name='Khatharr' timestamp='1348684432' post='4984058'] If the client is not getting updates as expected from the server then maybe you could pop up a notice in the corner of the screen or something and stop interpolating/predicting (only set player positions by server positions) until the problem is resolved. It looks tacky, but it will prevent adding confusion to the confusion already being presented by packet loss/lag. [/quote] I think I failed to explain my problem. In [url="https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking"]valves networking wiki[/url], 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 [img]http://public.gamedev.net//public/style_emoticons/default/sad.png[/img] ). 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 [img]http://public.gamedev.net//public/style_emoticons/default/sad.png[/img] [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
  6. [quote name='lawnjelly' timestamp='1348577579' post='4983547'] When it does break down I believe it is usually best to rely on the server being authoritative. If you 'see' on the client you've planted a bomb and trapper another player, but as far as the server is concerned, that player has already moved out of the way (their input is ahead of yours, for example), you have a choice, you either let the server be authoritative and you correct your client, or you wind back the server, and say 'hey this client made a hit' and replay everything from there and send the result to everyone. I personally wouldn't want to wind back the server, it strikes me as a bit of a nightmare in terms of balancing, potential for cheating, etc .. (what happens if there's a stutter on the client, and the other player is not updated, and thus easier to trap?). [img]http://public.gamedev.net//public/style_emoticons/default/unsure.png[/img] [/quote] 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. From the album Bombermole

  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. [quote name='papalazaru' timestamp='1348354090' post='4982755'] [quote name='Heg' timestamp='1348338528' post='4982697'] 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.[/quote] 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. [quote name='hplus0603' timestamp='1348337922' post='4982695'] [quote]this technique does increase the latency by quite a big deal, doesn´t it?[/quote] 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. [quote name='papalazaru' timestamp='1348093778' post='4981853'] On problem with using TCP and UDP together is that UDP packets tend to be dropped if you start to saturate your bandwidth. If you are nowhere near, then sure. However I prefer a full UDP solution, as it makes things easier in the long run. In any case, you can re-engineer the lower layers if you want to move away from mixing both UDP and TCP. Secondly TCP can fragment your communication. Say, you send 10 bytes message + 20 bytes message + 10 byte message. Then you may received that data in the form of 12 bytes + 12 bytes + 10 bytes + 6 bytes packets. So you will need some reconstruction at the receiving end. A custom reliable message system piggy-backed on UDP can stop that kind of fragmentation, but really, it's not a big deal to fix that problem. [/quote] 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. [quote name='Ashaman73' timestamp='1348053217' post='4981634'] [quote name='Heg' timestamp='1348052557' post='4981629'] If it feels too unresponsive, I will add some kind of indicator that the command has been registered by the machine. [/quote] 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 ;)