Pokemon Artificial Intelligence I'm working on a thesis about programming an AI combat system for Pokemon (To be implemented in Showdown!). However, I would like to include historical information about the existing implementations of Pokemon AI. This information would offer valuable context to my thesis. I have been scouring the internet for some sort of algorithm that explains how the AI Trainers make their choices, but have found nothing promising. I realize the fan games have implemented some more interesting AI systems for their trainers, these would be interesting to see as well. What I am looking for is examples of the methods used for Pokemon Battle AI decision making used in Pokemon videogames, whether from main series by Nintendo or the many fan games out there. I realize most of these pose no challenge to an experienced player, but I don't mind, I only wish to compile historical information on previous Pokemon AI attempts.


Can a rules engine produce manageable and complex AI? I am currently in the middle of creating an AI village simulation in Java. Having implemented a simple rules engine for dialog, I am wondering if this DSL can be extended for AI. I have previously implemented both GOAP and behavior trees, but considered GOAP to be confusing for the average user. Behavior trees may still be an option. In this case, I expect the AI to be able to control interactions between villagers (covered within the rules system already) and to manage the goals daily actions of both individual villagers and the village as a whole. Actions could range from gathering resources, to deciding what to build on a broader scale. However, I have concerns about whether a rules system will be able to manage hierarchy or many complex situations. There may also be some interaction with non technical users, so understandability is important. The rules engine as it stands currently takes in a number of facts on an event, matches it to the best rule and executes a number of actions. The outcome of the AI needs to be sufficiently complex as to be believable for example, there may be many competing desires to relax, work on a pressing task etc. This needs to be able to be managed and prioritized as tasks come up. A village wide AI can assign tasks to individual villagers based on their abilities and the urgency of the task. There are randomized events that can change the priority of certain tasks. My main concern is whether the rules engine will be performant, be able to schedule tasks well and be responsive to dynamic conditions. Is a rules based engine desirable for this kind of AI?


Does it make sense to use both TCP and UDP at once? After reading Is UDP still better than TCP for data heavy realtime games?, I'm wondering if it makes sense to use both TCP and UDP at the same time, but for different things TCP for sending information that is sent infrequently, but should be guaranteed to arrive reliably. Such as score updates, a player's name, or even the on off state of a light in the game world. UDP for transmitting information that is updated constantly and can be lost occasionally, since newer information is always on the way. Such as position, rotation, etc. Is this a reasonable idea? What are the possible drawbacks? Are there better ways to handle this?


Running both the server and the client within the same process Question I have just started working with Lidgren and networking for the first time, and I've come to the realisation that it is possible to run both the server and the client within the same process. Is this practice discouraged for any reason? Context The reason I'm asking is because I theorized that this concept might allow me to treat both singleplayer and multiplayer modes as one and the same, which would be very helpful. Following my line of thought, this is the distribution I had in mind Singleplayer 1 server 1 client in the same process. How fast are the communications? Multiplayer Same as singleplayer for the host 1 aditional client for each other player. The execution flow I'm picturing is for clients to recieve user input and send a notification to the server. Then the server validates it, and broadcasts an action to be executed by all the clients. It shouldn't matter if there is only one client (i.e. singleplayer) or multiple clients (i.e. multiplayer).


Kryonet usage for game networking Im making a game where real time data is exchanged between server and clients, and I was using java UDP sockets straight up, but I reached a point where I actually need to know if a few specific packets do arrive or not, like RemoveObject, ChangeLevel etc. UDP alone isnt enough, I needed some reliability. So i tried to implement a thin layer on top of UDP by following this great article http gafferongames.com networking for game programmers Still, although it's being great to learn low level networking, its also very hard and I've grown tired, so i looked up for a good alternative and found Kryonet. Kryonet is said to handle both UDP and TCP requests at the same time, by using two ports (although apparently a single port for both protocols can be used...). My initial idea (which seems more logical for me) would be to send via UDP the packets with info about object state updates and other real time dependent information, whilst using TCP for object creation, removal, state changes or even eventually chat messages. Still, every example i saw until now only uses TCP even for real time games, which i find odd when every article i read about game networking strongly discourages such. I also do not understand how UDP and TCP work at the same time since the article states The problem is that since TCP and UDP are both built on top of IP, the underlying packets sent by each protocol will affect each other. Exactly how they affect each other is quite complicated and relates to how TCP performs reliability and flow control, but fundamentally you should remember that TCP tends to induce packet loss in UDP packets. Please explain how is Kryonet supposed to be used on game networking and why it should be used in such way regarding common knowledge about both protocols.


I wanted to create a simple mobile online game for me and my mates. How should I handle the networking? I've made a few simple games and one multiplayer game where you connect through LAN but for this one I wanted to learn something new. I have the game concept working on my computer, it's just waiting for the networking. I was looking to create networking similar to mobile online quiz games, where you use your Store account as the game account you are not restricted to LAN or same WiFi network, but rather everything goes through an external server you have a Friends list,Recently Played list where you can see who's online right now you can invite a random player to a match or search for particular player to play with them add them to your Friends list Something like that. I don't know if you can host servers for a match on mobile devices, or how feasible it would be, given mobile internet isn't free, but it would make for a nice addition if the external server was only for handling information about who's online. I'm working in Unity btw. so any recommendation for package from Asset Store is welcomed Thanks in advance! )


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.


What to replicate in a PvP online action game? We're developing a 2D PvP online action game. You can think of it like Super Smash Bros. We have a function call tree for characters like below CharacterInput.Update() CharacterController.StartJump() CharacterMovement.TranslateState( "Jump" ) CharacterJumpState.OnEnter() CustomRigidbody2D.Move( delta ) I think the pseudo code above is kinda straight forward. It's a typical Controller Movement structure where the Movement part is made using several character states. Also, the Movement part is responsible for animations, physics, visual effects and sound effects. So, to make this networked, we need to replicate some values over the network. To make it clear, we're using Photon Bolt for Unity, which provide a ExecuteCommand way to deal with server authority and client prediction. You can check it out here. So in terms of replication, we realized that according to the structure, we should decide which part to replicate. According to the call tree above, we can split our character logic into these layers Input Layer LeftStick, RightStick, A, B, X, Y, ... Controller Layer MovementDirection, ShootDirection, IsJump, IsShoot, IsMelee, ... Movement Layer CurrentState and all of its member variables Rigidbody, Animation Layer Velocity, GravityScale, CurrentAnimationState Theoretically, replicate any of these layers can make it work because the process of higher layer to lower layer is deterministic. Once the higher layer is replicated, lower layers should be the same across the network. Sadly, this is just theory. In reality, you must deal with lag, and unreliable packet delivery. For example, if you only replicate the inputs, an unstable network may make it out of sync because state A may transit itself to state B if animation ends, but actually it should be transitted to state C if player presses some button. However, if you only replicate rigidbody and animation, all the visual effect or audio effect triggered by CharacterState can't work, because CharacterMovement doesn't even know which state it is in... So, my question is, how do other games replicate their character? Especially in a PvP game?


Movement networking for a Worms like game I want to implement a strategy artillery game, similar to Worms Arcanists. As game development (and game networking especially) is new to me, I was wondering whether this would be a good performant way to do the movement networking Server has all client's positions. Moving client to server Message start moving, moving direction Server now starts a simulation of the moving client moving. Server to all clients, except originating one, every 100ms(?) Message set client position client id, new position new position calculated by the server's simulation Clients lerp the moving client's position. Moving client to server Message stop moving server's simulation ends Server to all clients, including originating one Message set client position client id, final position all clients have the same position for the moving client in the end


How to handle MANY enemies in networked P2P game? Let's suppose a game of 4 players, one is the host. They will fight many enemies, along the lines of 20 40 at the time. Among other things like sending their own state to the other players (position, rotation, shot this frame, crouched, etc). How do I handle the enemies? Do the host "decides" the enemies state? (again position, rotation, isattacking, etc). And then sends several messages to the other players so they sync their own game? or do I "divide" the enemies, lets say 40, and 4 players, 10 enemies "controlled" by each player game? and then, each player sends those messages to the other players so all enemies are in sync? Also, should I group the messages and send one big message instead of 40 little ones? How do I know how big can the message be (how many enemies info in each message)? Basically I'm asking whats the best way to handle a 4 player p2p game with many enemies on screen. Any good tip is appreciated.


How much to bake user input in a client server? Assume a client server game where there server manages all state and the clients are simply rendering input. How much should I bake user input from the client before sending it off to the server? Does it make sense to send "jump" or "space keydown"? I'm inclined to bake the input as much as possible. Am I setting myself up for pain later?


How to avoid being throttled? I'm writing a networked iOS game. When sending packets with GKMatchSendDataReliable (which I assumed was UDP with their own packet reception code written) at 60 packets per second (so 16 ms between adjacent packets), average ping times rapidly get worse I opened 7 GameCenter matches below (one after the other) and simply sent a "flood" of 100 packets (at a rate of 60 packets per second). I measured the average roundtrip time, and these are the results 21 16 39 I saw an average roundtrip time of 52.342787 ms, he saw 54.496590 ms 21 16 34 I saw an average roundtrip time of 62.631942 ms, he saw 61.991655 ms 21 16 45 I saw an average roundtrip time of 88.394380 ms, he saw 83.619123 ms 21 16 51 I saw an average roundtrip time of 179.053118 ms, he saw 156.869141 ms 21 16 57 I saw an average roundtrip time of 75.025076 ms, he saw 75.419723 ms 21 17 23 I saw an average roundtrip time of 8832.082488 ms, he saw 7616.877558 ms 21 19 33 I saw an average roundtrip time of 25088.962344 ms, he saw 16833.064914 ms After the last 2 tests the results are around 1000 ms. It would seem that I'm being throttled, most likely by my ISP. Because this is an iOS game, people will use regular residential connections. When I changed the packet send rate to being 10 times slower (so 1 packet every 160 ms), the tests take much longer, but roundtrip times remain consistently low. 21 31 27 I saw an average roundtrip time of 55.289109 ms, he saw 69.032727 ms So it looks like to keep low latency on the connection (and not be "punished" by ISPs) I have to reduce the rate of packets that I send. Keep in mind these are very small packets, like 40 bytes maximum, yet I'm still being throttled. I'm looking for guidelines on how many UDP packets I can send per second to avoid being throttled! Are there any general guidelines anywhere?


Why do games have different ports for different maps? A little old example for that would be Metin2, this is the only game I know which have that, but there may be more. In Metin2 there are maps which are accessable through other ports. I'm not a network specialist, but I think then it is needed to connect to an other port on an map change. So would it not be possible todo all that on one port? Are there any benefits from that? Could it be that there is a limit on port connections on a server, that this would be something for loadbalancing?


How does delta compression reduce the amount of data sent over the network? Many games use the technique of delta compression in order to lower the data load sent. I fail to understand how this technique actually lowers the data load? For example, let's say I want to send a position. Without delta compression I send a vector3 with the exact position of the entity, for instance (30, 2, 19). With delta compression I send a vector3 with smaller numbers (0.2, 0.1, 0.04). I don't understand how it lowers the data load if both of the messages are vector3 32 bit for each float 32 3 96 bits! I know you can convert each float to a byte and then convert it back from a byte to float but it causes precision errors which are visible.


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.


TCP vs. Reliable UDP? Sending Reliable Packets in Fast paced Multiplayer Games? I'm currently working on a networking framework for Unity3D in order to simplify making multiplayer games. I'm using UDP for any kind of synchronisation and unimportant data. My question is how do I send reliable packets such as RPCs or object instantiation? Should I use TCP for that or should I go about writing my own reliable protocol on top of UDP? Thanks in advance!


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?


Which toolkit to use for 3D MMO game development? Lately i've been thinking about which path to follow for developing an 3D Online game. I have googled a lot but i couldnt find a good article that covers both game development and online server amp client development in same context. This question has been in mind for about 2 weeks now. So.. yesterday i started developing a game from scratch by using Irrlicht.Net Wrapper to use Socket library of .NET which im already familiar. But i found out .Net wrapper of Irrlicht is not totally finished yet and still have lacks from the original. So i lost all my motives . So i thought why not to ask the experts before i run into another dead end... What Game Engine and Networking Library is best way to go for 3D MMO Development? Here is some of my early conclusions Please let me know the ones im wrong. C Best Performance for 3D Graphics. Most Game Engines has native C Libraries. Lacks a Solid Socket Library .NETC Lacks Intellisense Support. C Intellisense Support NET Socket Library Lacks 3D Graphics Performance Lacks a native solid 3D Game Engine


Streaming player voice (client server) without (minimal) noticeable voice breaking I recently started to jump into voice streaming for my RPG game, for players to communicate by a central server point. I use TCP packets to communication from client server and from server client(s). What I currently do is streaming the microphone from the client (push to talk), send the voice data in 4096 bytes chunks, and send them to the client. However, since TCP packets take some time to send and process, as well as standard latency issues, the server forwards the packets to other clients with a certain delay (sometimes up to half a second). How should I compensate for this delay? (What technique do you recommend?)


How do I avoid losing prediction responsiveness due to client interpolation? In my online game, I am using client prediction and client interpolation to give the illusion of responsiveness over a networked connection. The client prediction applies inputs that haven't yet been acknowledged by the server to incoming server states. When the input is acknowledged, the client's entity will already be in the final position. The client interpolation works by buffering world snapshots and rendering the entities 100 ms in the past. While new snapshots arrive within the next 100 ms, there will always be valid data to interpolate between. My problem is that the responsiveness gained from client prediction is lost due to client interpolation. The client's local inputs are applied to incoming server states. However, those incoming states aren't actually rendered on the client until 100 ms later, due to the client interpolation. The result is that there is always a 100 ms lag between pressing a key and rendering the change to the screen. How can I get the best of both worlds, rendering entities in the past, but rendering the client's inputs instantly?


Turn based card game multiplayer http polling or TCP I am working on card games for mobile devices. For multiplayer I will be communicating through a central server. For the purpose I sorted out three options HTTP polling TCP Websocket (client libraries are not good, so will not use it) HTTP polling is simple, but I fear it will introduce much more delay and too many HTTP calls. TCP introduces other complications. So my question is Is HTTP polling appropriate for a card game? Will the HTTP overhead be too much? How much interval should I keep for polling? Can you give a sample game based on HTTP polling?


Character appearance synchronization in open world multiplayer game I am working on a multiplayer open world game where you can equip handhelds and armor pieces. In my architecture, there are clients and an authoritative server. Every equipable item is crafted by a user. They can be different in shape, so it's important that I synchronize shape information. This is expensive data to send (basically an outline plus some more info). Together with this, I also want to synchronize any equipment event that occurs, so when a user meets another user, they can see each other's gear. The easiest solution I've found is to force send gear on equipment, but it will use bandwidth even when two players are far away. This feels like a problem that has been solved a thousand times, so I don't want to reinvent the wheel. Do you know of any best practice known strategy that suits my situation?


Can a local UDK server have two clients connected locally? To do some basic testing on players interacting with other players I would need to have at least two players in my world. My solution is to run the server from my computer, then run two clients. When I run the second client and connect to the server, I find a weapon dropped by client 1 in the appropriate position(but no body). What happened? server.bat C UDK UDK 2015 01 Binaries Win32 UDK.exe server ieTestMap?GoalScore 0?TimeLimit 0?Game ie.ieGame log client.bat C UDK UDK 2015 01 Binaries Win32 UDK.exe 127.0.0.1 log class ieGame extends UTDeathmatch simulated function PostBeginPlay() defaultproperties bScoreDeaths false PlayerControllerClass class'ie.iePlayerController' DefaultPawnClass class'ie.iePawn' bDelayedStart false GameReplicationInfoClass class'ie.ieGameReplicationInfo' class iePlayerController extends UTPlayerController reliable client function ClientSetHUD(class lt HUD gt newHUDType) if(myHUD ! none) myHUD.Destroy() myHUD spawn(class'ieHUD', self) defaultproperties I have kept the other classes of my game 'bare bone.'


How to give each player in card game the same shuffled deck? I'm writing a card game in Swift. The idea is to make it work on the Apple Game Center framework. I've noticed an issue which I am not sure how to address. I need the current game data to be the same for all players. There are 6 players in the game. There is a deck of 30 cards, they are shuffled. Each player must have the same deck of cards (post shuffle). 6 cards are presented to the "table" one at a time (animation). There are also other activities that a player does that are outside the bounds of this question. My question is this How do I give each player the same shuffled deck of cards? There are a couple of options I can think of, but perhaps none of these are the best way hence my question The start player is the host. The host creates the shuffled deck, and this deck is sent to other players (ie JSON) in short all activities are facilitated through him. The problem with this is that the start player could lose internet, abandon the game or all sorts? So I don't think this is a viable solution There is a middleman, the server. There is a "lobby" (waiting area) There is multiple games. The game has players. An AI bot could be used to fill in abandoned players But wait, does this then mean the server shuffles the cards and sends the same data to all players and makes the players "thin clients"? Can Apple's Game Center handle this for me? I'm not sure about the best solution for this?


How do I determine how far to move an object in the client when using client prediction? I have a game server which, for testing purposes, is updating once per second, or 1hz so I can correctly implement client side prediction. Everything is running locally at the moment so there is no lag issues to deal with, but this setup replicates potential packet loss, or if the server somehow is behind on processing. I am using Unity for the client. I have a tunnel where the position is updated on the server and then broadcast to each client each tick (once per second). The client simply then lerps between its current position, and the new position received from the server, and this seems to work nicely. However, as I have set the tick to 1hz, there are unexpected results where the position seems to pulse, rather than smoothly transition. An example can be seen below. It can perhaps be seen more clearly without lerping I have tried constantly increasing the tunnel's position in the client, but if it's moved too far in the client, once the server's position is received, it is snapped back to that position which creates some weird rubber banding like effects even though there is no lag. How can I determine how much to move the tunnel in the client to create some seamless movement, even when the tick rate is so low? Baring in mind this movement is variable, so it can move faster slower at times so the movement in the client cannot be a fixed number. Yes, I can just increase the tick rate which gives smooth movement, however, there is no lag to account for as it's all local so I am just preparing for when I move the server to actual hosting. Instead of lerping between the current position and the received position, should I be trying to lerp between the current position and the next received position? Lerp Vector3 currentPosition transform.position Vector3 newPosition new Vector3(currentPosition.x, currentPosition.y, tunnelPositionZ) transform.position Vector3.Lerp(currentPosition, newPosition, Time.deltaTime) DMGregory's solution attempt If I decrease the 1.0f for the blend variable, the tunnel will move very slowly and then jolt forward when a snapshot is received. Decreasing the 1.0f to around 0.1f seems to align the speeds but there is still a noticeable jolt. I'm using the same velocity for the currentPosition and newPosition because the velocity never changes. float dT Time.time latestSnapshot.arrivalTime float blend Mathf.Clamp01(dT 1.0f) Vector3 currentPosition transform.position Vector3 currentVelocity rigidbody.velocity Vector3 newPosition new Vector3(currentPosition.x, currentPosition.y, latestSnapshot.tunnelPositionZ) Vector3 newVelocity new Vector3(currentVelocity.x, currentVelocity.y, latestSnapshot.tunnelVelocityZ) Vector3 velocity Vector3.Lerp(currentVelocity, newVelocity, blend) Vector3 position Vector3.Lerp( currentPosition velocity dT, newPosition velocity dT, blend) transform.position position


RTS game How to handle disconnects in a fully connected peer to peer architecture? I'm currently working on a game in which I am considering implementing a networking architecture as described in this article http www.gamasutra.com view feature 131503 1500 archers on a 288 network .php In order for the implementation as described in the article to work, all peers need to be interconnected without any exceptions. Like so This works fine when everything is well. But I am wondering how to agree on disconnects in such a network. (Sadly something the article does not go into). It is relatively easy if one client goes down. Just give every client a timeout, and if a client does not respond for a certain time, it is removed from that client. However, how should the system solve a case in which one client does not respond to another, but still responds to all others. In such a system the following could happen, resulting in a invalid state Of course this can be solved by giving one of the clients some kind of "master" role. It being the only one that can decide whether or not to disconnect other clients. But I'm wondering if it can be achieved in a pure p2p network. Note I realize this case is not one that can likely occur "naturally". But I want to prevent players from being able to ruin a networking game for others by playing a trick like this by using the firewall for example.


How does a server receive every player input with a server authoritative structure? I've been having a lot of trouble understanding networking in fast paced games. A server has a fixed tickrate, and the server receives input from clients at a fixed rate as well. Let's assume that a client is running at 300fps but is sending 64 updates to the server a second. Clearly, the client did not send data about every frame, which means that certain inputs were not sent to the server. However, in every networked first person shooter, the server still seems to pick up every input. In this image, a client presses W at a certain frame, but that frame's data is not sent to the server. A possible solution would be to send the server updates equal to framerate. But if a client is playing at a high framerate, they could be sending too much data for the server to handle. So how does a server receive every input from clients?


Networking in a strategy, city management game I'm developing a city management mobile game with its' share of multiplayer elements (leaderboards, achievements, social interactions). It's built using Unity and GameSparks as a backend. I'm a little bit confused on how I should be implementing the networking. At the end of every in game month, the game should go through every business building, calculate the revenue (each building generates different amounts of money depending on the number of workers), then add this value to the player's funds. These funds can then be used to continue building more businesses and houses, which increase the population. I have to save the states for the city (buildings, population, etc) and player (funds, premium currency, etc) in the cloud. I'm afraid people will exploit the game (due to the leaderboards) if I entrust data with the client, and I feel it would be best to keep the system deterministic, but I'm not completely sure I'm doing the right thing. How would you solve the problem?


Does it make sense to use both TCP and UDP at once? After reading Is UDP still better than TCP for data heavy realtime games?, I'm wondering if it makes sense to use both TCP and UDP at the same time, but for different things TCP for sending information that is sent infrequently, but should be guaranteed to arrive reliably. Such as score updates, a player's name, or even the on off state of a light in the game world. UDP for transmitting information that is updated constantly and can be lost occasionally, since newer information is always on the way. Such as position, rotation, etc. Is this a reasonable idea? What are the possible drawbacks? Are there better ways to handle this?


understanding game networking I have been working on a real time game, and am closing in on the point where I send and receive data. I have previously accomplished this before with a couple other test games, but I have never really learned the correct way to pass data from server to clients efficiently. My question What is the best practice for a real time game to pass data? I have my doubts that I should be sending an update every frame (currently running at 30 fps), but in all honestly I dont know what is best. Most of the games ive worked on have passed the data instantly when they happen and continue to update every frame. Any suggestions or advice? Ill post more info if needed as well. Thank you


MMO Client Server Spoofing Vulnerabilities Ive created a working authoritative client server system using LiteNetLib for my game however im wondering if packet sniffing modification is a real worry i should be developing for. I read some information that other Client sniffing the packets of another client is pretty much impossible since the packets are routed through their ISP. Therefore should i only worry about the client causing problems for the server, instead of also worrying about clients causing problems for other clients? Currently im encrypting every packet sent by the client including movement commands such as 'move left'. My idea is that this will make packet sniffing fail, packet modification fail, and packet spoofing fail. If i remove my encryption doesn't that mean someone can spoof a packet by changing the packet source in the header? (thus sending game commands for another client moving another player!). Usually when its encrypted i know that only the client with the secret key could have sent it, thus validating the packet source. I see everyone saying that people shouldn't encrypt general traffic like this, but whats the truth here! Whats the best way?


Is state change command less reliable than sending the entire state? I'm asking for a game that I develop right now. The game is using TCP communication, there's server and multiple clients. While players in a room are playing the game, I send state update commands in a custom binary protocol every 33 ms. (30 FPS) Problem is those states are huge there are players moving, objects spawning and also destructible blocks. If I were to send all this data a single state update to every player will be huge, resulting in huge bandwidth. So I'm thinking different approach Initially send the huge state with all moving and stationary objects, when the room starts Do the state update commands every 33 ms, but include just the moving objects, and not include the state and location of the stationary objects. For stationary objects, issue separate commands to tell they are destroyed or spawned and expect clients to update their copy of the state. My concern is that it may somehow happen that due to not including the stationary objects in every state update, clients may somehow miss the separate commands that update on those and not reflect that change in their copy of the state. Here is a visual representation of what I imagine Less bandwidth (is it less reliable?) game started gt obj1 id,location , obj2 id,location , obj3 id,location state update 1 gt obj1 id,location , obj2 id,location assumes obj3 is there state update 2 gt obj1 id,location , obj2 id,location assumes obj3 is there state update 3 gt obj1 id,location , obj2 id,location assumes obj3 is there object removed gt obj3 removing the object locally state update 4 gt obj1 id,location , obj2 id,location obj3 not present at this point More bandwidth include all objects in every state update and assume if something is not present, it has been removed (is it more reliable?) game started gt obj1 id,location , obj2 id,location , obj3 id,location state update 1 gt obj1 id,location , obj2 id,location , obj3 id,location state update 2 gt obj1 id,location , obj2 id,location , obj3 id,location state update 3 gt obj1 id,location , obj2 id,location obj3 is not here, so removing it locally state update 4 gt obj1 id,location , obj2 id,location obj3 not present at this point


Is it feasible to use a DHT to span an MMO over many servers for improving reliability? At the moment I have an idea for how to handle distributing MMO servers. At the core is a bunch of worker nodes that all share the same set of distributed hash tables. Each DHT stores a specific game component. Each frame a coordinator server (which there can also be many of) pushes work out to all of the connected worker nodes and wait for them to complete all of the assigned tasks. The system is also divided up into four parts the client, which obviously the player uses. The proxy server that sits behind load balancers and users connect to. All they do is process incoming user packets, verify them and passes the request to the work cluster. The work cluster receives packets from proxies and append them to a process queue and wait for the frame event from the controller node to process them. I just want to know if adding a DHT to the worker nodes like this would be feasible? This should allow redundency and high availability out of the box as DHT's are quite good at that.


How do multiplayer servers handle receiving, handling, and sending packets? I want to make a fighter jet simulator game. The server (authoritative) and client communicate over udp. The server sends out updates about the gamestate at a fixed rate. Think of plane positions, speeds, rotation, basically anything to do with physics. On demand, the server sends out packets for spawning bullets and applying damage. So this is not at a fixed tickrate. This is done to sidestep the problem of superbullets and syncing fire rates with tick rates entirely. This class of packets also include chat messages. How do I go about implementing this? I am using c c , programming raw sockets. I am running into the issue where the recvfrom function is blocking. I can set it to non blocking using fnctl, yes, but that spams error messages because sometimes there are no packets waiting to be handled (I could handle it but egh, inelegant). Ideally I would like to prevent multithreading, but given that there seems to be no native event driven or interrupt driven way of receiving packets it seems I need to do that. How do other game servers, like quake arena, set up their threads? My idea Main thread calculates game state, sends out packets at a fixed rate 1 child thread for listening for new packets (recvfrom loop) If the incoming packet is a quot i am shooting quot packet, it performs checks, and broadcasts to every client that a bullet has spawned. It adds the bullet to the world, and the main thread will calculate the continued trajectory in the next or current tickcycle, using the time difference and initial spawn data. if the incoming packet is a chat message, perform checks and just broadcast it across clients. if the incoming packet is any other kind of packet, put it in a queue for the main thread to handle (the queue is mutexxed) Is this how I should make the child and main communicate?


Should I use select() for networking in my gameloop? I'm writing a simple networked game in C C . To keep things simple I'm using TCP. In my server's game loop I'm using a POSIX select() with a zero second timeout for two things Discover incoming data from connected clients Discover new incoming connections Is this a reasonable way to do it? Instead of using select() I could just loop through all connected socket descriptors and call recv() (or something like it) for each, to see if there is any new data. Would that be better? The same question goes for the client. Note that on the client there's only one socket descriptor. Should I here use select() and a zero second timeout to find out if there's any new data incoming, or should I just call recv() on each game tick? Or perhaps it would be even better if I pushed networking to a separate thread?


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?


Latency issue on multiplayer game networking I am currently writing a 2D top down shooting multiplayer game using Java. I have a game loop at the client side that does the following in order in each game tick (The client is running in a tick rate of 60 t s) client gameloop 1. Send an input sample (an object storing info about what keys are pressed) to the server through a DatagramSocket 2. Receive info on change in game state from the server 3. Update the client side game state through the received info For the server side, I have a game loop that does the following in order in each game tick (The server is running in a tick rate of 60 t s) server gameloop 1. Read an input sample through a single DatagramSocket 2. Using the input sample to apply physics to the game world and update the game state When I try to connect the first client to the server, the game flows fluently with unnoticeable delay. However, when I try to connect the second client, both first and second client start to lag behind the server greatly (delay ranges from 5s to 10s). I am currently stuck on what causes the delay. Am I handling the sending and receiving of info between client and server in a wrong way that causes game state in the server side not being able to synchronize with those of clients'?


Securing a replay based leaderboard system (as much as possible) A few years ago, I implemented a basic online leaderboard system in one of my games that sent encrypted score data over the wire. The encryption keys were stored in the game client's binary. Of course, the leaderboards got hacked the same day they were released. I have now released a new game on Steam, and I've worked hard to implement fully deterministic game logic and a replay system. The replay system works by simply replaying the user's input that was recorded in a previous playthrough. The fully deterministic game logic ensures that the replay will work on any machine, independently of the game's FPS. Now, it is time for me to implement online leaderboards. My idea is to create a server version of the game executable which receives replay files over the network, replays them on some remote machine, and adds the score to a database if the replay data is valid. While this prevents cheaters from simply sending a fake score to the server, it opens up many other cheating avenues, including Tool assisted creation of replays, either by slowing down the game speed or by manually crafting a replay file after reverse engineering its format (the game is open source). Taking someone else's replay and sending it over the network, changing data regarding who the replay belongs to. I could somehow encrypt and compress the replay data before sending it over (or saving it on the user's local machine), but since the game is open source, it would be easy to reverse engineer the encrypted replay format. What is a good way of securing a replay based online leaderboard system? One possible idea I had is to have the server generate an encryption key token for a specific user which is only valid for a small amount of time, send it over to the client, and only accept replays that are encrypted with that key. This would prevent users from uploading older replays to the server, but in theory it should work am I missing something?


UDP server and large number of users? My initial research showed the most people prefer to use UDP protocol and build a control code on top of it for multiplayer games. It seems like a good design at first, but I am wondering if it is really the best in the long run. For example, what happens if your game goes from 64 players to 500, 1000, 20 000 Is the UDP port going to overflow and start dropping incoming packets? Is the overhead that you wrote for UDP reliability going to be less optimal when you start using more bandwith? (I.e. the server will spend significant cycles managing features that may already be present at the hardware and network level that are built into TCP) I am considering re writing a server that initially used UDP reliablity protocol and splitting it into two cluster servers to handle different regions as well as introducing a load balancer in the middle. The UDP design is starting to look a little more complicated and having a large number of NPCs and state synchronization that may have to take place is making me reconsider UDP.


Server to client update rate I am building a game that uses client server architecture and have the following question regarding server to client updates. Currently the server is doing 60 ticks per second and is sending updates to the connected clients after every step, this means information about every entity that is in the world. Since my game is rather slow and rts based, a lot of the entities do not change state after every step and do not need to be updated. So to reduced server load I added an update queue. Only entities that require an update are added to this queue and it is executed after each step. Looking at this approach I wonder if there are any significant disadvantages to it. One I could think of is that maybe as the time goes by and the game gets more complicated all the entities will need to be updated on every step anyway and that might be just a waste of time to implement.


Why do some networked games use interpolation and some use pathfinding for remote movement? This is a bit of an open question but I'd like to see someone contribute a good reasoning for both. For a quick example of both Interpolation Model Think the Valve model where the client is receiving position updates frequently and the remotes update their positions using interpolation on this data. Path finding In this model, think the user sends a destination and everyone pathfinds to it. What types of games are suited to each and when should one use each?


How should I update object movement on Client in a lockstep game? I have a game that I am implementing a lockstep system for multiplayer on an RTS game. Now the server sends update packets at a higher frequency than the clients with new data. What I'm stuck on understanding about lockstep systems is how does this tie in with the movement of the units. Should I only move the objects when a new update packet is received?


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?


Authoritative movement with client side prediction I don't fully understand how client side prediction works with authoritative movement. Let's say we have client at position(0,0) server at position(0,0) Now the client wants to move forward and calls a client side function move and then sends the server that the client wants to move forward. Now the client has moved to position(10,0), while the server is still at position(0,0). Now the server moves to position(10,0) and sends an update to all clients. But the client has now moved to position(20,0) and now receives the position state from the server that the client should be at position(10,0). What happens now? The client can't just apply the position from the server otherwise the client would jitter around. One simple solution that I could think of would be a distance check. if(Distance(position(10,0),position(20,0) gt SomeNumber) ForceUpdatePos() But this is probably not a good idea because SomeNumber depends on the MovementSpeed and latency. I probably also would have to include a timestamp of the package because maybe the client has not heard back from the server for several ticks and then receives a bunch of unordered position updates. What is a common technique to solve this problem?


UDK client, C server (is it possible?) For example I have C C server side with sockets or http web server and UDK client. I am interesting what about experience with networking in UDK could I connect UDK client to C C socket server via UDP TCP? Maybe some tutorials examples?


I'm making a networked game for mobile. Should I worry about cheating? I'm in the process of making a racing game for Android iOS. I'm thinking of implementing a server client model, should I worry about cheating and make all players communicate with a server of mine, or will I be good by letting one of the players host the game? I'm not sure how much memory editing or packet editing is possible in Android iOS, and that's the main reason why I'm asking this.


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 ?


Validating User Actions on the Server I am currently working on a networked first person shooter. I have created a server implementation that can synchronize player data. But while implementing a damage system, I realized that I almost simply sent a packet with PLAYER DAMAGE target id amount But that would likely be open for any player to save a list of IDs and inject that packet to damage every ID. Unfortunately the server is unable to know what the environment is like meaning it cannot check if there is something between the two players or likewise. How would I keep this from being possible?


frame lock networking I'm developing an RTS game and I want to add multiplayer support to my game. I picked the easiest technique to implement for start frame locking technique. I used server client networking architecture (I think it's my first mistake I think using peer to peer is a better one for this) On game update every clients send their commands and maybe receive some command then render the frame and wait for all clients to send their update complete message then all of them can go for the next frame. I send commands and all logic is calculated on the clients based on commands but the clients can go out of sync easily. Every AI controlled units make different decisions on each clients What I have to do to sync my game? Do you suggest me a better network architecture or technique?


How can I simulate a bad internet connection for testing purposes? I am developing an online multiplayer game. It works well when I test it on the local area network, but before I release it I would like to test how the user experience works out for someone who has not such a good connection to the server. How can I simulate a bad internet connection with high latency, low bandwidth, jitter and occasional packet loss when in a local environment?


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 to sync client and server at the first frame I'm making a game where an authoritative server sends information to all clients about states and positions for objects in a 3d world. The player can control his character by clicking on the screen to set a destination for the character, much like in the Diablo series. I've read most information I can find online about interpolation, reconciliation, and general networking architecture (Valve's for instance). I think I understand everything but one thing seems to be missing in every article I read. Let say we have an interpolation delay of 100ms, server tickrate 50ms, latency 200ms How do I know when 100ms has past on the client? If the server sends the first update on t 0, can I assume it arrives at t 200, therefore assuming that all packets takes the same amount of time to reach the client? What if the first packet arrives a little quick, for instance at t 150. I would then be starting the client with t 150 and at t 250 it will think it has past 100ms since its connect to the server when it in fact only 50ms has past. Hopefully the above paragraph is understandable. The summarized question would be How do I know at what tick to start simulating the client? EDIT This is how I ended up doing it The client keeps a clock (approximately) in sync with the server. The client then simulates the world at simulationTime syncedTime avg(RTT) 2 interpolationTime The round trip time can fluctuate so therefore I average it out over time. By only keeping the most recent values when calculating the average I hope to adapt to more permanent changes in latency. It's still to early to draw any conclusion. I'm currently simulating bad network connections, but it's looking good so far. Anyone see any possible problems?


Should response be tied to request in a multiplayer game? I wonder if server responses on client operation requests should be tied by some operation id? Tied would be when 1.Client app sends request to server to e.g. buy item X, and sets operation id as ID. 2.Server responds with operation id and true or false. This would mean that operation with that id was successful or not. Untied example 1.Client app sends request to server to e.g. buy item X 2.Server responds with just an updated data of item X, where new item owner would be mentioned. This way client can check if owner name is equal to it's own name and if true, assume that item was bought successfully. Same response data could be sent to other clients, to let them know that item X was bought by someone. Which approach is better? IMHO untied is better and simpler in implementation, but it feels like there can be so many edge cases which I don't see right now.


Networking middleware I'm looking for a networking middleware that may be suitable for a medium sized MMO. I don't care in which language it's written, just that it's high level, stable and has many of the features that can ease my development. I am making a 2D real time action game. Come to think of it... I'd be happy with "just" a high level networking framework that has a few handy features to ease the development of a general networked game.


Networking User Interface Buttons (build queue items) I am creating a RTS with Unity C , and have noticed a problem synchronising build queues. Is there an ideal solution to handle button prediction? I think I may have overengineered the solution... Presently when the client clicks a button, it sends a request to the server. The server validates the request (cost if applicable) and then returns the order to create the build queue item. Consequently, when the client clicks a button there's a noticeable lag. Is server validation for button presses, like build queues, in a client server model overkill? What would be the ideal solution?


Only send moves for P2P 2 player LAN game? I am making a 2D network game. The concept is simple, a player have to shoot the other player to win. I'd like to improve this game ( add a map, items, monsters, w e ), but later. This is my first network programming experience. I have little theorical knowledges about packets, sockets, client server side, what is dangerous to do client sided, but I've never really used them. Goals set This is a 2 players LAN game, no more no less. No server. Player 1 starts the game waiting for player 2... ... which leads the game open for reverse engineering or packet editing, but w e, for this kind of game I prefer simplicity over security. Pretty basic. For a first network game that will never be shared, I take off problems and will see later. This is where I am each player is a square that can move in four directions. The approach TCP Packets. Each movement ( each frame a key is pressed to be accurate ), a packet is sent to the other player with his position. Packets are received each frames before drawing and updating game elements, in the same thread, with a non blocking receive() function. And that's it. My questions Is sending a packet for each moves overkill? Will I have problems with this later? What kind of problem can I meet? mono thread non blocking function will be a problem later, assuming the goals I've set?


Synchronisation on a non authoritative networked peer to peer scene I currently have a piece of coursework that requires 3 or more 3d simulations connected via p2p to maintain a simulation that is visually consistent amoung all peers. A big issue is that I'm not allowed to use any form of authoritative server peer logic and I'm struggling with potential designs. The coursework has the following relavant constraints each peer must be connected at the start and will have the same initial empty simulation The network will be LAN only Hardware is consistent in all computers in the network I'm thinking about implementing it along the lines of Each peer will regularly create a snapshot of all objects that have moved since the last snapshot Each peer will maitain a local copy of the snapshot in addition to broadcasting it to all other peers Each peer will combine the other snapshots possibly via averaging and and adding it to the current local state. I'm thinking I could also possibly use timestamps of each snapshot to weight the combination. each peer runs their local simulation briefly then repeat the process Can anybody see any potential problems with this or recommend anything?


game multiplayer service development I'm currently working on a multiplayer game. I've looked at a number of multiplayer services(player.io, playphone, gamespy, and others) but nothing really hits the mark. They are missing features, lack platform support or cost too much. What I'm looking for is a simple poor man's version of steam or xbox live. Not the game marketplace side of those two but the multiplayer services. User accounts, profiles, presence info, friends, game stats, invites, on offline messaging. Basically I'm looking for a unified multiplayer platform for all my games across devices. Since I can't find what I'm planning to roll my own piece by piece. I plan to save on server resources by making most of the communication p2p. Things like game data and voice chat can be handled between peers and the server keeps track of user presence and only send updates when needed or requested. I know this runs the risk of cheating but that isn't a concern right now. I plan to run this on a Amazon ec2 micro server for development then move to a small to large instance when finished. I figure user accounts would be the simplest to start with. Users can create accounts online or using in game dialog, login out, change profile info. The user can access this info online or in game. I will need user authentication and secure communication between server and client. I figure all info will be stored in a database but I dont know how it can be stored securely and accessed from webserver and game services. I would appreciate and links to tutorials, info or advice anyone could provide to get me started. Any programming language is fine but I plan to use c on the server and c c on devices. I would like to get started right away but I'm in no hurry to get it finished just yet. If you know of a service that already fits my requirements please let me know.


Text based hold 'em game in C using TCP So I'm trying to create a simple text input Texas Hold 'Em game that can be played in a Terminal between multiple computer. (Disturbing lack of hold 'em games that don't require Facebook integration or a million ads or micro transactions c ) With my current knowledge I can create the TCP Server and Connect some clients, but I'm not sure how to proceed from here. How can I communicate between the clients and server turn by turn using text input effectively? My vague idea of what to do is Accept clients, store FD in Array Loop through Id's sending them 2 cards each Create thread with a game info struct, that reads users text input Wait for thread to finish and return value will be the players move Update game info, and move repeat step 3 4 for all Clients Break whenever only 1 player is left, or all bettings phases are over then repeat This outline makes sense in the server, but I'm not sure how to construct the client to not do anything until it gets prompted by the thread creation in the main server while loop. If anyone has any advice or links to helpful articles or example code I would really appreciate it thanks so much!!


Is host advantage real? I'm sure many of you have heard the term host advantage through out your time playing action video games. However, I was curious if this was a real studied and proven concept in game design, computer science, and network programming? I tried looking it up on Google, but all I saw was just some gamers ranting back and forth on a forum (none of them even seem to bring up client server concepts in their babbling...).


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 ?


Does StreamPeerTCP guarantee received packet is same from server? I'm making simple Godot project that works with Node.js server. To receive and send packet to Node.js server, I used StreamPeerTCP. First seems works, but after 2nd transmission from server, extract data from packet were broken and mess all other logics. This wasn't happened when same logic tested with Unity C https github.com rico345100 unity multiplayer with nodejs blob master Assets Scripts Network NetworkManager.cs Here's the repo I'm currently developing https github.com rico345100 godot multiplayer with nodejs https github.com rico345100 nodejs tcp server for godot Used Godot 3.1.2 but also works with 3.2.rc6. Tested with Godot 3.1.2 and macOS 10.13.6.


In a 2D multiplayer game should I send the position of user to the server all the time? In a 2D game where the user moves with the keyboard arrows, should the user send all the time he moves his position (x, y)?. If the user has some speed, the user would send (x, y) like 50 times pixel by pixel in just a second.


Best way to handle realtime melee AI in authoritative network environment So i've been working on a multiplayer game for a bit it's a co op action RPG with real time combat. If you've seen or played TERA, I'd say it's comparable to that, but not an MMO, heh. I'm currently handling the AI units authoritatively, the server calculates their pathing, movement, and pursue attack logic, and syncs the movement to the clients 15x per second, and the state changes when they happen. When I emulate 200ms ping, though, the client can perceive being out of range to an AI's attack, but still take the hit, because on the server he hadn't moved that far yet. This also plays hell with my real time blocking. I don't really want to allow the clients to be allowed to say "that was out of range" or "I blocked that", but I'm not really sure how else to handle it.


Turn based Client Server Card Game Unicast (TCP) or Multicast (UDP) I am currently planning to make a card game project where the clients will communicate with the server in a turn based and synchronous manner using messages sent over sockets. The problem I have is how to handle the following scenario (Client takes it turn and sends its action to server) Client sends a message telling the server its move for the turn (e.g. plays the card 5 from its hand which needs to placed onto the table) Server receives messages and updates game state (server will hold all game state). Server iterates through a list of connected clients and sends a message to tell of them change in state Clients all refresh to display the state This is all based on using TCP, and looking at it now it seems a bit like the Observer pattern. The reason this seems to be an issue to me is this message doesn't seem to be point to point like the others as I want to send it to all the clients, and doesn't seem very efficient sending the same message in that way. I was thinking about using multicasting with UDP as then I could send the message to all the clients, however wouldn't this mean that the clients would in theory be able to message each other? There is of course the synchronous aspect as well, though this could be put on top of the UDP I guess. Basically, I would like to know what would be good practice as this project is really all about learning, and even though it won't be big enough to encounter performance issues from this I would like to consider them anyway. However, please note I am not interested in using message oriented middleware as a solution (I have experience with using MOM and I'm interested in considering other options excluding MOM if TCP sockets is a bad idea!).


How to measure packet latency? In the context of lag compensation, one needs to know when the command is instantiated on the client (this can be named as "command execution time" as well). AFAIK, there can be 2 methods for this Client sends a timestamp with the command. Client doesn't send any timestamps, but server does a smart thing to calculate the command's instantiation time. About 1 Is this safe in terms of cheating? About 2 According to Valve's paper, command execution time is as following Command Execution Time Current Server Time Packet Latency Client View Interpolation This means, server must know the packet latency. Another paper from Valve confirms this and says Before executing a player's current user command, the server Computes a fairly accurate latency for the player ... How can the server compute "fairly accurate latency for the player"? Most naive and easiest approach would be sending pings regularly (less frequent than game commands and updates though) to find out an average of the latency and use it. Busy network traffic, latency fluctuation and naiveness of this method makes me feel there must be a more elegant way. EDIT Would UDP vs TCP change anything in this context?


I know that my super simple multiplayer setup is probably not a good idea, but why? I'm making a simple little MOBA just for fun. I was making everything single player then I realized "oh crap I should probably add multiplayer, huh." I've never done anything with networking before, so learning how to integrate Lidgren into my game was fun and awesome. The thing is, I pretty much know the way I'm doing things is wrong, because it's not robust enough for mainstream games to use, as far as I know, but what's wrong with it? What I'm doing is, basically, whenever a player does an action, it sends a message to the server saying "hey, I just did this thing." The server and the client are both running the same simulation. The server then sends a message to all other clients telling them that that guy did that thing. For the most part, except in a few cases, when a player does a thing, the client assumes it's cool and goes ahead with it on its own. So when you right click somewhere to move there, that player's client just starts moving his guy there, and then sends a message to the server telling it about it. So basically Player 1 casts a spell to make him move 100 faster for six seconds Player 1's local client adds that buff to his Unit object Player 1's client sends a message to the server saying "hey I just cast this spell" The server makes sure he really did have enough mana to cast that spell, and if so, adds that buff to the server's copy of that Unit object The server sends a message to all other clients saying "hey this guy just cast this spell" Every other client receives the message and goes "ah okay cool," and adds that buff to their local Unit object for that player I've been skimming through stuff to see how big games do multiplayer, and it's kind of confusing for someone who's just starting to dabble in this stuff, but it looks like the Source engine sends a packet containing all of the changes to everything in the world every tick? Again, totally new to this stuff, but can you really push that much data that frequently? Sorry if this is a bit rambly, but basically, I was wondering why my simpler system isn't the right way to go, because if it was, other games would use it, right?


Should Client Server Server Client packets be separate? When working on network packet structure for games, what is more efficient (in terms of code structure) for packet reading for client server? Currently, Our packet structure is to send the packet ID as an Int32, which is read when it is coming into the server. But to minimize the amount of packet ID's we use, instead of having a (for example) LoginRequest AND a LoginResponse, we use just a Login packet. The data is structured differently whether it is the server, or client sending the packet. Should we use an individual Packet for each Request Response? Or is there a better way? EDIT And by data being different for whether it is the client or server sending, it is different in terms of complete packet structure. So while it still has the same ID, it uses entirely different data types. Example (Using a Lobby Request Lobby Response as one packet) Client Request Packet Id (Int32) (Lets say ID 5) LobbyName (String) LobbyPassword (String) GameLobby (Boolean) Server Response Packet Id (Int32) (still ID 5) LobbyName (String) GameLobby (Boolean) MemberCount (Int32)


Client side Prediction Divergence with Input Packets and Time Differences Multiplayer FPS I am running into a problem while implementing client side prediction in my multiplayer FPS. I'm not entirely sure if I've completely and correctly understood the concepts. I have read the articles from Gambetta and from Valve, as well as several others. What I'm currently doing is sending client input as key presses and key releases the client sends when it presses 'W', for instance, and sends a packet once it has stopped pressing 'W'. The client then predicts the movement in a fully deterministic way. The server then sends a position packets to all of the clients and the client checks if there is any divergence and corrects for it. I am now running into the issue if the time between the input packets on departure differs from the time of the input packets on arrival, it will inevitably lead to small errors and massive divergence over time as the server will think the client will have pressed a key for longer or less time than it actually has. I haven't seen anyone mention this, so I'm questioning if what I'm doing is right. Another issue I am seeing with this approach is that the client sends rotation updates to the server at 64hz (my tick rate). This will, of course, lead to small differences in rotation from the server and client at specific times. Given that the movement is dependent on the orientation rotation of the player, client side prediction errors will inevitably ensue. One way I was thinking that could fix the first problem, would be to send timestamps along with the input packets and have the server rewind positions and compensate for the delay imprecisions. Before I follow through with that, I am seeking some confirmation as to what I'm doing is right. Any help would be appreciated! Thanks!


RTS game How to handle disconnects in a fully connected peer to peer architecture? I'm currently working on a game in which I am considering implementing a networking architecture as described in this article http www.gamasutra.com view feature 131503 1500 archers on a 288 network .php In order for the implementation as described in the article to work, all peers need to be interconnected without any exceptions. Like so This works fine when everything is well. But I am wondering how to agree on disconnects in such a network. (Sadly something the article does not go into). It is relatively easy if one client goes down. Just give every client a timeout, and if a client does not respond for a certain time, it is removed from that client. However, how should the system solve a case in which one client does not respond to another, but still responds to all others. In such a system the following could happen, resulting in a invalid state Of course this can be solved by giving one of the clients some kind of "master" role. It being the only one that can decide whether or not to disconnect other clients. But I'm wondering if it can be achieved in a pure p2p network. Note I realize this case is not one that can likely occur "naturally". But I want to prevent players from being able to ruin a networking game for others by playing a trick like this by using the firewall for example.


Should I sync animations from the server to the client or let the client play its own animations? For example, if the user presses the "Fire" button which leads to the player character doing some kind of animation, should the client evaluate itself if it can play the animation or wait for a response from the server telling it that it's ok to play the animation?


Handling packet impersonating in client server model online game I am designing a server client model game library engine. How do I, and should I even bother to handle frequent update packet possible impersonating? In my current design anyone could copy a packet from someone else and modify it to execute any non critical action for another client. I am currently compressing all datagrams so that adds just a tad of security. Edit One way I thought about was to send a unique "key" to the verified client every x time and then the client has to add that to all of it's update packets until a new key is sent. Edit2 I should have mentioned that I am not concerned about whether the actions described in the packet are available to the client at the time, this is all checked by the server which I thought was obvious. I am only concerned about someone sending packets for another client.


Latency issue on multiplayer game networking I am currently writing a 2D top down shooting multiplayer game using Java. I have a game loop at the client side that does the following in order in each game tick (The client is running in a tick rate of 60 t s) client gameloop 1. Send an input sample (an object storing info about what keys are pressed) to the server through a DatagramSocket 2. Receive info on change in game state from the server 3. Update the client side game state through the received info For the server side, I have a game loop that does the following in order in each game tick (The server is running in a tick rate of 60 t s) server gameloop 1. Read an input sample through a single DatagramSocket 2. Using the input sample to apply physics to the game world and update the game state When I try to connect the first client to the server, the game flows fluently with unnoticeable delay. However, when I try to connect the second client, both first and second client start to lag behind the server greatly (delay ranges from 5s to 10s). I am currently stuck on what causes the delay. Am I handling the sending and receiving of info between client and server in a wrong way that causes game state in the server side not being able to synchronize with those of clients'?


Hide network latency for ingame dialog I have a tick based Multiplayer RTS game Client sends action to server at Frame n which will be broadcasted to all clients and executed at Frame n x (x depends on network latency of slowest player) I'm unsure how to hide this latency in GUI dialogs. E.g. a value that is adjustable with a slider between 0 and 100. The current solution simply fills a "virtual" value with the actual value at game start and always operates on that value. It is highly unlikely that a change command for this does not get executed (TCP, unconditional change execution) but it is possible (packet sent and ignored during pause) I also wanted to keep that value local to the dialog and not store it somewhere else. Start idea Get the current value on dialog open and use this while the dialog is open. Problems Maybe the value was changed before (packet sent, but not executed) in which case the change does not get displayed. An idea I have is storing the last value I got and update the slider if that value has changed. Maybe only when the sliders position itself did not change (by the user). However then after the update it will detect that change and change it again which leads to a change of twice the amount requested. I could also update the "last value" when the packet is sent but that will cause the (time based) update to change it back till the actual change is made which might even result in a loop of back and forth changes. How can I keep the GUI and game in sync but allow visual changes? Seems I'm missing a little piece here... Another part where this is even worse is with other kinds of dialogs. E.g. an ordering dialog (put some entities in a specific order) or a number input that is used to request producing the specified amount, hence the game may also decrease this, not only the packet. I could not find any guides or solution besides "use inter extrapolation" which is not applicable here. How do others do this? Edit Maybe a little example for the strategy I though off with its flaws A) OK Value 4 Open Dialog Show Value 4 User Changes Value to 6 (Slider position change) Sent to server Server sends "6" Slider changes to "6" (no change as it already is) B) OK Same as A) but dialog closed before receiving from server Dialog reopened Show Value 4 Server sends "6" Slider changes to "6" C) Value 4 Open Dialog Show Value 4 User Changes Value to 6 (Slider position change) Sent to server User Changes Value to 7 Sent to server Server sends "6" Slider changes to 6 BAD Server sends "7" Slider changes to 7 OK, but strange and may cause feedback loops D) Value 4, change to 6 requested Open Dialog Show Value 4 (6 was stored in the old dialog) User Changes Value to 7 Sent to server Server sends "6" Slider changes to 6 BAD Server sends "7" Slider changes to 7 OK, but strange and may cause feedback loops So on one hand I only want to show visual values (and store them between dialogs) but on the other hand I want to keep them in sync with the actual value. So only solution here seems to be to persistently store the visual value and make sure, each update will eventually be executed. But I'm still clueless what to do with values that can be changed by the came (e.g. production orders that decrease once they are processed)


Designing client server to mitigate hosting advantage? My game will be client server, and I'd like to prevent the hosting player from enjoying the usual benefits you'd associate with playing on a server. For example, the advantage of the server running ahead of time compared to clients. Are there simple ways of mitigating host advantage? Or do I have to make something complicated? My naive solution would be having the host run a "ghost" state, and a client state, on the same map. The ghost state is an authoritative server simulation, it doesn't render the simulation which remains invisible, but does run ahead of time making calculations and decisions as usual. The host also plays a client on the same map, in which their input is regarded as any other client across the network, and like any other client is required to wait for the server simulation to make and transmit outputs. And so the host doesn't enjoy an advantage because they aren't playing the simulation which is making executive decisions on the game state ahead of client time. Has this solution been done by any other games, or is there a better way of handling the problem?


Multiplayer tile based movement collisions cause client prediction to fail I am developing a tile based online multiplayer game, but I am stuck. Players can move across the grid in the four cardinal directions, as can enemies, but two players enemies cannot occupy the same tile at the same time. Positions of all players enemies are synced for all clients. My current implementation of movement Clients send a 'request to move' to the server whenever they are stationary on a tile. I have implemented client prediction. When a button is pressed to move, the client shows their character immediately moving in that direction, as opposed to waiting for confirmation from the server, preventing lag between player input and visible results. The issue arises when the player attempts to move to a position that will soon be occupied. For example, the player presses up when an enemy is very close to entering the tile above the player (though they can't currently know that the enemy will choose that tile next). Locally this is confirmed and the upwards animation begins, but by the time the request to move up arrives at the server, the tile is no longer free, and the player is not moved up on the server. This creates a situation where the player's local position is out of sync with that of the server. My current solution to this is snapping the local player back to the server's position when this happens, but this looks awful. It seems to be happening a lot, making the game nearly unplayable. Is there a way around this? Any help would be very much appreciated, thanks. Some other notes I send updates from the server 10 times a second, which consist of every object's position (and other stuff). When a movement event is processed, the object's position is updated immediately, even though an animation follows.


Need help choosing the right networking approach platform for an RTS I have been thinking for a while about making an online 2D RTS like game. (2 6 players in a match, up to 50 60 units, no AI). The key thing here is that I want the game to be playable in a browser, so it'll have to be either flash or java applet, both using TCP sockets. At first I was entirely focused on flash because of a higher market penetration and accessibility. However, after reviewing different networking approaches I am unable to make a choice. I really liked lock step simulation approach where server and every client are running the exact same simulation, until I realized that it's going to be tough as hell (if not impossible) to implement exactly the same logic in two different languages, one of them being actionscript. This is where java comes in. With java client and server can share simulation related code that may as well cut the development time in half. But then there is another approach, where clients try to simulate (or rather extrapolate) the game state correctly as long as possible, but they don't have to do it right at some point they are going to receive the full state snapshot an adjust accordingly. Flash looks like a viable option again, but still, lock step simulation seems so much more straightforward, as there is no "adjusting" part. So are my assumptions correct? What would you suggest?


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)))


Which server platform to choose I'm going to write a server for an online multiplayer with these requirements Pretty simple turn based game (think a card game) that is played entirely on the server (security reasons) Must be able to run multiple games (tables) with 4 players per table, but no lobby system required (another server takes care of that) Can support as many players at once as possible Might need multiple servers Chat between players Socket connection to a Flash AIR client Must be able to communicate with other servers (for player accounts and such) Now, I'm considering two options Smartfox (or equivalent) A custom Java solution in something like Tomcat Why Smartfox? It handles multiple rooms and chat natively It presumably has solutions for well known multiplayer gaming issues Why custom? Smartfox has many unneeded functions, bad for performance Smartfox communicates with an XML based format, I could use a more efficient binary one. Don't know if running the entire game model on the server is convenient with Smartfox' extension mechanism Multiple rooms and chat are easy to reimplement Tomcat or a lightweight container is easier to deploy than Smartfox Better IDE support for developing on Tomcat (automatic deploy, etc) What do you think? Are my assumptions correct? Do you have anything to add? What option should I choose (or maybe a different one entirely)?


How to sync client and server at the first frame I'm making a game where an authoritative server sends information to all clients about states and positions for objects in a 3d world. The player can control his character by clicking on the screen to set a destination for the character, much like in the Diablo series. I've read most information I can find online about interpolation, reconciliation, and general networking architecture (Valve's for instance). I think I understand everything but one thing seems to be missing in every article I read. Let say we have an interpolation delay of 100ms, server tickrate 50ms, latency 200ms How do I know when 100ms has past on the client? If the server sends the first update on t 0, can I assume it arrives at t 200, therefore assuming that all packets takes the same amount of time to reach the client? What if the first packet arrives a little quick, for instance at t 150. I would then be starting the client with t 150 and at t 250 it will think it has past 100ms since its connect to the server when it in fact only 50ms has past. Hopefully the above paragraph is understandable. The summarized question would be How do I know at what tick to start simulating the client? EDIT This is how I ended up doing it The client keeps a clock (approximately) in sync with the server. The client then simulates the world at simulationTime syncedTime avg(RTT) 2 interpolationTime The round trip time can fluctuate so therefore I average it out over time. By only keeping the most recent values when calculating the average I hope to adapt to more permanent changes in latency. It's still to early to draw any conclusion. I'm currently simulating bad network connections, but it's looking good so far. Anyone see any possible problems?


Networking middleware I'm looking for a networking middleware that may be suitable for a medium sized MMO. I don't care in which language it's written, just that it's high level, stable and has many of the features that can ease my development. I am making a 2D real time action game. Come to think of it... I'd be happy with "just" a high level networking framework that has a few handy features to ease the development of a general networked game.


How do I create a server for an existing game I don't have the source for? I was wondering if it is possible to create a dedicated game server for a game that already exists and you don't have access to. For example, a game on Steam that only allows multiplayer through hosting a game with your running client. A client can host a server but only while the hoster is also playing the game. The question being, is it possible to write a server from scratch that can replace the game client host with a dedicated server that does not require a player hosting it? If so, how?