🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Crackdown 3 Technicalities

Started by
0 comments, last by Servant of the Lord 8 years, 9 months ago


This looks awesome. I don't know if it will be fun to play but I'm impressed with how much is going on. Anyone have any ideas on how they might have pulled this off? I get that they have TONS of servers computing stuff, but even then, they can't send that much data for 1,000 objects or .....100,000 objects that frame. I'm not sure the exact number of busted objects but it looks like it can grow forever and they just. He even says over time you can blow up the whole city.
My guess would be that objects are handled like the "Million GPU Particles" and they are update textures/buffers per frame that store transform data, and then a single draw call for a bunch of objects. Other than that, it would be too many draw calls to do each object individually.
The physics networking is what I can't figure out. Again sending each objects update per frame is going to be way too high. So the server could then compute the broke mesh pieces, and tell the clients "Hey these meshes were busted and now form these smaller meshes and here is the direction they are going". But I feel like there would be so many syncing issues between the client and server given how many physics interactions are occurring and if something went out of sync, you couldn't just re-correct it if it were wrong because it would cause objects to snap.

NBA2K, Madden, Maneater, Killing Floor, Sims

Advertisement

I didn't watch the video, but the journalists reviewing the game were given weapons that were temporarily made more damaging/explosive than those weapons normally are when users eventually play the game (I don't know if they mentioned that in the video, but it was in a news article a few months back). This means it'll take alot alot alot more work for players to collapse a skyscraper, which means not as much content will be

Below is my speculation:

Objects don't need to be sent "every frame" even in regular networked games. Even if their positions and velocities are sent just once a second or less, you can still predict (based off their previous positions and velocities) where they will be going. With real-life players, a player can turn and walk in a different direction, so you need to send the real position and velocity much more frequently, but with a rock flying through the air, it's not going to change direction suddenly. Objects in the distance need to be updated from the server even less frequently.

Once the rocks land, they don't need to be updated anymore unless the player starts interacting with them again. Rocks don't move on their own. So once a building settles, and a player is a few hundred feet away, the server doesn't need to do any more calculations on it, just store the positions, and only kick up some more physics calculations when the player starts interacting again. The farther the player gets from the building, the more the server can put the complicated parts of the simulation in deep freeze.

This topic is closed to new replies.

Advertisement