Hey everyone it’s time for your regularly scheduled update. This week everybody continues their work on large, multi-week projects. Flavien has made some good progress on networking and has completed his initial implementation of our new client-side prediction code. To summarize, this means that the server is able to compensate for latency so that when it looks like you shot something on your screen the server actually agrees with you. This is obviously extremely important for a solid dogfighting experience. There’s still quite a bit of work left to be done as he needs to merge his test code with the game’s code and once that’s working move onto server-side collision detection with planets - a difficult problem.
Pre-rendered image of the command center of a factory
I ran into what I’ll refer to as an unexpected patch of deep mud while working on the path rendering R&D for the UI which has slowed me down over the last few days. The paper I’m using is dependent on some big-data and scientific computing algorithms that are readily available on NVIDIA hardware but not AMD hardware. I have to convert them to be cross-platform which is time consuming, error-prone, and tedious but once I finish getting through it I’m optimistic about wrapping up the rest of the initial path rendering code soon. I’ll still have to take care of font rendering and a few other things but at least I should be able to start showing screen shots.
On the art side Kristian continues to work on the factory which is composed of many large, complicated structures. Once Jan finishes with the space whale bobble head placeholder, which is already looking pretty good, he’ll be helping Kristian finish up the factory before they both move onto the land base. Dan is starting on the final geometry pass for the destroyer which is likely to be the first capital ship we implement in the game.
Hey, just blowing in for my once-in-a-blue-moon post. A quick question about the collision detection - why is this particularly difficult? I’m not trying to say “What can’t you just…” about a programming problem, I’m genuinely interested in the problems posed here. Broadly speaking you would place the hitbox over the planet and run the terrain algorithm for the points it covers then see if there’s overlap, right? Like, you don’t need to generate anything like as much as you do for rendering, you’re covering a small section of the planet for each player.
I get that if there are hundreds of players you need to quickly churn through the collisions for them all, is that where the problem comes in?
Yes, this is where the problem comes in. If we want to support 200+ players on a server for epic space battles and it just so happens said epic space battle is actually happening on one or more planets and all of those players are zooming all around said planets we now have to do an incredible amount of on-demand terrain patch generation for all of those collision detections. Since every player is potentially flying incredibly fast most of that work has to be immediately discarded as players move from one patch to the next so basically the worst case scenario is that the server is stuck constantly devoting a tremendous amount of resources to generating terrain patches it only uses for a fraction of a second.
Right, so when you’re generating regions for rendering, you can keep some of the previous results cached because they’re still visible, which reduces the load even though there’s so much terrain that’s visible at once, but you can’t do that for collisions. Is that about right?
More or less however the client only ever has to cache terrain for a single viewpoint and it doesn’t care about anything that occurs beyond a certain threshold outside of that viewpoint. The server has to cache terrain for X viewpoints which quickly becomes unfeasible from both a memory and a compute standpoint. Therefore we have to use voodoo black magic to make it work.
Nice to hear work on the capitals is underway again. Does this mean you’ve got a working unique control system for them (or fully fleshed out idea for it)? Or will the destroyer be making its first appearance using the standard twitch controls?
Also, has Jan considered giving the whale a rocket backpack?
It seems to me that server side collision detection on terrain only needs to be a sanity check to identify hacked clients. The actual collision detection would be best done client side to avoid lag and the only reason doing that is a problem is that someone might hack their client.
You need server side checks as well, but there seems no need to run them every frame. Why not just check one client per frame on the server? So if there’s 50 players connected each player would be sanity checked every 50 server ticks. If a check fails you could increase the number of checks done on that player and if it keeps failing consistently throw them off the server.
I don’t think it’d work that easily. First of all, the game using client side prediction with physics, if the physics on the server disagree, it is authoritative. Since there’d be no collisions with the terrain on the server it’d disagree all the time, in other words although collisions would get detected on the client the server would constantly ignore them. The only way to fix that is to make the entire collisions client-sided ( not just with the terrain ), including other players or other structures.
The other issue is that it closes the door to anything that is NPC based ( there’s no client for those ), like the haulers, AI/bots ( which some of you advocate on low-population servers ), and also some server gameplay that needs to do some ray-casts ( like detection / sensors ).
I think @Crayfish is suggesting that the functionality be present on both client and server, but that the server relies on the clients as much as possible so as to offload compute load. Because clients cannot be trusted, the server spot checks the client claims.
NPCs would remain on the server and continue with their full compute load.
Note that with the functionality also being available on clients, NPCs could be implemented by other processes that connect via the network. Headless clients. If those processes are considered trusted, then the server doesn’t need to spot check their calculations. That could come in handy especially for a PvE experience where compute demands increase dramatically.
Thought provoking stuff, thanks for the reply. The reply by @JB47394 mirrors my own thinking on the issues he covered.
I’m coming from a place where I play a lot of Arma 3 and it’s fairly obvious that all collisions are dealt with client side. The giveaway is the rubber banding that happens with objects that need to be synchronised to the server. I guess Bohemian Interactive rely heavily on Battleye to make the client as trustworthy as possible.
Rubberbanding is another issue, due to variable latencies ( changes in ping, packet drops ) with network interpolation. The client simulates itself in the present but shows entities in the past. The more in the past, the smoother the interpolation looks like, but the more latency there is ( which gets compensated usually server sided ). If you get more agressive with latency ( to minimize it ) you might get more rubbderbanding when your connection has instabilities. For example my connection to the azure battlescape server can quickly change from 105 ms to 145 ms, that’s ± 40 ms that could change in a very quick amount of time.
All that networking stuff is great but we all know the most important thing is the space whale.
Personally I don’t like the fact that the whale has been contorted into a cartoony S-shape pose with a tiny tail.
I’d love it to be closer to the concept sketch which looked great!
How about having it more horizontal with the head wobbling sideways?
While we’re at it, make the fins and fluke wobble too?
If you’re thinking “It needs to be vertical for the wobble to work”… then remember you’re on a space ship, gravity is which ever way you’re accelerating.
I quite like the comical style of the whale in the shown mockup. It caters to the theme that most Bobbleheads are caricatures of real world things. Even without the bobble I find the shown mockup more expressing the message/joke/fun of a Bobblehead.
