and even if some idiot put every zombie npc in a database (or if you want to think of it that way), you wouldn’t just delete the rows! the bodies would disappear, so instead you would update that row like (npcState = KIL, bodyLocation = <some coords>) or something. Especially if you wanted to keep player stats
Maybe you would have an array of active enemies in RAM, and when enemies are killed they are removed from that array for example?
In a game like Minecraft for example, you definitely wouldn’t want to store every single dead entity and its location when there can easily be thousands created and destroyed in a single second
Definitely depends on the type of game, but it’s more likely the game stores data about which areas you cleared and then infer that the bodies of any permanently remaining enemy (like bosses) is to be displayed.
Can vary even more for procedurally generated levels. If the set of enemies is fixed and stay in calculated positions in a map generated randomly, then it might store an array or something tracking the enemies.
Procedurelly generated stuff is all about storing the differences from the procedural generation.
So for example minecraft saves don’t store the terrain, they store how it differs (due to player interaction) from the procedurally generated baseline.
(After all, all you need to recreate an untouched procedurally generate world are the bytes of the seed and nothing else)
and even if some idiot put every zombie npc in a database (or if you want to think of it that way), you wouldn’t just delete the rows! the bodies would disappear, so instead you would update that row like (npcState = KIL, bodyLocation = <some coords>) or something. Especially if you wanted to keep player stats
Isnt there this graveyard off map somewhere in Skyrim, where all the bodies get teleported?
Why would that even be necessary? Sounds like one of those “make a guy with a train for a hat and run up and down this hall” moves they like to do
Their code is literally spaghetti
l-… literally?
I wouldn’t be surprised if it is true though. Bethesda games are not exactly winning awards for coding elegance.
If they literally don’t have an object delete option then relying on render distance to make it go away is a ridiculous but simple solution
i can’t speak to that, but it sounds plausible. in that case the body location would be updated to those coordinates
Grab the source here before Bethesda DMCAs it.
npcState = KIL
no
Where was you when
I want the rows deleted. I’m going to market it as the first game with true AI/enemy permadeath. Dibs on the idea!
Maybe you would have an array of active enemies in RAM, and when enemies are killed they are removed from that array for example?
In a game like Minecraft for example, you definitely wouldn’t want to store every single dead entity and its location when there can easily be thousands created and destroyed in a single second
It obviously depends on the game though.
Definitely depends on the type of game, but it’s more likely the game stores data about which areas you cleared and then infer that the bodies of any permanently remaining enemy (like bosses) is to be displayed.
Can vary even more for procedurally generated levels. If the set of enemies is fixed and stay in calculated positions in a map generated randomly, then it might store an array or something tracking the enemies.
Procedurelly generated stuff is all about storing the differences from the procedural generation.
So for example minecraft saves don’t store the terrain, they store how it differs (due to player interaction) from the procedurally generated baseline.
(After all, all you need to recreate an untouched procedurally generate world are the bytes of the seed and nothing else)
This is how it works in many game engines.
You set up the monsters and just hide them/disable them. They’re already allocated to memory.
And it’s a performance cost to create/delete versus just moving a dead enemy out of view, then respawning that enemy later in the level.
deleted by creator