Since the last devlog I've been working to get to a minimally playable game. Units now have turrets, they can fire at each other, and get blown up when they tak...
Nice work, I really like the fire and forget style of bullet, which greatly reduces the network traffic of many bullets moving around at once (just sending start x,y,vector of bullet vs send x,y of bullet every server tick) - Have you ever seen it go 'out of sync' between server expectation and client expectation (e.g. with subtle timing differences between CPU time on server vs client). I imagine there could be drift, but the time frame is short (bullet life) and both sides use pix/dt instead of pix/frame.
I haven't really done any real testing on the networking code yet, but I definitely will at some point. Poor network conditions might cause the hit event (and resulting explosion) to not visibly line up with the bullet or the unit it hit. But I think it can mostly be covered up reasonably well by the client. For example given the bullet movement is predictable, if a "projectile fired" message arrives late due to being delayed by the network, the client can advance the bullet to compensate for the lateness, and then it's back in sync. I'll be digging in to all those details in the blogs when I get to beefing up the network code.