Paul P.

Thanks a lot for your help! I will take into consideration all that we discussed here. I hope it turns out great. I will start working on it soon, but I might postpone adding this functionality for a later release of the game since it's not the core of it and I want to have something working as soon as possible. I will probably open a new thread for suggestions on how this can be replaced in the early stages of the game development.

So to conclude, you suggest I would do the following: - Have the game loop run at the same time on the client-side and the server-side, at a fixed rate, 10 TPS - Send the input from the client-side with a higher frequency than the tick rate - Have the server apply the last input received for the current tick and discard the rest (this might not work for me, but I can aggregate the inputs into a single one) - Have the server emit the game state once per tick - Have the client-side interpolate entity movement between game state updates so they wouldn't jump around every 100ms, so they will smoothly move every frame (this one is trickier since the client-side prediction will allow the player entity to move immediately after the movement input was detected) This brings up one more question, if I use client-side prediction to move the player entity immediately after an input was detected, how do I account for multiple inputs in the same tick? Let's say I, the player, quickly pressed the following, inside one tick, UP, UP, LEFT, DOWN, RIGHT. Assuming a movement of 10 units/tick, I would have the following scenario, assuming the player entity starts at (0,0) - UP -> (0, 1) - UP -> (0, 2) - LEFT -> (-1, 2) - DOWN -> (-1, 1) - RIGHT -> (0, 1) Since the input is sent 10 times less often than the tick, I divided the movement by 10. In this case, if the server only reads the last input which was RIGHT, the computed state by the server will be (0, 10) where as the client will be at (0, 1) and after receiving the update from the server, the entity will jump 9 units. To combat this the server will have to take into consideration all input received within a tick and aggregate them and update the entities accordingly. What do you think?

I understand what you are saying, and this is exactly what I'm planning to do. I just wasn't sure which option of the 3 I mentioned I should take when designing the server. I'm using a TCP socket, so all packets should arrive, in order, but not always on time. What should be done when an input arrives later than it should have? Do I discard it or do I still apply it?

I'm afraid it's not possible to allow the client to run the simulation as a whole then upload the results, because inside this simulation the player and the entities have a certain accuracy, damage and movement speed. The loot present on the map is also relevant, but you have to fight your way through to get to it. Take hit chance for example, let's say it's 10%. If the simulation is ran on the device and the server checks the events, there is no way I can detect hit chance cheats, because if the player takes 100 consecutive shots and they all hit despite the chance being at 10%, that's still possible to happen without cheats (extremely unlikely, but still possible). Maybe if I use a pseudo number generator on the client side that has the same seed as the server and the same algorithm the outcomes of the hits should match. But there is still a problem. Not the whole map is visible at one time, the player can only see entities which are within a certain radius around them (this is important because the lower the radius the higher the difficulty). Also the contents of the loot "chests" present on the map should be unknown until opened.

There is only one player, so there is no opponent. It's just the one player and the server which are involved in this. I agree with you that the pings will be higher than 100m, but I'm not sure if this will be a problem. Assuming a constant ping of 500ms, the first action will arrive with this delay, but the player won't notice it because on their screen stuff is already happening, because of client-side prediction. The events from the server will arrive with some delay as well, but the behavior of the entities is mostly predictable. Here is what I think will happen: the player will see that an entity has spawned 500ms after it should have seen it, but it's (the entity's) behavior can be computed locally, meaning it will move smoothly, targeting the player or whatever. The same thing goes for when an entity gets damaged, there will be a 500ms delay before the player sees it. Now that you've said this, and I agree with you, I'm not sure which option to choose, since variable tick rate is not really an option. What do you think, considering what I mentioned above?

The thing is that the game is not action packed, there are only a few entities visible at the time, and their movement speed is not that fast. The player's actions are quite simple as well: movement, target selection and picking loot. Since the packet size for input and game states are relatively small it should be pretty fast to transport from the client to the server and vice versa. Even if the inputs arrive later at the server, it think I will allow it to still process them. If that doesn't work well, I think I will choose Option 1 and implement some kind of anti-cheat method by measuring the average TPS. Since the target TPS is 10, I will probably allow it to go as low as 8 before calling the player a cheater. I don't know how this will behave on a low-end device that cannot process the data fast enough, but I'm 80% sure that all devices will be able to handle this, since it's only 10 ticks per second... EDIT: I don't think I can allow a variable tick rate because the timings are tick bases, like for example the movement which is 0.3 units/tick for certain entities.

Thank you for your answer. This pretty much covers what I'm planning to do, but my concern was with the behavior of the server when user input arrives later than it should, and if it (the server) should wait for such input before computing the next state (only possible because there is only one player). Regarding the anti-lag mechanism you described, I'm planning to use client-side prediction for this, to keep the entities moving to their last known target until a new game state is received. For example, one entity is set to follow the player, then the entity will follow that player's position on the player's screen even if the server did not send a new game state with the updated positions.

I believe Quake was not designed for Internet multiplayer, only LAN multiplayer and that was one of the issues. Another, but I'm not sure about this, is that they didn't do client-side prediction and this is a must for smooth gameplay.

@fpo the information is encoded using Protobuf, but it's not encrypted. Performance shouldn't be an issue since the number of entities is pretty small and the tick rate is not that high. Some games send the player position and the server has to validate that it's not too far away, but in this case I just send the user input like the analog stick is at (+0.9;+0.5) and that will determine where the player will move in the next game tick. @wasab thank you for your input, but I believe that option 3 is the most used one in games, maybe with some more details than I mentioned here.

If the array is not sorted by default, sorting it then using binary search is less effective than actually iterating over each element and checking if it's the one you are looking for.

Hello guys, as the context, I'm currently working on a small game to practice my programming skills in the game programming area. Now I've got to the real-time programming part of the project and I have some issues there. As you probably know already, lag in a real-time game is really annoying. Since this is a mobile game I would assume the problem is even more severe since I have to deal with pings in the hundreds range. I've have been doing some reading on lag compensation techniques like client-side prediction and server-side reconciliation, but I have some unanswered questions. The player will be able to control an entity on a 2D map, their input is very limited: an analog stick and interacting with some elements. There is only one player in such a game, so basically it's only the player and the server involved in this. The client-side prediction is really easy to achieve here so that's not a problem. The issue I have is that I'm not entirely sure on how to handle things on the server-side. The inputs are currently being sent every game tick (10 per second) and they are tagged with the tick number. I have the following options: The server waits for the input from the client then computes the new game state and sends it to the client. The server runs the game loop waiting up to 100ms (10 TPS -> 100ms / tick) for an input. If it gets one, it will be taken into consideration when computing the next state, otherwise it will be discarded. If an input arrives after the tick was done, it will be discarded. If an input arrives during this timespan, but the tick numbers don't match (client send input for tick 5, but server is at tick 7) it will be also discarded. The server runs the game loop waiting up to 100ms (10 TPS -> 100ms / tick) for an input. If it gets one, it will be taken into consideration when computing the next state, otherwise it will be discarded. In this case it will not care if the input is not for the current tick, it will apply it anyways. Option 1 is the easiest to implement and will be more consistent. The biggest issue with this is that I believe it's easy to cheat. Since the server is waiting for input, the player might be able to "pause" the game, analyze the situation then dispatch the action, basically allowing a cheating player to play in slow-motion. The client-side reconciliation in this case seems easy, when the player moves, it will move instantly on the screen and when it received the updated state from the server it will do it's reconciliation. Option 2 is a tad harder to implemented (not by much tho), but it will be unplayable (literally, the player won't be able to move) if their ping is higher than 100ms. Option 3 has the same complexity as Option 2. It will work with pings higher than 100ms but it will most probably lead to some frustration on the player's side since their inputs will not arrive in time. What do you guys think? Which option should I choose? Is there a better option for this than the ones I mentioned?

I really like the form factor and the specs of this laptop. It is great for me, I don't play many games and I mostly use my PC to develop software, so the battery life will be great for me.

My favorite part about this phone is really that huge pixel density, I'm not so worried about contrast and color accuracy

Hi guys, So I have a problem with a friend's PC. It's stuck just before booting from HDD, and by that I mean that screen with black background and white text listing components and stuff, the one where "Press any key to boot from X..." appears. At first there is a blinking cursor in the bottom left corner then it dissapears. Here is what I did so far: 1. turn it off and on again (duh) 2. cleared CMOS 3. checked if the hdd jumper is set to master 4. disconnected all peripherals (except the mouse and the keyboard which by the way are ps2) 5. disconnected hdd, after i done that it shows an error message saying that I should enter a bootable disk and press enter 6. loaded optimized settings 7. loaded factory defaults what I didn't do: 1. check if it boots from another device like usb or cd (it was late night and i didn't have any on me) I was told that this appeared out of the blue.... I'm sorry if i made spelling mistakes, i'm not a native english speaker. Thanks in advance!

thanks for the giveaway Linus !