I want to make this lighter and remove the rendering-specific code so that it can be used in tests, etc.
I also want to make it completely represent the game world -- at least insofar as it will contain everything on the current map.
It should have:
tile map
entities as... a vector? quadtree? what? Well, it can't be just a quadtree, because I still need a structure to iterate over to build the quadtree in the first place. So I guess let's use a vector as a base. Then perhaps I'll write some tests to see at what point the quad tree starts beating the vector in performance. Another possibility is the spatial hashmap, which is far simpler to implement and can be a self-contained data structure. I can just implement the quadtree query interface on the map to simulate the quadtree, and I bet the performance difference will be negligible.
objects? Well, see, this is where I start thinking that maybe I should treat everything as an object, because special handling for three different kinds of things sounds like it'd suck, and we start running into the whole reason that ECSes were invented in the first place, which is that you're often going to wish you had multiple inheritance. It's easy to split off tiles because there's 16000 of them in a 160x100 map and they just sit there and don't do a whole lot. Splitting entities and objects is more controversial. Yeah, I think I should keep them together. So no.
I want to make this lighter and remove the rendering-specific code so that it can be used in tests, etc.
I also want to make it completely represent the game world -- at least insofar as it will contain everything on the current map.
It should have:
Welp, let's see how this goes.