>All these overcomplicated solutions
If you know how many animals will there be at maximum (and you should), use an array to store all animals. Iterate over it to update it. If an animal dies, swap it with the last member of the array, and reduce its count. Then, iterate again and render.
You can do this because you don't need to keep the animals ordered to be updated, so swapping their orders is cheap. It is even cheaper than mallocing and freeing every time you update the population, and chances are that, if the user can already hold an array as big as the MAX_POPULATION, you won't need to free it any time soon. You can always make a resizable array if you want to, and it will be easier on memory, cache and CPU than a linked list. It is also better than making a 2D grid (seriously anon, what the fuck), since it will consume less memory, will iterate over no empty tiles to update, and you couple less entity data and spatial information, which will make your engine more flexible in the long run.
Also, don't use quadtrees to store the actual entity data. While it could be a good idea to build a quadtree from the entity data in order to check for collisions, it should be a "second class game engine structure", and not an actual data storage for all your game entities. Iterating over an entire array, which is what you will do in EVERY logic frame, is still cheaper than iterating over every node of any tree you can imagine.
>>974563
Don't do this. I know coupling logic and rendering in the same loop over the entity array looks like the logical thing to do, since you only iterate the array once, but it will fuck you over later on. You want to keep them separate to be able to update and/OR render (say, you want to pause the game, but still move around, like a camera mode). Iterate twice if it's needed, and you will maybe even benefit morr from code cache.