Acknowledgement reliability using UDP I have a question about UDP. For context, I'm working on a real time action game. I've read quite a bit about the differences between UDP and TCP and I feel I understand them quite well, but there's one piece that has never felt correct, and that's reliability, and specifically acknowledgements. I understand that UDP offers no reliability by default (i.e. packets can be dropped or arrive out of order). When some reliability is required, the solution I've seen (which makes sense conceptually) is to use acknowledgements (i.e. the server sends a packet to the client, and when the client receives that message, it sends back an acknowledgement to the server). What happens when the acknowledgement is dropped? In the example above (one server sending a packet to one client), the server handles potential packet loss by re sending packets every frame until acknowledgements are received for those packets. You could still run into issues of bandwidth or out of order messages, but purely from a packet loss perspective, the server is covered. However, if the client sends an acknowledgement that never arrives, the server would have no choice but to eventually stop sending that message, which could break the game if the information contained in that packet was required. You could take a similar approach to the server (i.e. keep sending acknowledgements until you receive an ack for the ack?), but that approach would have you looping back and forth forever (since you'd need an ack for the ack for the ack and so on). I feel my basic logic is correct here, which leaves me with two options. Send a single acknowledgment packet and hope for the best. Send a handful of acknowledgment packets (maybe 3 4) and hope for the best, assuming that not all of them will be dropped. Is there an answer to this problem? Am I fundamentally misunderstanding something? Is there some guarantee of using UDP I'm not aware of? I feel hesitant to move forward with too much networking code until I feel comfortable that my logic is sound.


POST HttpRequest doesn't send any data I've some trouble for sending a post request to my nodejs server. I can receive data from the server with GET method, but when I try to send data with POST, I've an empty bracket on return on this function func on request completed(result, response code, headers, body) var json JSON.parse(body.get string from utf8()) print(json.result) print(response code) And empty bracket on my JSON console.log on the server too. My code extends CanvasLayer func ready() HTTPRequest.connect("request completed", self, " on request completed") func on Button pressed() var data "name" "Godette" make post request("http localhost 8080 ", data, false) func on request completed(result, response code, headers, body) var json JSON.parse(body.get string from utf8()) print(json.result) print(response code) func on HTTPRequest request completed() pass func make post request(url, data to send, use ssl) Convert data to json string var query JSON.print(data to send) Add 'Content Type' header var headers "Content Type application json" HTTPRequest.request(url, headers, false, HTTPClient.METHOD POST, query) And this code return this in my console 200 Thanks for help )


Sending changes to a terrain heightmap over UDP This is a more conceptual, thinking out loud question than a technical one. I have a 3D heightmapped terrain as part of a multiplayer RTS that I would like to terraform over a network. The terraforming will be done by units within the gameworld the player will paint a "target heightmap" that they'd like the current terrain to resemble and units will deform towards that on their own (a la Perimeter). Given my terrain is 257x257 vertices, the naive approach of sending heights when they change will flood the bandwidth very quickly updating a quarter of the terrain every second will hit 66kB s. This is clearly way too much. My next thought was to move to a brush based system, where you send e.g. the centre of a circle, its radius, and some function defining the influence of the brush from the centre going outwards. But even with reliable UDP the "start" and "stop" messages could still be delayed. I guess I could compare timestamps and compensate for this, although it'd likely mean that clients would deform verts too much on their local simulations and then have to smooth them back to the correct heights. I could also send absolute vert heights in the "start" and "stop" messages to guarantee correct data on the clients. Alternatively I could treat brushes in a similar way to units, and do the standard position velocity client side prediction jazz on them, with the added stipulation that they deform terrain within a certain radius around them. The server could then intermittently do a pass and send (a subset of) recently updated verts to clients as and when there's bandwidth to spare. Any other suggestions, or indications that I'm on the right (or wrong!) track with any of these ideas would be greatly appreciated.


Quake style snapshot system for an MMO? I'm making an MMO style game in my spare time for kicks, I've been researching more and more into networking for video games and I've mostly been learning about Quake and Sources networking implementation where they have an authoritative server with a snapshot system where the client receives snapshots that reflect the current state, and the clients will send their input to the server and the server will simulate the game, etc. Is this what most MMO games use in terms of their networking? I ask this because as I'm implementing it, it seems very expensive if you want a lot of players , whereas the networking architecture seems more like it was designed for Quake or Source games where it's mostly shooter type stuff where you only have maybe 10 players at a time, sometimes you have 30 or so. To elaborate here, I mean that having even 10 players it costs a lot to send snapshots back and forth in terms of bandwidth, it can pretty quickly add up to megabytes. Is this normal? Is this expensive? I don't do a lot of network programming so I'm not particularly sure what is cheap or expensive in terms of bandwidth. I've currently implemented most of this system, though I've added regions so that the world is split up into multiple areas so that entities in region A don't care about the events, particles, and other entities, etc. in region B or C, D, and so on.


Handling incoming packets immediately or queuing them I'm using Golang to write a game server. I was wondering what the advantages of queuing the incoming packets for processing over processing them immediately. For example (processing immediately) each new connection client a new goroutine coroutine is created and within that goroutine a loop that reads from the network socket and has a switch statement that routes and handles each packet. Or (queuing) each new connection client a new goroutine is created and within that goroutine a loop that reads from the network socket and passes it to a queue. A second dedicated goroutine for this connection client has a loop that process the packets in the queue. Is this a pre optimization? How are MMORPG's (server side) packet recv handling handled in principle? I'm using TCP.


Is it feasible for a Server to send nothing more than a tile based area to a Client? To start, I have a good amount of background in networking (hardware, routers, ex.) but very little knowledge past the basics of network programming. This may seem like a stupid question, but I want to know what I am getting myself into while fathoming the implementation of multiplayer in my game. I am creating a tile based world, which is generated through a simple 2D Array. Let's say something like World 100 100 , for simplicity's sake. Currently, the render method only renders the tiles based on the resolution of the window, plus one tile (for smooth rendering during movement.) No matter how large the world is, (10x10, 1million x 1million) the rendering is flawless in performance. The gameplay needs nothing more than to know what is in the currently visible (rendered on screen 1) and at the most possibly SOME information of tiles in an area around the player. So anything more sent by the Server wouldn't be the full tile information. Ex. Items laying on the ground, ground type, trees, etc. would not be important in the area outside the player's view, but would only be what the Client Player needs to know about in those tiles. (Ex. Ultima Online's 'incoming names' where players could know a Character player or monster was just beyond the tiles in their rendered view.) I do not know very much about networking, so perhaps as I learn this might answer my question. However, I am curious if this is a feasible solution or if the idea is simply laughable. The information being sent would be about a 10x15 area of tiles, and each tile holds information about what is on the tile. More efficiently, everything would be an Object, where the tile holds all the Objects on the tile. Ex. Tile 4 4 holds Sword 23452, Rock2, Tree5, Player3, Monster4. Empty tiles would send nothing more than terrain type Grass, Sand, Water if not already loaded during Initialization Load. Some tiles would have a handful of objects Tree2, Sword 924, Gold, Corpse, Rock3 . So I cannot imagine that a tile would have very much information to send to the Client from the Server, since the Client mainly only needs to know the Texture that needs to be loaded and Position to place it on screen. Position being only two integers and Texture being one integer for a list of files to tell the client to render. At the craziest, the Server would have to send 150 tiles with information of only a handful of Objects OnLOAD, and from then on update only changes to tiles (if any) and any new tiles (10 to 15 everytime a player moves in a direction) and the direction of movement for characters on screen (so the client can simulate smooth movement between tiles). I assume I am correct in thinking this is an incredibly low amount of information being sent over the internet or between peers, so it should have little problems with performance even over laggy connections? Or am I so ignorant of networking that my mind will be blown when I finally get around to opening up my book on multiplayer networking? If it is a very low amount of information being sent between Client Server, would it make more sense to simply load the entire World on Initialization? Or 'Map' if the World is excessively large. And then after LOAD, send only tiles which are updated? I am still pondering how I should specifically deal with data. The book I am using as reference wants me to have a Linked List, where I add and remove objects, so everything is a bool. "Is there a Character? Is there a Tree?" I was thinking of a different approach, such as a container which holds objects, and Server logic that sends only what is required to tell the Client what to render. Possibly with objects that hold networking information within itself, which is sent out when called for by the Server.


How can I support direct P2P for mobile devices? I'm Interested in two or more player co op in Godot, via direct P2P without connection to a central server. I have this idea that would utilize two smartphones in proximity to one another. I don't know an awful lot about Bluetooth or networking so please explain simply.


Is RPC Safe and what is security layer of RPC? We're creating a MMO and I wonder is RPC safe or not ? Isn't RPC easily hackable by injecting to client and what is the security layer of RPC on Unreal Engine ? For example a player is walking and sending that information (new position, rotation etc) to other players, can't that player change movement speed or position with injecting ? What is validating is that movement is valid or it was a hack ? I checked on Google but didn't get answer for my questions. Thanks o


Real time Debugging Techniques There's nothing quite like the routine of tweaking a variable, compiling code that takes a few minutes, executing the code, realizing that your tweak was in the wrong direction and repeating the process all over again. I would like to start interacting with my game logic while a session is in progress. What are some of the ways you've handled doing this? I would be open to hear solutions for iOS, C C and C XNA.


Fair dice over network w o trusted 3rd party Though it should be a pretty basic problem, I did not find a solution for it How to play dice over a network without a trusted third party? The M players shall roll N dice, one player after another. No player may "cheat", i.e. change the outcome to his advantage, or "look into the future" before the next roll. Is that possible? I guess the solution would be something like public key crypto, where each player turns in an encrypted message. After all messages were collected you exchange the keys to decode the messages. Then the sha1(joined string of all decrypted messages) mod 6 1 is used to determine the die. The major problem I have since the message c s hould be anything, I don't know how to prevent tampering with the private keys. Esp. the last player to turn in his key could easily cheat (I guess). The game should even stay fair, if all players "conspire" against one player.


What's the performance benefit of saving all logged in characters in MMOs in regular intervals? The majority of MMORPGS have a Worldsave system that will save all the characters once every X hours. I guess the reason is performance. So why is this better, performance wise, than saving a character on disconnection?


How do I synchronise real time moves of players on a grid? I'm working on a real time game based on a grid. Each player can move a single square at a time. A server tracks the game state and notifies clients of changes. It's possible for two players to make a conflicting move, such as attempting to move to the same square. How can I fairly resolve such conflicts when they happen? My current approach is First come, first served When the server receives a move, it immediately updates the game state to reflect that. It then discards any conflicting moves it receives later. The problem is that the moment a move was received does not necessarily line up with moment it was sent. Players on a faster network connection will always have an advantage. How can I deal with this?


Implementing game synchronization between clients and server I'm creating a small online multiplayer game where I have multiple thin clients and an authoritative server. Both the client and the server have a fixed game loop. Now I have a game entity with the following properties X position float Y position float Direction float In the client, the entity is in constant velocity changing its direction based on user input and sends an input event to the server. LEFT, PRESSED Entity moves to the left LEFT, RELEASED Entity moves to the right Every event is queued on the server, and simulated the same way as on the client (calculating the new properties based on trigonometric functions) and the event is send to other players in the room. The other players apply the same simulation to that particular entity (keeping track of what key is pressed for each entity). Now after some time playing, the position and direction start to drift and stop being in sync. I suspect this has to do with floating point arithmetic(?) Is this implementation correct, rather than sending its position and direction every step? How would I solve this problem? I think I need to make the server the single source of truth and send regular state snapshots to the the clients to correct possible mistakes drifting? What would be a good interval to keep the clients up to date? At the moment, I'm broadcasting an event to every player in the room. What would be a nice approach to only send events to players near the entity? Would a quadtree work here (the same I'm using for my collision detection)?


P2P network hiding positions? I have been working on a P2P architecture for secure gaming and I have divided the problem into five sub problems Unlawful modification of sent game state Accurately drop cheaters Agreeing on a game state Avoiding "look ahead" cheat Hiding sensitive information from opponents The first four I have pretty much all solved but it is the last one which I am having trouble with. Before I go into details I just want to ask if there's anything I've missed in my list of making a "cheat proof" p2p network. I am not interested in cheats such as using aimbots, I am only interested in making the p2p network as secure as a centralized server. So in my effort so far on hiding sensitive information I've focused on the position of players in a game where the position of your opponent should not always be known. The problem then becomes how to determine if you should send you position to your opponent without knowing the position of your opponent. I have ruled out methods such as the opponent sending multiple false positions for you to compare yours too since your opponent can easily abuse such a system since he will get your position if one of the false positions happened to be "visible" from your position. The method I have been focusing on one in which you receive a "visual field" from your opponent and can thereby determine if you should send your position or not. This is however a problem in games such as League of Legends where the visual field of your opponent is also highly sensitive information. I have tried to solve this by transforming the visual field using a singular matrix meaning you cannot go from the transformed version of the visual field back to the original version, but since it is a linear transformation you can still figure out if your position is inside the visual field or not. This does not however work perfectly, the exact visual field cannot be restored after transformation, but information about the "slopes" in the visual field (the visual field is constructed by several lines, and the slope of each line can be determined) can be restored and this can be used to relatively inexpensively reconstruct the original visual field. In essence, what I need is a function which can determine if a position is "visible" or not, and reconstructing this function visual field has to be so computationally demanding that once you are done reconstructing the visual field it is no longer relevant for the game in action. Is there any super smart person out there who happens to know of such a method? Edit People seam kind of confused about the whole "vision field" so I aim to give a more detailed explanation here. The vision field consists groups of a set of lines, you can easily check if a position is inside one of these groups by just checking which side of the line your position is, if it's on the same side for all lines in that group you know it's inside that group and thus inside the vision field. The information being sent however is not this line, but a transformation of the line and the transformation (2 by 2 singular a matrix), you can still check which side of the line your position is on by first transforming it using the transformation you received and comparing that value to the transformed line. The key here is that the transformation is singular, meaning it is impossible to find an inverse to go back to the original line. However it is possible to determine the slope of the line which makes reconstructing the line by just checking on which side of the transformed line a lot of points lie until you have pinpointed the origin of the line a lot computationally cheaper than if you did not know the slope of the line. What I am looking for is a method for determining if a point is inside of an area, where reconstructing the area from the method is either impossible (which I doubt exists since you can always brute force it) or very computationally heavy.


How do games have low tick rates without causing input lag? For example, Minecraft. It updates the gamestate at a rate of only 20 second. And from what I've read, these multiplayer games do the same with their network communication, sending updates at that same speed. So it sounds like the entire game is, internally, running very slow (ignoring the render interpolation to not appear slow). But what I don't understand is how player input doesn't feel laggy as a result. If player input was only being sampled 20 second, you would feel the delay. But that isn't the case in Minecraft, it is extremely responsive. I assume that means player input is being sampled as fast as possible, at renderer speed. But that means the game is gathering input way faster than it can use it. If it updates the gamestate and talks to the server 20 times in a second, but gathers 200 input samples in that same time, how does it handle that? Is it perhaps just faking it locally, taking the latest player input and interpolating the renderer with it to appear responsive, even though that input isn't actually being used anywhere in the game? How does it decide which particular input sample to use when it's comes time to do a gamestate network update without losing information? I don't understand how to resolve the conflict between having too many input samples to use, and having input feel too slow.


Lag compensation in rocket game context I have read a lot of papers recently to understand the lag compensation concept recently. They were all about the same context shooter game where bullets move in infinite velocity. The most important thing is checking what was in the crosshair when the client created the fire command. If another player was there at that time, then s he's damaged. That is done by checking the world state at that time by finding a snapshot and executing commands until the fire command. How about firing a rocket? That is slow (not to mention other differences ignition time and area damage). That means, I cannot only check what was on the crosshair of the client at the command creation time. If I go back and check the world state at that time (with same method above), it wouldn't be enough. I would still need to do the simulation for the next snapshots until the most recent one (server's present). That would mean, if I have a time step of 15ms (tick rate 66) and I want to discard a command if it is older than 1.5 seconds, I need to keep the most recent 100 (1500 15) snapshots of the world. And every time a delayed command comes, I have to re simulate the world from that command's timestamp to present including reprocessing the commands with timestamps after that one. This sounds too much work on the CPU to me. Is this the same in the first scenario (infinite speed bullet)? What about lag compensation for movement commands? Would that be different? Or did I misunderstand something many things?


Should damage calculation in a competitive multiplayer game be done client sided or server sided? I'm interested in creating a moba style game like League of Legends and need help with a situation. More exactly I have an item that gives the player 50 Attack Damage or an ability that does 50 Attack Damage. Is the information about how much damage the items champion abilities do kept in client side of the game or the server. Option 1 I hit the enemy and the client tells the server to deduct 50HP from the enemy i hit or Option 2 I hit the enemy and the client tells the server only that I hit the enemy, then the server looks at the item I have ability used and based on code on the serves side deducts the 50HP


Should I consider a cloud based networking solution? In my spare time for the past few years, I have been working on both the front end and back end for a space based online game. This game is initially designed for the PC, and is hopefully able to host thousands of players in a massively playable universe. Along with the development of the game, I have been building the networking solution almost entirely from scratch. The architectural design of the networking solution is based on a fairly traditional master server sub server model. I recently was able to run some fairly decent scale tests on this model and was pleased to see that both my expectations and goals were met. Which leads me to my current fear. The basic idea behind the current solution is that the master server acts as a router. It knows about all of the currently active sub servers, including their load (cpu, memory, bandwidth etc) and what the sub server is assigned to handle. The master server has literally no other purpose. Each sub server is designed to handle one (or more) solar systems. The idea being as a player, you connect to the master server and tell it which solar system you want to go to. The master server looks to see if there is a sub server already assigned to this solar system and sends you there, otherwise it finds the sub server with the least load and assigns that sub server to the solar system before sending you there. The part that I am worried about is that this is pretty much as much as I can get out of this model. Once you have been sent to a solar system, you (and everyone else in that solar system) are on that sub server until you leave that solar system. Although I am happy with my testing so far, and that it looks to be able to handle around 300 fairly active peers, fairly comfortable on a well fitted server, I am worried if I ever end up in the situation where this isn't enough. I discussed this recently with a few acquaintances of mine. The discussion lead to a cloud based network maybe being a better solution than single server machines acting as sub servers. Atmittedly, cloud commputing is fairly unknown territory for me. With that being said I've spent some time looking into this and I am fairly confident with the basics, but I have the following questions I assume that if I were to re design the networking solution to work within a cloud based network, I would no longer need the master server sub server model, since I could build a single application that would handle all solar systems and peers, and that the cloud would scale based on the number of solar systems and peers? Any and all advice is welcome!


How to properly handle sending arrow key movement data to a authoritative server? I've made a little C server which receives UDP packets and shows me the incoming information. I want to make an authoritative server in C which simulates character movement and interaction in a 2D real time world and sends information back to a Unity game client where the information is then represented. My question is How does my server know how long a button is pressed in real time (example right arrow key to move character right)? My guess is that the client would send a UDP packet to the server on key press saying move this direction. The server would then simulate the character moving and new positional information is constantly sent back. When the Client releases the key a new UDP packet is sent to the server saying the movement key has been released thus stop moving this direction. BUT the problem is UDP unreliability and the lag between letting the key press up, and the server knowing that the key press is up which would make the character keep moving for a period of time after letting go of the key is this solved with proper movement interpolation?. Any ideas or information sources how to properly handle sending arrow key movement data to a authoratative server?


Authenticate player on backend server with google login I would like to create a mobile game which communicates with my own backend server. For authentication I want to use google Sign in(https developers.google.com identity sign in android backend auth), so users don't need to create an account. My backendserver uses a TCP connection to communicate with the client and I don't want to send the google login auth code unencrypted over the network. I read alot about SSL encryption, but I'm not sure if it is the thing I need and if this is sufficient. Another question I would like to ask is do I need to encrypt all packets my client is sending to the server. Because when I just do authentication over an encrypted connection, potential hackers could simply perform a man in the middle attack to access the account of a player after they logged in. So what would be the best way to send this token to the server, is SSL sufficient for this and do I need to encrypt the whole traffic my game creates?


How do I smooth out latency jitter in my netcode? I'm developing a multiplayer game and I'm following some articles I've found online to create an authoritative client server model. Reading this article, Valve says that every time a message is received, the client assumes the "current" time is the time in the latest packet, in the article they state it It is assumed in this paper that the client clock is directly synchronized to the server clock modulo the latency of the connection. In other words, the server sends the client, in each update, the value of the server's clock and the client adopts that value as its clock. Thus, the server and client clocks will always be matched, with the client running the same timing somewhat in the past (the amount in the past is equal to the client's current latency). Smoothing out discrepancies in the client clock can be solved in various ways. And interpolation of remote entities Each update contains the server time stamp for when it was generated From the current client time, the client computes a target time by subtracting the interpolation time delta (100 ms) If the target time is in between the timestamp of the last update and the one before that, then those timestamps determine what fraction of the time gap has passed. This fraction is used to interpolate any values (e.g., position and angles). Now obviously due to jitter, my interpolation looks terrible as I will receive time latency jitter. So my question is, is on this part "Smoothing out discrepancies in the client clock can be solved in various ways." What would be a good way to smooth out any discrepancies?


How to build a turn based multiplayer "real time" server I want to build a TCG for mobile devices that is multiplayer over the web (not local wifi or bluetooth). As a player plays cards I want the second player to see what is being played in "real time" (within a few seconds). Only one player can play at a time. Server requirements 1) Continuously listens for input from Player 1 2) As it receives input from Player 1, sends the message to Player 2 I know some PHP, but it seems like unless I had a loop that continued until I broke it (seems like a bad idea) the script would just receive one input and quit. On the mobile side I know I can open sockets using various frameworks, but what language allows a "stream like" behavior that continuously listens sends messages on the server? Or if I'm missing something, what would be the best practice here? EDIT I might have not made it clear before, but the mobile apps are native not web based. I guess I'm asking for specific suggestions on what some of the best tools or platforms for this scenario could be used i.e., PHP sockets, etc.


Lag Compensation in a Real Time Game I have been trying to implement some lag compensation techniques for a real time game, I've found some good resources online, but I don't think I fully understand the server side part of the problem. The game is a simple 2D game, where the player moves an entity around the map. There will be other entities with their own behavior that are controlled by the server, but I made it so that their movement can be easily interpolated. The player input is quite simple an analog stick and some commands (pick target, loot objective, etc.). The game runs at a fixed 10 TPS (it's on mobile and it's not that action packed, 10 TPS will suffice). The client will send the input state every tick (even if no input is present, like the analog stick is in the default position). It is worth mentioning that only one player is connected at the same time, so in a way this is not multiplayer, but I need to run this on the server as well to prevent cheating. I understand client side prediction and that's quite straightforward to implement. I am struggling with the server side part. As far as I can see I have 3 options The server waits for the input from the client then computes the new game state and sends it to the client. This is a viable option only because there is only one player. 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 though), 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. Is there a better way to do this? What are your thoughts?


How does a wow server handle which player position to set to each nearest players? I already understood how game developers could create very large game levels, bypassing the floating point precision limit. This was my very first mind boggling question, and I understood it when I read how some programmer told the story of some dungeon PC game. My question is more related to game networking, more precisely wow. There are no interruptions in the game level (apparently I think). Since the viewing distance is much smaller than the world size, and since there are a lot of players, you can't send all players positions because it would require too much bandwidth so you have to only send the nearest players positions, among a pretty big list of connected players. Those servers are almost always online, with a large number of players (only doing quests or idling into cities, since I guess dungeons and raids must be hosted on dedicated servers), and they must find a solution to save as much bandwidth as possible. So at one point the server has to determinate which players positions it has to send to which players, and when it has to stop sending it. I was wondering about how the server does this, because to me it seems to have O(n 2) or even an O(2 n) complexity. How do they do it ? Do they fragment into virtual tiles so they only check players in the nearest tiles ? Do they calculate this not so often so that the server can handle it ? A continuous online persistent world is quite awesome, but technically I don't really know how they do it.


P2P synchronization can a player update fields of other players? I know that synchronization is a huge topic, so I have minimized the problem to this example case. Let's say, Alice and Bob are playing a P2P game, fighting against each other. If Alice hits Bob, how should I do the network component to make Bob's HP decrease? I can think of two approaches Alice perform a Bob.HP , then send Bob's reduced HP to Bob. Alice send a "I just hit Bob" signal to Bob. Bob checks it, and reduce its own HP, then send his new HP to everyone including Alice. I think the second approach is better because I don't think a player in a P2P game should be able to modify other players' private fields. Otherwise cheating would be too easy, right? My philosophy is that in a P2P game especially, a player's attributes and all attributes of its belonging objects should only be updated by the player himself. However, I can't prove that this is right. Could someone give me some evidence? Thanks )


Client side Prediction and Reconciliation for movement I've explored the concept of client side prediction with reconciliation quite a bit and there's one thing that puzzles me a lot. From what I've seen in most guides, the flow looks a bit like this T0. Client sends MOVE command and immediately simulates a predicted result. T0. Server streams gamestate (server does not know about Client's MOVE command yet and thus the T0 gamestate does not contain results for it). T3. Client receives gamestate T0 from the server. T0 does not contain any movement and thus Client is forced to reconcile with the Server gamestate. This way, Client will have to reconcile with the Server every tick it receives because they will never agree. If Client would be delayed by RTT before predicting, Client and Server should agree most of the time, but that's an unwanted delay. If the Client submits a tickstamp with each command sent, the server can apply those commands pasttime. But this would mean that the client is authorative because it can make the server reconcile with its commands. There's also an issue here where players with a high latency will be changing a relatively distant past on the server, potentially undoing invalidating a lot of already streamed gamestates. I suppose the Client could simply pretend that T3 is T0 (sync to a different server tick depending on how high the latency to Server is) but I don't know the effect of that when interacting with other non predictable entities (such as other players). I guess the Client would take longer to reconcile with the correct Server gamestate because of the induced "tick latency". Is there something I'm missing here? Which is the best way forward for a twitch gameplay competitive game? I.e. Air Hockey or similar.


network programming simultaneous IO over sockets? In my curses based game, I decided to add multiplayer functionality over net, in addition to one keyboard mulitiplayer game. I use switch loop and in case it's 1st user's buttons, user 1 is acting appropriately and second otherwise, without blocking each other's movements i.e not waiting for opponents move. Now I read socket tutorials, and use server looking like this wait for 1st user to connect wait for 2nd user to connect loop read from 1st write to 2nd read from 2nd write to 1st Now problem is obvious, players would block each others movements, how this network multiplayer problems solved in games design?


How to reduce server traffic for 100 multiplayers game? I'm working on fast paced multiplayer game which has 100 players in single session. To sync entire game state to each player, server should send massive data if I did not any compression 24(transform per object) 100(total objects) 100(total players) 30(server update frequency) 7.2MB s ! This is completly unacceptable size. So I investigated someting technique for recuding packet size (like https gafferongames.com post introduction to networked physics ) Maybe I can reduce data size of (transform per object), by using quantization, Y axis only rotation and so on. Also, there is chance to reduce (total objects) for specific player (ex, send only near or visible object for that player). Reduced packet size example is (worst case) 16(transform per object) 30(visible objects per player) 100(total players) 30(server update frequency) 1.44 MB s ! I think this is still large for server! Is there any technique for more optimizing packet size? Another question, if I sending large block of state packet, should I split entire payload into small UDP packets for avoiding fragmentation? (application level packet fragmentation and assembling is efficient?) Thanks.


Acknowledgement reliability using UDP I have a question about UDP. For context, I'm working on a real time action game. I've read quite a bit about the differences between UDP and TCP and I feel I understand them quite well, but there's one piece that has never felt correct, and that's reliability, and specifically acknowledgements. I understand that UDP offers no reliability by default (i.e. packets can be dropped or arrive out of order). When some reliability is required, the solution I've seen (which makes sense conceptually) is to use acknowledgements (i.e. the server sends a packet to the client, and when the client receives that message, it sends back an acknowledgement to the server). What happens when the acknowledgement is dropped? In the example above (one server sending a packet to one client), the server handles potential packet loss by re sending packets every frame until acknowledgements are received for those packets. You could still run into issues of bandwidth or out of order messages, but purely from a packet loss perspective, the server is covered. However, if the client sends an acknowledgement that never arrives, the server would have no choice but to eventually stop sending that message, which could break the game if the information contained in that packet was required. You could take a similar approach to the server (i.e. keep sending acknowledgements until you receive an ack for the ack?), but that approach would have you looping back and forth forever (since you'd need an ack for the ack for the ack and so on). I feel my basic logic is correct here, which leaves me with two options. Send a single acknowledgment packet and hope for the best. Send a handful of acknowledgment packets (maybe 3 4) and hope for the best, assuming that not all of them will be dropped. Is there an answer to this problem? Am I fundamentally misunderstanding something? Is there some guarantee of using UDP I'm not aware of? I feel hesitant to move forward with too much networking code until I feel comfortable that my logic is sound.


Should I ping for a TCP based game? I have a head to head game where two players communicate through a server based on TCP. I am planning to implement a ping pong mechanism in order to detect network disconnection situations. For example, A pings B every 500ms. If A receives no response from B, A shall consider B is disconnected. If A receives no response from the server, A shall consider A is disconnected itself. Do you think this ping pong system is needed or other method is recommended?


Send regular keyboard samples OR keyboard state changes over network Building a multi player asteroids game where ships compete with each other. Using UDP. Wanted to minimize traffic sent to server. Which would you do Send periodic keyboard state samples every from client every to match server physics update rate e.g. 50 times per second. Highly resilient to packet loss and other reliabilty problems. Out of date packets disacarded by server. Generates a lot of unnuecessary traffic. Only send keyboard state when it changes (key up, key down). Radically less traffic sent from client to server. However, UDP can lose packets without you being informed. So the latter method could result in the vital packet never being resent unless I detect and resend this in a timely manner.


How to synchronize actions like jump in multiplayer? I am a newbie game developer and I have been researching about multiplayer games. I observed that there's always some latency, the players always get updates from past actions. But there are techniques like dead reckoning to handle the latency. I can predict the movement and make movements smooth. But how would I make actions synchronize like jumping, stopped walking, etc. Suppose, client A was moving, he was at 100m at 10.2 time with 100m sec velocity and sended this information. Client B would receive this information somewhat later, let it be 10.4. So at client B, I can use prediction and place client A at 120m. But what if, client made a jump at 110m at 10.3. I can't predict that and since I have been using prediction I can't show client A jump in past. I may deal with this problem by not sending jump action at all. But what if my game has some voids where players can fall and die. So, If I don't sync jump actions, other players will observe that one player was running then he falls in void and then again appear on the screen destroying the visual engagement. Jump is just an example, there might many scenarios where prediction can't work. So, How do deal with them. One such example can be Multiplayer Online battle arena games like Awesomenauts.


Why do multiplayer games chat services ever need to be able to open all NAT ports? I understand that games need to be able to open NAT ports in order to receive incoming connections. What I do not understand is why there is an issue between "limited" and "open" NAT. The only reason I can see that a game would ever need to have the flexibility to open any port is if it is intending to accept incoming connections on ports that aren't specified in advance as part of the protocol. (If there was a restricted set specified in advance, forwarding these and no others should satisfy all of the game's demands for NAT forwarding, meaning that "open" would not need to be a thing.) This seems to imply there's some port negotiation going on as part of the protocol (otherwise how does the connector know that this port, not specified in advance, is available?) but if a connection is already established to conduct the negotiation, why move to a different port? And even then, why can't negotiation be limited to a subrange of ports rather than the entire range?


How do I avoid users hacking my network games from the client side? I've decided to make an online game the server sends packets of information to the client application, which is going to simulate what it gets from the server. The client makes a part of the design of the game, and sends the new state back to the server for processing. The clients can send fake information to the server, and inform the server that I've done the task successfully, without trying. Assume a Counter Strike game the client may send a fake packet to the server and tell the server that I've defeated someone. How can I avoid this violation?


PlayFab Custom Server Integration I want to use PlayFab to host and manage my server instances but I'm unclear on how to implement the requirements they listed here. My server SDK is in .Net and I'm hoping I can fulfill all the requirements with plugins written in C . How can I and make parameters available in the command line input? Am I supposed to return information by printing on the console?


How to synchronize events to clients? I need to keep the client updated on data that's rarely changed (like health) or when an event occurs (like when a player is attacked and should have " 10 hp" above him). Those 2 specific part should be interdependent btw. I need a way to instantly send this data to clients (or just without big lag), without resending it too many times and I need to be sure the clients received it. I cannot just send a request to the client when something happens, because I'll just be sending a lot of tiny messages to a lot of clients and that's bad for performance. I was thinking of accumulating packets of data (per client) and sending them no more often than 5 times a second and then if the client doesn't say he got a package just resend it. This way if nothing happens there is no overhead and if a lot of events are going on I'm sending them in bigger packets. Is my solution good? Is there a better, more popular way of dealing with this?


How do I let game maker know that recieved json data is an array? In python I created an array called lobbyList "Awesome","Funny","Epic" I sent this array to Game maker studio 1.4 using JSON, I made a variable called RecievedData and made the following script var name argument0 var data argument1 RecievedData json decode(data) show message(RecievedData) Let's me know data has been recieved I can recieve data fine, but when I show message(RecievedData) it returns 4, when I do show message(data) it gives me a string of "Awesome","Funny","Epic" So how do I tell game maker that this is an array and not just a number or string? I want to draw this array coming from the server into a lobby list but for the life of me, I can't figure out how say this is an array.


Client send rate for network games As I understand for a client server model, it's common practise to send input to the server and then the server applies the input to update the state of the game. The server then sends updates to clients regularly. The client in the meantime does prediction, before it receives the "true" state. My question is how often to send input. Surely it should be sent every frame otherwise some input (during frames which are not sent) will not be processed by the server. Will this be too heavy for the network. What is common practise?


Should the server calculate the time of a player's input, or trust sent data? I am curious about the details of lag compensation in games. I have read a lot of articles about it, for example Source Engine Multiplayer Networking Fast Paced Multiplayer Gabriel Gambetta How do Multiplayer Game s sync their state? And I still have this question At the 1st link, the Valve developers give a formula to compute the time when the command should be executed Command Execution Time Current Server Time Packet Latency Client View Interpolation But on the 3rd site, the author says that the client sends the Command Execution Time and the server does not need to use that complicated formula to calculate something that the client can give the server for free. I mean, the player will always send the correct info about Command Execution Time, so the server can believe him. Which one is correct? Or are both suitable (for different situations)?


Multiplayer tile based movement synchronization I have to synchronize the movement of multiple players over the Internet, and I'm trying to figure out the safest way to do that. The game is tile based, you can only move in 4 directions, and every move moves the sprite 32px (over time of course). Now, if I would simply send this move action to the server, which would broadcast it to all players, while the walk key is kept being pressed down, to keep walking, I have to take this next command, send it to the server, and to all clients, in time, or the movement won't be smooth anymore. I saw this in other games, and it can get ugly pretty quick, even without lag. So I'm wondering if this is even a viable option. This seems like a very good method for single player though, since it's easy, straight forward (, just take the next movement action in time and add it to a list), and you can easily add mouse movement (clicking on some tile), to add a path to a queue, that's walked along. The other thing that came to my mind was sending the information that someone started moving in some direction, and again once he stopped or changed the direction, together with the position, so that the sprite will appear at the correct position, or rather so that the position can be fixed if it's wrong. This should (hopefully) only make problems if someone really is lagging, in which case it's to be expected. For this to work out I'd need some kind of queue though, where incoming direction changes and stuff are saved, so the sprite knows where to go, after the current movement to the next tile is finished. This could actually work, but kinda sounds overcomplicated. Although it might be the only way to do this, without risk of stuttering. If a stop or direction change is received on the client side it's saved in a queue and the char keeps moving to the specified coordinates, before stopping or changing direction. If the new command comes in too late there'll be stuttering as well of course... I'm having a hard time deciding for a method, and I couldn't really find any examples for this yet. My main problem is keeping the tile movement smooth, which is why other topics regarding synchronization of pixel based movement aren't helping too much. What is the "standard" way to do this?


Should I switch to UDP for a mobile p2p game when considering 3G network? I have been making a mobile game that is similar to "Street Fighter" where two players play with each other via Internet. The game sends out a small packet (controller status) to the other party every 30ms (a lot of packets going on). I am currently using a server to connect two players and all communications are via TCP through the server. The server load increases a lot even for just 30 concurrent players. I know it sounds not wise to let the communication go through the server, so I think the best design should let these two players to communicate directly via UDP after the server hooks them up. However, I have some questions when trying to move on to the new design Since it's a mobile game, players might be using 3G network a lot. Does UDP hole punching work well in 3G network? Does it matter when a player is actually moving physically (such as inside a car)? Do you think I should change the design or any recommendation of better design concepts?


How do we make online games deterministic? I am trying to understand how networking in games work as I am trying to make an online game myself. I can't grasp how it is possible to synchronize the players, in order to make the game deterministic. I found an article saying this in order to ensure that the game plays out identically on all machines it is necessary to wait until all player s commands for that turn are received before simulating that turn. This means that each player in the game has latency equal to the most lagged player. This makes sense and I also came to the same conclusion after hours of drawing graphs with various scenarios. However, there are some games where one player can have 500ms delay, and another player could have 40ms delay. In this case, how is the game deterministic ? Lets name players with 40ms, 500ms delay Player40, Player500 Lets say that Player40, shoots Player500 with an instant laser shot at T1 0ms. Exactly 40ms after the Player40 actually clicked with his mouse to shoot (so T2 40ms), The "laser shooting event" registered on the server and returned "ok, you can execute laser shoot" to Player40. So, the shot is being applied on Player40's machine and on his screen he sees that he killed Player500, and the corpse is lying on (x1,y1,z1). Meanwhile, what happened on Player500's machine, was that Player500 was running straight. A few moments later he sees a laser a few feet behind him, he dies even though the laser didn't hit him, and his corpse is lying on (x2,y2,z2). Since this scenario never happens in some games, does this mean that those games are deterministic ? How is something like this possible, without forcing all players to get a delay equal to the delay of the most lagging player ?


Using Unity's uNet to create a turn based RPG I've been checking some tutorials about uNet and it seems pretty powerful. The NetworkManager is a great tool when you want to make generic games, but what is troubling me about it is the need of spawning a "Player". I intend to create a turn based RPG, and for that, during the battle there's not a "physical player entity", there's two players which have a set of monsters and the players can select a monster to attack the opponents', but the player itself doesn't exist, in the end it sums up to a trade of commands between the clients. How can I achieve such an architecture with uNet? Should I discard the use of the default NetworkManager? Should I simply create a bodyless Player and go along with it?


Multiplayer netcode where all units, including server, are untrusted possible, feasible, etc.? Most professional video games use either a peer to peer architecture or a client server architecture. In the former, clients often trust each other, and instead employ anti cheat techniques to ensure that all clients are using the same version of the game. In a client server architecture, the company owned server manages the game, and each client only needs to trust the server without trusting any other client. My question is how might I write a game network architecture such that the server is not necessarily trusted either (e.g. it is another client, or is buggy, or has been compromised), and do so in a way that does not take too much processing power away from the game? I know that the blockchain algorithm (as infamously used by Bitcoin and other cryptocurrencies) does provide this as long as at least half of the computing power is owned by trusted machines. While this may work for long term actions (such as match verdicts), it doesn't work as well for the frame by frame actions of action games and can also be too slow for turn based games, to say nothing of the computing power it requires of the clients or of any dedicated servers.


Random Disconnects on UNET Using UNET, I can't host a game for more than a few minutes unless both server and client are on the same computer. It appears that I am not alone in this. Essentially, any latency problems or packet loss triggers an immediate disconnect. Rather than just getting lag, the client gets booted. Does anyone know how this could be dealt with?


How to perform game object smoothing in multiplayer games We're developing an infrastructure to support multiplayer games for our game engine. In simple terms, each client (player) engine sends some pieces of data regarding the relevant game objects at a given time interval. On the receiving end, we step the incoming data to current time (to compensate for latency), followed by a smoothing step (which is the subject of this question). I was wondering how smoothing should be performed ? Currently the algorithm is similar to this Receive incoming state for an object (position, velocity, acceleration, rotation, custom data like visual properties, etc). Calculate a diff between local object position and the position we have after previous prediction steps. If diff doesn't exceed some threshold value, start a smoothing step Mark the object's CURRENT POSITION and the TARGET POSITION. Linear interpolate between these values for 0.3 seconds. I wonder if this scheme is any good, or if there is any other common implementation or algorithm that should be used? (For example should i only smooth out the position? or other values, such as speed, etc) any help will be appreciated.


How can I implement a game locator or proxy server? I have a turn based strategy game which already has a multiplayer server client layer that works fine on local network (where one server is set up and players connect to it). I would like to extend this architecture to allow players to play via Internet, but I don't want to have a dedicated game server for that, especially due to performance issues. The game's AI is runs on the game server of course, and multiple games with computer players would "kill" the machine. I would like to have some kind of "central connection point" server that does not run the game logic, state or AI but can be used by players to find servers hosted by other players. How can I implement this?


Interpolation Jitter I am trying to interpolate players in a multiplayer game like so var lastTime now (1000 config.serverUpdateRate) for (var i 0 i lt players.length i) tmpObj players i var total tmpObj.t2 tmpObj.t1 var fraction lastTime tmpObj.t1 var ratio fraction total tmpObj.x UTILS.lerp(tmpObj.x1, tmpObj.x2, ratio) tmpObj.y UTILS.lerp(tmpObj.y1, tmpObj.y2, ratio) The server update rate is the frequency with which the server send the player positions. The x2 is the newest position and x1 is the position from the previous update. Now this works fine on my localhost and on an empty server. But as soon as the game server has around 60 people on it, it begins to stutter. I am assuming that this is because the positions are coming in at an inconsistent rate. How can I adjust for that in my interpolation? You can see the issue in action here http moomoo.io I have tried to simply interpolate without lerping, but the movement felt too floaty. Also client prediction is not an option in this case


Game networking , server send rate I've been writing some server code recently and I ran into a bottleneck. If a server is capable of sending data at 60hz, with 1 client it would send data to that client at 60z, with 2 clients this would drop to 30z, then with 3 clients to 20hz,etc... This is because the server can only send data to one client at a time, Is my logic correct here? For example, if I had 50 clients and I wanted each client to receive 60 updates per second the server would have to tick at (60hz x 50 clients) 3000hz!? Is there a more efficient way this is done?


Design Architecture of a game waiting room I have some experience in creating singleplayer games, but for a new project I want to implement also a multiplayer. I can imagine what kind of information (position, textureId, ...) i have to send over the network. But hey, I can't figure out how I "could" represent a game waiting room. Which means One player creates a new game (What happens here?Does the server code calls a new instance of the game, but does not start the game yet???) The player, who created the game then either waits for additional players(in maximum 4) or he starts a solo game (Should my game has something like a value for currentPlayers ? Or is this managed by server code?) Also can you explain what exactly server code means? Which common functions should it handle (in context of creating a game room)? How can I make sure, that other players can also start new games As you can see I am a complete beginner to networking, but i do know about TCP and UDP, but the only thing i have done with it was a simple echo server... What am i looking for are simple pseudocodes oder examples, but please explain briefly.


Fixed timestep, how to determine how far back other clients are simulated I'm working on networking code for a social MMO (very low intensity compared to an FPS) and have a question about fixed timestep. This answer does a good job of explaining the forward dating part of utilizing a fixed timestep, but doesn't seem to have the whole picture. If the forward dating was meant to account for the packet getting all the way through the server to the other clients, wouldn't it have to either take into account the latency of the most latent client in order to arrive in time, or deal with it being late? I assume this is where the "simulate other clients as being a few ticks behind" concept comes in. My question is how is this back dating offset calculated? Is it a single number for all other clients, or should it be variable through the server sending each client's latency? What goes into the calculation? I would assume that the starting point is any delay caused by differences in tick rate between the game tick and networking tick (e.g. game is 60 ticks s, network is 20 and both are in phase, you need to push clients back at least 2 ticks to let the server's network re tick.) Is this understanding accurate?


How to organize messages queue in a fast paced multiplayer game I'm trying to develop a fast paced multiplayer game. I decided to build my own protocol over UDP and now I'm stuck with the following question. The idea of the protocol is very basic and it's similar to many others Client does NOT do any game logic except of some predictions (like smooth walking). It just sends 'ping', 'connect', 'disconnect' and 'keypressed' 'keyreleased' actions to the server. On contrary, the server does game logic based on the users inputs and sends diffs to each client every 30 ms As I already mentioned, the client sends 'ping' messages (to notify server that we're still alive when there's no other messages in some period of time) as well as 'keypressed' 'keyreleased' stuff. I thought that the 'ping' messages can be unrelirable the client sends them at steady intervals anyway, so if one was lost, nothing bad will happen. However, such messages like 'keypressed' and 'keyreleased' should be reliable. By this I mean that the client should resend them in case of any failure and they should appear on the server in the same order they were sent (otherwise 'keyreleased' message could arrive before 'keypressed' resulting in the incorrect game behavior). So, the questions is how is it usually handled? I mean, what is the right way to implement such logic on the server? Should I queue all incoming reliable messages in some container and wait until messages with smaller sequence IDs also arrive? If so, what should I do with unrelirable messages then? Because I definitely shouldn't wait before 'ping' message arrived (and there's a chance that it won't arrive at all). Should I use a distinct sequence numbers for unrelirable messages or should I make 'ping' messages reliable as well?


How do you build a matchmaking service for an iOS turn based board game? I want to build a board game that matches players with similar skill levels against each other. Take for example a chess iOS app. Log in, and the game pairs you up against someone with a similar elo rating. But there's a network infrastructure they're using. I haven't been able to find a suggestion for what kind of network architecture I should use. I've tried Google and searching on YouTube for how to build a multiplayer solution, and I haven't been able to find anything specific. The closest thing I have is to just use the built in GameKit features Apple offers. Otherwise I have to use some things called REST, SOAP, Amazon AWS, or Unity's UNET multiplayer matchmaking service. And that's all fine, but I haven't been able to find any specific directions on how to use those services. What I'm trying to say There doesn't seem to be a stock, default solution for multiplayer matchmaking in 2018. What should I use? What can I use? Should I just stick to the basic Game Center functionality? Should I explore other services or take a few months to build a custom solution? What's the most efficient route towards building a multiplayer server for a simple board game between two players?


How do I prevent identity spoofing in a multiplayer game? I'm thinking about clients spoofing IP addresses, tricking other clients that they are the server that sort of stuff. (I don't know much about this, so if this is completely wrong, please correct me.) What should I do to prevent this? Because it is a real time game, if I were to use encryption, I would use something fast and secure like RC4. Should I encrypt packet data with a key, that the server gives to the client? If it makes any difference, I'm using UDP.


Is there a library or a framework that handles networking in an RTS? I'm aiming for making a(n) RTS game with networking so instead of doing tedious stuff like networking I wonder if there is a library framework that will save me the effort. I intend to make that game in Unity if it is of any interest.


How to open auto detect LAN connections? After sucessfully creating my first online multiplayer with servers and clients in UDP, I am wondering how LAN connections works. As it is right now, I need to open a server and forward the ports for the server if public. In LAN, they connection is possible but requires the local IP address. However, if we take Minecraft or Starcraft, the game is able to auto detects servers on your local network. How are they achieving this ?


Implementing network smoothing We are making a multipler first person shooter. The client sends it's position to the server at a fixed rate (currently at 10Hz). The server sends a single message contatining all player's positions to all players at the same rate (10Hz). As expected, the movement is pretty choppy since the 60fps game is only recieving updates 10 times a second. What is the best way to smooth this movement? The most obvious way would be to interpolate between the last two packets, so that the interpolation finishes as we recieve a new packet. But this adds an instant 100ms delay for all players. The other way would be to use the velocity and acceleration inferred from the last few packets to predict where the player is before the next packet arrives, however if the prediction is wrong, the player would tend to jump as soon as a new packet is recieved. Does anyone know how AAA titles solve this problem?


Would adding delay to inbound traffic give you an advantage in online games? Wouldn't adding a latency delay to inbound traffic and limiting your download speeds to a low but playable standard give you an advantage in online games, especially shooters? Because wouldn't your shots be registering as normal (using upload outbound) while anything that attempts to hit you (download inbound) would be delayed and or slow?


Networking with UDP, should I keep sockets open on the server I am working on making a 2D platforming game that will have multiplayer functionality. Over the last few days, I have done a lot of reading regarding how to deal with the networking, and believe that I am on the way to implementing some of the concepts I have read about. I have decided to go with an Authoritative server client model, where multiple clients will send actions made by the user to the server, client will predict the players next steps before comparing against the Authoritative reply from the server, etc. This seems to have been suggested in numerous corners of the web regarding games networking, and seems reasonable. Before jumping straight into trying to get snapshots sent from the server, I wanted to make sure that I had an idea of some of the technical nuances of a language, as conceptual knowledge can only get me so far. I have set up a simple Echo Server that has worked rather well for a single client, but now my next step is to have multiple clients connected to the server at a single moment, and have each message that is sent from a client echoed to all clients connected to the server. I feel that the answer might be language dependent, so I will mention now that currently I am using Java for the networking (a little bit of preliminary testing may suggest that Java has significant overhead in its network implementation, so I am open to change upon suggestion). I am using UDP for speed sake (and this seems to be what is predominantly suggested). My question is with the server, should I be keeping each DatagramSocket that represents a connected client open and send DatagramPackets directly out without ever closing them (until the program terminates, client disconnects, etc.), and have them stored in some form of Collection, or should I close them after each message is sent and create a new outgoing socket whenever I need to send a packet? There are obvious performance disadvantages of creating a socket whenever I need to send a message, but is there some fundamental reason that I have not come across that suggests leaving sockets open is not a good idea?


networking how to deal with serverside packet arrival delay? Let's assume each client sends a packet every 0.05 seconds. (rate 20) Server update tickrate is 60 and it sends data back to client every 1 30 seconds. Now client A has 50ms ping time and it sent each data at A 5, B 5.05, C 5.10 second. But due to some networking issue, server received each data at A 5.05(good), B 5.10(good), C 5.18(bad! it delayed 0.03 seconds.) When server get the packet A at 5.05 seconds, since each packet contains client data(like commands) for 0.05 seconds, it updates the entity based on this A packet for 0.05 seconds. after that, server time is now 5.10. and the next packet, B is already arrived so server just can keep updating. At 5.15, now server has to update the entity with next packet, which is C, but there's no packet! Server has to wait for 0.03 seconds till next packet will be arrived. now, server is behind 0.03 seconds from client. sync failed. I have two idea for solving this problem. Server maintains its own client's time and sends back to client. For client side, when there is heavy desync between client and server, the client syncs to the server time. Solution 1 is still applied. but there is one more. like entity interpolation, there is packet interpolation. Client sends each packets every t seconds which is (t SEND TICKRATE CLIENT LAG ) . It means server gets next packet after t LATENCY seconds which is always larger than SEND TICKRATE, 0.05 in this assumption. So when server gets packet, it doesn't update it immediately but waits for some time (like 0.03 0.05 seconds). Now server has next packet with a high probability. I think Solution 2 is good. But the drawback is, client renders other player's data behind RTT Entity Interpolation time Server packet Interpolation time , so for a fast paced game, Shot behind the wall will more happen. What technique is used in other fast pace game like league of legends or overwatch?


How to synchronize the ball in a network pong game? I m developing a multiplayer network pong game, my first game ever. The current state is, I ve running the physic engine with the same configurations on the server and the clients. The own paddle movement is predicted and get just confirmed by the authoritative server. Is a difference detected between them, I correct the position at the client by interpolation. The opponent paddle is also interpolated 200ms to 100ms in the past, because the server is broadcasting snapshots every 100ms to each client. So far it works very well, but now I have to simulate the ball and have a problem to understanding the procedure. I ve read Valve s (and many other) articles about fast paced multiplayer several times and understood their approach. Maybe I can compare my ball with their bullets, but their advantage is, the bullets are not visible. When I have to display the ball, and see my paddle in the present, the opponent in the past and the server is somewhere between it, how can I synchronize the ball over all instances and ensure, that it got ever hit by the paddle even if the paddle is fast moving? Currently my ball s position is simply set by a server update, so it can happen, that the ball bounces back, even if the paddle is some pixel away (because of a delayed server position). Until now I ve got no synced clock over all instances. I m sending a client step index with each update to the server. If the server did his job, he sends the snapshot with the last step index of each client back to the clients. Now I m looking for the stored position at the returned step index and compare them. Do I need a common clock to sync the ball? EDIT I've tried to sync a common clock for the server and all clients with a timestamp. But I think it's better to use an own stepping instead of a timestamp (so I don't need to calculate with the ping and so on and the timestamp will never be exact). The physics are running 60 times per second and now I use this for keeping them synchronized. Is that a good way? When the ball gets calculated by each client, the angle after bouncing can differ because of the different position of the paddles (the opponent is 200ms in the past). When the server is sending his ball position, velocity and angle (because he knows the position of each paddle and is authoritative), the ball could be in a very different position because of the different angles after bouncing (because the clients receive the server data after 100ms). How is it possible to interpolate such a huge difference? I posted this question some days ago at stackoverflow, but got no answer yet. Maybe this is the better place for this question.


Multiplayer tile based movement synchronization I have to synchronize the movement of multiple players over the Internet, and I'm trying to figure out the safest way to do that. The game is tile based, you can only move in 4 directions, and every move moves the sprite 32px (over time of course). Now, if I would simply send this move action to the server, which would broadcast it to all players, while the walk key is kept being pressed down, to keep walking, I have to take this next command, send it to the server, and to all clients, in time, or the movement won't be smooth anymore. I saw this in other games, and it can get ugly pretty quick, even without lag. So I'm wondering if this is even a viable option. This seems like a very good method for single player though, since it's easy, straight forward (, just take the next movement action in time and add it to a list), and you can easily add mouse movement (clicking on some tile), to add a path to a queue, that's walked along. The other thing that came to my mind was sending the information that someone started moving in some direction, and again once he stopped or changed the direction, together with the position, so that the sprite will appear at the correct position, or rather so that the position can be fixed if it's wrong. This should (hopefully) only make problems if someone really is lagging, in which case it's to be expected. For this to work out I'd need some kind of queue though, where incoming direction changes and stuff are saved, so the sprite knows where to go, after the current movement to the next tile is finished. This could actually work, but kinda sounds overcomplicated. Although it might be the only way to do this, without risk of stuttering. If a stop or direction change is received on the client side it's saved in a queue and the char keeps moving to the specified coordinates, before stopping or changing direction. If the new command comes in too late there'll be stuttering as well of course... I'm having a hard time deciding for a method, and I couldn't really find any examples for this yet. My main problem is keeping the tile movement smooth, which is why other topics regarding synchronization of pixel based movement aren't helping too much. What is the "standard" way to do this?


How does the 3G network assign IP to smartphones? I am playing a game on the 3G network using Android or Iphone. Suppose I am moving from one cell to another Will the IP Address change? If yes, then how can I continue the same game while changing the base station, as my IP address is already registered in The game server? Is there something DHCP?


NavMesh LoS and "Containing" For a gameserver backend, I have a navmesh for "walkable" areas in form of points triangles. Now I want to check every gametick if the client is still in a legit place and if he shots casts a spell, if his target is in line of sight. I found several possibilities, but I am not sure what is performance wise ideal. To check if the player is still in the allowed area (and not wallhacking) I would check if his position is in one of the triangles with a algorithm using barycentric coordinates like this https github.com SebLague Gamedev Maths blob master PointInTriangle.cs But this would mean that every gametick I have to check soooo much triangles. To check if its LoS I could either check if the line from the player to its target crosses one of the "border" lines of the mesh (which have no other triangle next to it). Those border lines could be computed at bake time and are just a static list for each level. But still it would be a lot lines per check. Second option I found would be to start a Simple Stupid Funnel Algorithm (http digestingduck.blogspot.com 2010 03 simple stupid funnel algorithm.html) until LoS is broken. The questions now are How does a good gameserver handle this can it be optimised? What way to check is the best fastest? Is it common to only check if the position is legit every now and then or every gametick? The Levels are fairly simple ( 300 mesh triangles, 200 border lines, 10 players, 10 npcs maybe)


Should I use threads to check sockets for multiplayer game? In a multiplayer game does the code to get send info from to sockets reside in the game loop or does it belong in its own thread?


NodeJS client gameloop running slightly faster than server gameloop So I'm working on a real time multiplayer game in NodeJs (Client and Server). Both loops handle the same "physics" (movement at a constant rate) and both are running at 40hz or 40 times per second. I am using setInterval on both client and server with a delay of 40ms. The issue is that my server average delta between each tick is 41 and my client average delta between each tick is 40. This leads to results like this See in the last result, there is a difference of 46 ticks meaning the client is rendering about 1.8 seconds ahead of server time. My first guess on solving this is to sync the client every so often but that would lead to it "teleporting" backwards quite often due to how much it is desyncing.


Securing a TCP connection on iOS for an MMO I am currently building an iOS MMO and I'm leaning towards using TCP as my networking protocol over the higher level HTTP (for the speed difference and the fact that it does not require the client to poll constantly for updates.) Now, through my research I know that with MMO and any client server multiplayer games, you should never trust what the client sends to the server. As an extension of that, you wouldn't want anybody to read your packets to see the contents so it's harder for them to send correctly formatted data to the server. (Maybe I'm paranoid.) The only problem is, where in HTTP there is great support for a secure channel in HTTPS through SSL where the setup occurs mainly server side, I am not aware of a way to achieve the same thing on TCP. Is there any resource I could be referred that could help me achieving similar security, or at least good enough, on both the iOS side and server side? On a side note, if the answer involves doing the encryption and decryption on the client side, would that severely impact the performance of my application? Thanks!


Using peer to peer for prediction in a client server network model By implementing peer to peer connections between clients in a client server network model I should be able to increase the prediction fidelity as this theoretically would provide the client with other clients commands for a given tick earlier than it would receive the servers game states for the same tick. One problem I can think of is that clients would have to be able to interpret other clients commands (usually they just have to listen for game states, not commands). This would be a little bit like an RTS model I guess. This should be solvable without any negative effects on gameplay. Another problem is that clients could cheat by sending fake data to their peers when it is beneficial to them. This can be mitigated by having the client aware of the real commands through the server and have them immediately stop listening to any clients that fed it false data. This should therefore be solvable with different degrees of negative effect on gameplay depending on the design of the game and how impactful a few ticks of wrong command info is at the worst possible moment. (Unfortunately, you can't have the server punish any client because it has no idea who's lying, it can only help clients themselves understand if they are being lied to by providing them with correct data). Am I correct in assuming that this would increase prediction fidelity or is there something I'm not accounting for? The idea is that this allows the client access to some information about the other clients faster than in a traditional non peer to peer model where it would base predictions solely on its own commands.


What is the impact of many AI enemies on state replication networking? Imagine an online coop style FPS or TDS game where say 2 6 real players fought large amounts (20 60 concurrent) of AI enemies. Could this style of game be reasonably networked over the internet using a Quake or Tribes style partial state replication model? Almost every coop game I know of uses a lockstep style networking in these cases (even games like Halo which use state replication for normal multiplayer, but lockstep for coop firefight). My concern is that the network download (for clients) and upload (for server) overhead of each AI would end up being about the same as if a real player was in the game. Is this a real concern? Or is the limiting factor on the number of players more about how much data the players upload? TLDR Can large numbers of AIs be reasonably networked to a few players with a partial state replication model or is lockstep the only real solution. Any help here would be great!


What is better? Lots of small TCP packets, or one long one? I am sending quite a bit of data to and from a server, for a game I'm making. I currently send location data like this sendToClient((("UID " cl.uid " x " cl.x))) sendToClient((("UID " cl.uid " y " cl.y))) sendToClient((("UID " cl.uid " z " cl.z))) Obviously it is sending the respective X, Y, and Z values. Would it be more efficient to send data like this? sendToClient((("UID " cl.uid " " cl.x " " cl.y " " cl.z)))


How to design a server for a multiplayer game? I'm trying to write a multiplayer game where players join small matches with other players. What I also want is a way for players to login and go online. How would I design the a server that could handle logging in, matchmaking and the actual running of the match? I'd like to have multiple threads on the server to handle input from all the players, but I'm not exactly sure what I want to put in a single process and what I want to split apart. How would I set up the sockets for something like this? I'd probably end up having this run on Amazon EC2 or something similar if that makes a difference. I was planning on making the game a MOBA where there would be a small number of players (6 10) and latency would be relevant.


Do I need TCP socket? My game uses UDP sockets to stream updates between server and client and I've also made a reliable channel that resends messages if there's no response and makes sure same message isn't processed multiple times. But TCP is specifically designed to be reliable and the people who made it probably have more experience than me. So would it be good to use TCP to send commands such as "attack", "play animation", etc. instead of my UDP implementation? (Of course I mean TCP sockets that don't delay sending the data (Nagle algorithm))


Some practical issues with component based game object systems I am creating my own game engine just for fun and brain development. I have chosen various free and open source libraries to integrate and now I have come to the engine architecture. I intend to use server client architecture and I prefer to be more "data driven" so I can organize my game state in MySQL database. I recently read about a component based design which plays nicely with data driven systems. The idea is that game object components are bare properties and the behavior is implemented in so called subsystems. Each subsystem (like Physics, Render, Animation, Sound) "knows" only about related components and also is able to tie itself to other systems if needed. Those subsystems are singletons (single instances). I can use the observer pattern so each subsystem can subscribe to property changes which are important for the particular subsystem. The subsystems subscribe to prop change events in some particular order thus creating subscription chains. But this can create one problem SystemA detected change in propA and needed to change some propB, but SystemX is listening to propB changes and affects propA .. and we have an infinite loop. Is this a common weakness of such systems or I have wrong implementation ideas? The last system in the subscription chain could be the NetworkSystem, which sends out a small package on every subscribed property change ... or it is a bad idea and I should pack more changes together?. I guess, rendering and physics will be separate threads where RenderSystem (client side only) is polling the entities for their properties which have changed since last frame and PhysicsSystem is modyfing properties on each iteration InputSystem (client side only) and NetworkSystem also are modifying properties and WorldClockSystem could modify some properties on timer events. But the major problem is when I think how to implement custom scripting in such systems. Let's say, users are allowed to upload their custom logic and animation script called Respect which has one property called goodDeeds with a rule "if a person with goodDeeds 100 passes by, I run some RespectAnimation". So I would install a global RespectSystem which subscribes to position changes of every character and checks for the Respect component and goodDeeds property and then somehow tells to Animation system to run Respect animation on this object. Is this the way it is supposed to work, isn't it dangerous that the behavior now is a global object and not a property of the entity which uses it? If I think again about the problem of neverending loops of observed modified properties, it means that one wrong xxxSystem script could stall the entire server (but from the other hand, the admin of the server should have enough sanity to see such problems before allowing the user to upload that script). Anyway, it would be great to find some book or article which better describes how to use component based systems where components are properties and behavior are singletons, but somehow all articles I have read, explain only the idea itself but not how to attach it to a real game engine with scripting and networking.


Connecting clients with UDP and WebSocket connections I'm in the process of making a physics intensive multiplayer game. Naturally I use a UDP to transfer packets regarding rigidbodies between client and an authoritative server. However non essential packets I'd prefer to use a more reliable connection like WebSockets. This would be for things like voice chat, text chat, scoreboard, etc. It also seems the be a nice approach to checking if the client is still connected and if not, stop sending it UDP packets. I'm actually unable to find use cases of this dual connection approach online and I was wondering how this is typically handled in similar games. Is it very far fetched or unconventional? Another question would be how far do I take relying on the WebSocket connection? Lets say for managing remaining bullets in a guns magazine, would it be better over UDP or WebSocket? I feel like WebSockets would be best in this case because if the bullet was successfully spawned and the server needs to remove a bullet from the client's gun's magazine, if that packet doesn't arrive at the client, then they shot a free bullet... The UDP equivalent for this scenario would be to always send the client's magazine state as packets and the client just updates it's magazine whenever the packets get to them. My concern here is overloading the network traffic data that might not have even changed...


Applying the input for the always moving player in the multiplayer game I've read several articles published on gambrielgambetta.com, gafferongames.com plus some pages about how Valve handles multiplayer networking in its games but I still can't get it how to implement the client side prediction for my game where the player's always moving and he controls the speed by pressing the spacebar. When the client input has arrived the server already had simulated the world using the old velocity values. So we get a stretch in time. Let's imagine that the player is moving between the 0.0 and 1.0 values. The current position is 0.2. The normal speed is 0.1. The "crawling" speed is 0.05. Let's assume the server and the client have framerates both fixed and the latency is two steps high. STEP 0 server 0.2 client 0.2 STEP 1 server 0.3 ( 0.1) client 0.3 ( 0.1) STEP 2 server 0.4 ( 0.1) client 0.4 ( 0.1) STEP 3 (Spacebar's pressed) server 0.5 ( 0.1) client 0.45 ( 0.05) STEP 4 (Spacebar's still pressed) server 0.6 ( 0.1) client 0.5 ( 0.05) STEP 5 (Spacebar's still pressed. Finally, the input has arrived) server 0.65 ( 0.05) client 0.55 ( 0.05) STEP 6 (Spacebar's still pressed) server 0.7 ( 0.05) client 0.6 ( 0.05) STEP 7 (Spacebar's released. Input was sent) server 0.7 ( 0.05) client 0.7 ( 0.1) STEP 8 server 0.75 ( 0.05) client 0.8 ( 0.1) STEP 9 (Input has arrived) server 0.85 ( 0.1) client 0.9 ( 0.1) It looks like nothing's wrong with this data while every multiplayer game's trying to hide the latency. But what if the periods of pressing the spacebar are different and the latency is different and the server and client have different framerates. I can't use the input duration when updating the player position because it allows the player to cheat (just lower the duration and you will start moving slower). And the server reconciliation works not very good since I'm getting the effects derived in the statistics above. When pressing the spacebar the player just jumps back and starts moving slower. So I need to compensate that somehow. The core of the problem is how to handle the player input when the user can only decrease the speed of the character while the character's moving with the predefined speed.


Using Unity's uNet to create a turn based RPG I've been checking some tutorials about uNet and it seems pretty powerful. The NetworkManager is a great tool when you want to make generic games, but what is troubling me about it is the need of spawning a "Player". I intend to create a turn based RPG, and for that, during the battle there's not a "physical player entity", there's two players which have a set of monsters and the players can select a monster to attack the opponents', but the player itself doesn't exist, in the end it sums up to a trade of commands between the clients. How can I achieve such an architecture with uNet? Should I discard the use of the default NetworkManager? Should I simply create a bodyless Player and go along with it?


Implementing Multiplayer entire world ticks or just changes? i'm working an a very simple multiplayer experience (for now node.js, later will probably remake all in c , but my question is more about theory). All guides and tutorial i saw about making something multiplayer Always speak about sending all the "world" information, once per tick, deciding optimal tickrate, making smooth movements on client side with interpolation or stuff like that. Honestly i thought of another way, and i really cant see why its never mentioned. My idea would be the following Client sends to server when input happens eg if you move with arrows, you send to the server a message only when your moving status changed. If you was moving right and then start moving upright, then you send a message about you changing your movement. Server recives the messages, sets variable on player object for its movement, and sends to all other clients information about the change. Also sends current time and current position in the server at the moment of movement change. Clients recive a movement status update, place the player object in recived coordinates moved by the new movement ping delay. That way position in all clients should Always be up to date with the server. Why should i send hundreds of positions to each client per each player every x milliseconds when i can just send the changes? I feel like its about polling vs interrupt... (yeah i know its not polling anyway, but the concept is sending the change vs keep sending everything)


When doing network programming, is it always a good idea to optimize packet size as much as possible? My question is relatively straightforward, but I haven't been able to find a concrete answer yet. I'm programming a real time networked multiplayer game, and I'm finding many examples of places where I could optimize packet size (i.e. minimize packet size) in small ways. As an example, one packet type stores player input (running, jumping, firing a weapon, etc.) along with an integer ID for that player. In practice, there will never be more than four players in a single game, meaning that ID could be represented with only two bits (four possible values) rather than the full 4 byte integer. My question is, should I send only those two bits across in a network message or just send the full integer? To clarify, I'm not referring to storing the ID in the main code itself. For that, I'm just using an int. I'm only curious about what I should be sending in a network packet. That's also just one example of a few I've run into. The reason I ask is that this feels like a "don't prematurely optimize" scenario. Ordinarily, I know to not worry about optimization (within reason) until I've run profilers, but I'm less familiar with networking than "normal" programming. Is it better to optimize packet size as much as possible, or would that be overkill? Thank you.


Can networking be platform independent in a libgdx game? LibGDX supports Desktop (Windows, Linux and Mac), Android and web applications. Can i code the network part of an online game without taking care of what kind a of application i'm running? i.e coding the network engine interdependently of the application type.


Optimal data size for a 3G client server game? I'm currently working on an iOS turn based client server game and I am concerned over later performance issues. How much data per message is too big? I am planning to use JSON to transfer data (and, if possible, gzip it for more compression) and try to send as little as possible to make it work, but is there a figure I should keep in mind so that I do not exceed and is there a best practice way of compressing this data? On a side note, will this prevent me or affect whether I will use secure connections like SSL?


Where should multiplayer games start? Client or server? I'm starting to make a small multiplayer game, and even though I have experience with games and networking, there's just one thing that keep me from making this. The question is When starting a multiplayer game, should one start making the server first, or the client first? This looks like a dead lock for me, because while starting on the client, seems to be the a good option (you'll make a game, which you are already very good at doing probably, and you'll have something to look for progress), you will fall on the trap that probably most of the code effort you put into making that game will have to be thrown away and remade on the server side. And starting on the server side is just the opposite You'll have nothing to look upon, so you can't know if you're making progress. And if that wasn't bad enough, you'll also have to throw lots of stuff away, since you have no game to check if that will have to indeed work like that. Is there a correct answer for this?