2 ms·
I've been working on my own ECS system and can say that you're not wrong, most of it is indeed a data problem (and going past DB into just memory allocation and
by animal531 2y ago
I've been working on my own ECS system and can say that you're not wrong, most of it is indeed a data problem (and going past DB into just memory allocation and management). Games in truth don't even have that much data, for example you might have 1-2k entities, obstacles etc.
However unfortunately I haven't found any existing DB type solutions that work for the gaming use case, even when looking at in-memory only solutions. Real world business solutions have two major constraints, a) Do a bit of work as fast as possible and b) Do a lot of those bits as fast as possible. They have additional 'pros' where you can always potentially add more hardware to any problem to achieve that throughput.
Gaming uses both of those as well but for the second case it comes at it from c) Always obey the framerate. For 60fps you have 16ms to do everything and of that you might have only 8ms available for code. Even so that might seem a lot, you could for example do 10 billion adds in that time. But throw in a few loops, conditionals and suddenly it means that for a few thousand entities you can do almost no data transformation, copying etc. Everything needs to be in place and ready to access as is.
Existing DB's are about storing data and delivering it, what we need instead is a dynamic memory manager that can move your data around in memory as needed so that elements that are currently being processed together have some advantageous layout and/or are grouped correctly for some process.