   Projectiles -- Could this work?
  I'm working on a &#106avascript/php multiplayer 2D RTS game, and I need to figure out how to model projectiles in an efficient manner. Efficiency is very important, because I need the server code to be able to scale well, and handle many games at the same time.For various reasons, I decided to have an authoritative server that simulates the game, and sends regular updates out to each client every 100ms (so far only 2 players, for efficiency purposes). This isn't too bad, because it's a small-scale RTS with each player controlling only 20 units or so.Each game update has a number associated with it, so each player will never have to download an update twice, and to make synchronization easier. The game update also has any number of "sectors" associated with it, containing various types of data. Right now, I only have "units created/destroyed" and "unit updates", containing all the necessary information the client needs to know about each entity. I'll soon be adding a "projectile launched" segment to tell each client when, where, and in what direction a projectile is created.Since neither player can influence the path of a projectile after it is launched, I figured that I don't really need to send location information for each projectile from the server every game update. I WOULD potentially have to send collision data, though.ANYWAY, the point of the thread: Where to do collision calculations.The simplest way would be to do the collision detection on the server, and send the ID of the projectile to the client when it hits something. That wouldn't add too much network overhead, and would be relatively easy to code.I could do collision detection on the server and client at the same time, which would be twice as much coding, but would save significant bandwidth at the cost of client cpu time. This isn't really viable in my opinion.HOWEVER, when I was thinking about how to do collisions, I thought that I could potentially do all the collision detection on each client separately and have each client report back with the results any time it found a collision. This would save significant server CPU resources, while still being relatively hack-proof, given that both clients would have to be hacked in the same way for a player to gain an unfair advantage. If a discrepancy is detected, the server could call the game over, and process the replay to see who hacked.Would this work? Does anyone know if something like this has been tried before? Should I just stick with doing everything on the server?   
  I'd keep it simple and do the first one and two, which are the same. How would you simulate the projectile on the client? without collision detection? What happens when the projectiles goes through a wall?From the server, send to all a 'create projectile' message, with initial position and velocity.  Do the calculations (trajectory and collision) on every machines concurrently, and the server, when the projectile hits something, send a 'hit' message to the clients. On the clients, when a projectile hit something, disable it and wait for the 'hit' message to blow up the projectile at the right place. The bandwidth will be minimal. You need to send a 'create' message, reliably, to all clients, and a destruct message (position, normal of surface hit, object hit and what not) to all again at the end. What happens in between can be 'faked' relatively accurately on clients, if the trajectory is pretty straight forward (mortar shell, bullets, even homing missile I suppose, it just needs to track a specific entity, the path don't necessarily need to be in sync).As for CPU, I don't think simulating projectiles would be that taxing. The #3 is too complicated imo. Worse case scenario, how many projectiles exactly are you thinking of having at one time?   ;Quote:Original post by oliiiHow would you simulate the projectile on the client? without collision detection? What happens when the projectiles goes through a wall?Since the client only updates when the server does, the client has all the same information as the server, so the client could do collision detection exactly like the server could.Quote:Original post by oliiiAs for CPU, I don't think simulating projectiles would be that taxing. The #3 is too complicated imo. Worse case scenario, how many projectiles exactly are you thinking of having at one time?I'm not exactly sure what the fastest firing gun would be, but I'd imagine it will be somewhere between 25 and 100 ms. If each of 20 ships has 2 guns that fire every 25 ms, the upper bound would be somewhere around 1600 every second. You'd have to have a pre-set up special situation to get much more than half of that, though, due to the way the game mechanics work.I guess I could always try it both ways ^ ^   ;Quote:I'm not exactly sure what the fastest firing gun would be, but I'd imagine it will be somewhere between 25 and 100 ms. If each of 20 ships has 2 guns that fire every 25 ms, the upper bound would be somewhere around 1600 every second. You'd have to have a pre-set up special situation to get much more than half of that, though, due to the way the game mechanics work.wow, 1,000 shots every second, that's quite a lot. That would be a lot of data to transmit. Say you need 10 bytes for every shot created, that's 10KBytes / second for each client.You also have your ships, 20 ships @ 20 fps, 10 bytes each, that's another 4Kbytes / second for each clients. total, around 10-16kBytes / second for each client, so a total of around 300 KB/s for hosting a 20 player game, or over 2 Mbps upstream. eek! And 10 bytes per update / creation is very tight. You could easily double that.   ;  Yeah, I realized as I was typing that it was way too many, I might have to try to get it down to 250/s or something.There are only 10 game updates per second, I'm going to be using interpolation to get some extra frames out of each actual game update, so it doesn't look too jerky.Each projectile creation message basically only need the x and y positions it is fired from, the angle at which is fired, and the client-side resource ID of the projectile in question. Even if I went waay overboard with the size of each thing, I could probably fit it into 6 or 7 bytes (compressed).Assuming 7 bytes per update * 250 projectiles * 2 players, that would be 3.5KBup/s, which seems a bit more reasonable.Also, it's an RTS, so the 20 ships are split between only 2 players... there won't be any 20 player games. So with this new maximum projectiles, it would be something like 10kBps, or 80kbps. Hosting 10 2-player games would be 800kbps, which still doesn't seem like that big of a deal.How reliable is speedtest.net? It's telling me I have over 6Mbps upload speed, almost as high as my download speed :o   