Aspiring game programmer here. I was playing GTA V yesterday and it got me thinking. How do you think object buffering works in this game? Specifically, how are all the entities like cars, pedestrians, random animals, etc. created and destroyed? Is this done on the fly? Like I noticed that sometimes I will spot a nice car I want to steal, I'll drive past it for 20 seconds, then turn around and go chase it - only to not find it even though the road didn't have any branches for it to escape me (highway). So is stuff generated before you arrive there and then quickly discarded? Or is it some clever spatially partitioned database that holds everything in check? It's technically very impressive that you can drive through the whole city with this many objects and stuff going on and I don't understand what's going on. I don't think I could program something like this if you gave me a supercomputer to work with, yet this works reasonably well even with older hardware. So what gives and how did they do it?
Aspiring game programmer here. I was playing GTA V yesterday and it got me thinking...
Other urls found in this thread:
adriancourreges.com
twitter.com
I hope you noticed that your cone of vision plays a role, while some entity is within your drawing distance, it tends to disappear while you're not looking at it. I'd wager the higher the LoD of an object, the less likely it will be to despawn while you have line of sight on it.
They took their 100million dollar engine from GTA IV, and they patched it for DX11.
Works fine with DX10 too
Can't comment on GTA V, but played Vice City and San Andreas a lot. Cars you interacted with are remembered longer, rest is generated on-fly depending on visibility. In SA it was radius, in VC it was angle on view. This isn't TES-like every character being scripted with daytime routines.
They use the same system since GTA 3, if you are not looking, cars dissapear
yeah, it's probably a combination of line of sight and distance
i'd wager objects are more likely to be spawned closer to the player, out of sight; and further away or hidden objects are freed from memory as appropriate or required
>How do you think object buffering works in this game?
As a wild guess, they probabbly figure out how many objects they can roughly hold in Memory, then check every couple of frames which objects are unnecessary, based on player position, state, velocity and FOV and if there is a necessity to free up memory.
It can probably also scale the quality of models depending on that.
Honestly the most impressive things in Video games is that they work at all, it certainly wasn't easy to do real time 3D rendering and create the hardware necessary for it.
One time I stole a car and there was this fatso driving it and he got mad and started chasing me, I let him chase me on foot for a few blocks so he'd get some exercise and shit, and then I parked the car for him and as I walked away from the car I looked behind me and the dude wasn't chasing me anymore and the car was gone. The guy just walked past me then. So I guess it's on fly generation based on field of view? Kind of immersion breaking but I understand why it needs to be done like this.
Fairly sure it's created on the fly and has been since the early GTA games. If you drive past a bunch of cars and turn around to follow them they will have disappeared if they went outside the buffer around the player. The buffer is somewhat larger in GTA5 than previous games because you can be quite far away from cars before they disappear.
It's not that hard programatically, you know where the players location is, what their field of view is and so what is visible and what isn't.
The more subtle things going on here is things like the type of roads and their locations in the game decide what sort of types of cars will likely spawn there and how many, so a dirt road in rural areas will more likely have 4x4s, dirt bikes etc, and inner city in expensive area you'll have more posh/expensive cars.
Certain things will force the buffer to stay for longer, if that car interacts with the environment in some way like they're part of a collision, if the driver dies or gets out, all that stuff kind of pins the car into the world in a way which survives being outside of the players buffer a bit more robustly, I suspect that's also true of special vehicles like police cars, ambulances and fire engines, probably the military stuff too.
Planes and other aircraft like the blimp are so few they're probably tracked globally.
>The more subtle things going on here is things like the type of roads and their locations in the game decide what sort of types of cars will likely spawn there and how many, so a dirt road in rural areas will more likely have 4x4s, dirt bikes etc, and inner city in expensive area you'll have more posh/expensive cars.
this, GTA V has a bunch of really large, painstakingly created files with all of that information.
handling.dat has all of the handling information for every car in the game (including things like, if i'm not mistaken, how much grip the car has, it's health points, how quickly it loses health when shot and how quickly that health loss decreases the car's performance, etc), popcycle.dat has all of the information on who spawns where (it's tied to neighborhoods, so if you're in venice beach it will spawn peds based on the information in that section, different peds will spawn if you're in grove street) pedpersonality.dat has all of the AI information (gang members will pull guns if you insult them as Trevor, they'll tell you to fuck off and then pull guns if you insult them as Michael, they'll do different things if they see police vs paramedics, same as if they see rich pedestrians vs homeless people).
you can edit all of this with OpenIV. try it out. it's fun.
Depends on the engine.
You got answers for why it is that way in GTA but if you generalize to all games (or routines), basically you have events that are priorities and those that are not, interacting with an item or event might bump it to priority though they may have kill events (like a time limit, so as to prevent memory problems for example).
This is why shit disappears in GTA and makes your toaster able to run it even if it's draw distance is super small and items get reduced to just a few.
But also why simulators are so memory intensive, every item has a constant event that needs to exist to keep the simulation running faithfully. At one point you'll have so many simulated events that you have no memory and you bottleneck the thing until it dies basically.
Using GTA as an example for assigned priorites, if you want to steal a car, you need to keep it in view (it needs to keep existing while seeing them otherwise it's weird if things disappear while you play) or trigger an event with it, like crashing, scrapping, shooting etc, which bumps it even higher and now it won't disappear even if you stop looking, but will still have a kill action like time limit, area limit, and so on.
I've not messed with these but figured the data would be stored somewhere.
I remember this being done as early back as Carmageddon II: Carpocalypse Now. That game stored all the car info in .txt files which were a kind of primitive ini file with values, it had strength of the car parts, weight, chance to sheer them off from the car given a certain force and all sorts of things, you could just edit in a txt editor.
After messing with the demo so much, found it funny that they eventually encrypted those files in the full game and changed the extension of the file to .twt which we all lovingly called .twat files. I remember editing them to have a really likely sheer value as crashes had some chance of sheering the car literally in 2 pieces and faffing about in game constantly sheering in 2 all over the place, really funny.
It is a crazy level of engineering though, it's really subtle in game but it does make a big difference, it means you can hunt for specific vehicles by going to specific areas and things that really matter to gameplay.
desu I would prefer it if games skimped on graphics and textures in favour of physics and simultaneous objects
>It's not that hard programatically, you know where the players location is, what their field of view is and so what is visible and what isn't.
Yeah, what's hard is the details about field of view detection. Things like occlusion and determining at what point something becomes visible. Is it the number of vertices on the model that the projected FoV hits? Is it a certain coverage of the FoV projection?
I imagine in this field you can have implementations that differ in efficiency by orders of magnitude.
I wish I had the tenacity to work through something like this one day.
Interesting, thx
I don't think it's as complicated as that, at least not for spawning and maintaining the entities, you don't want occluded cars suddenly being de-spawned because they may only be behind cover briefly before re-emerging such as driving behind a building or around a corner out of sight.
What you're more interested in is the causal implications, if you suddenly de-spawn a bunch of vehicles on a busy road the rest of the AI entities have to adjust to that change and that's a problem.
My bet is they have a relatively simple forumla for this, and that'll be anything that's inside some radius from you is forced to remain active to keep causality around you relatively coherent. Anything in some further radius is probably at risk of being de-spawned under certain conditions like probabily of moving further away from you given your current speed and things like line of sight. Anything that's directly in your FOV won't de-spawn unless it exists beyond the draw distance for that object.
Things like occlusion is done independently, that's to save on rendering power, just because you can't see something doesn't mean you want to stop simulating it, again for causality reasons. If you throw a grenade over a building you want whatever is on the other side to explode.
Memory isn't really a problem, the amount of data per object/vehicle is tiny really, you maybe have 100 pieces of data to be tracked maximum. It's caluclating the decisions/behaviour of the AI that's the intensive part.
I'd also be willing to bet at distances where the objects are very small such as distant motorways the AI is dropped entirely and the behaviour of traffic is basically "dumb", just particles moving along lines at a fixed speed kind of simplicity.
>I'd also be willing to bet at distances where the objects are very small such as distant motorways the AI is dropped entirely and the behaviour of traffic is basically "dumb", just particles moving along lines at a fixed speed kind of simplicity.
yes, but the fake cars are organized into vehicle types and their location is tracked, so if you see a truck driving down the freeway and you go to that location, you'll see a truck.
>I'd also be willing to bet at distances where the objects are very small such as distant motorways the AI is dropped entirely and the behaviour of traffic is basically "dumb", just particles moving along lines at a fixed speed kind of simplicity.
Yep, you can see this by using a telescope at your online crib for example; very low LoD cars just follow the street and overlap at intersections. Video game graphics seems like a competition to cheat as much and avoid as many operations as possible.
I've seen the fake car overlay fade into different, real minimum LoD vehicles many times.
It's about trade off, whatever CPU/GPU cycles you save in places where it's hard to notice the trade off, like at immense distances, the more cycles you can spend up close where details are important.
>I let him chase me on foot for a few blocks so he'd get some exercise and shit
jej
It's actually I inmmersive because it's a nigger ridden neighborhood
this game have still better damage models than most modern games.
>It's technically very impressive that you can drive through the whole city with this many objects and stuff going on and I don't understand what's going on. I don't think I could program something like this if you gave me a supercomputer to work with, yet this works reasonably well even with older hardware. So what gives and how did they do it?
Stuff won't render if they're not on your FOV (which is why stuff disappear when they're too far away or when you turn around) and every object have some LOD (levels of detail), so when you're far from a building, it won't be as detailed as when you're close to it. That is why the game works well even with older hardware.
GTA is a great example to explain LOD principles, btw.
rendering is usually separate from the game state
the game can keep track of the position and deformations of objects without that object being in view, it just skips rendering it until it comes into view.