That's right, I didn't think about collision detection enough when I tried to implement the level loader code. The level file format specifications are ready and I've already written code to load it, but the question is: where to store this loaded data?
I need to split up the sprite lists. Inserting new sprites while ordering them on their Z value (so they are rendered in good order) is nice, but not when the list contains 10.000+ items… Besides creating a second list that contains the static sprites, I think it's also a good idea to use a quad-tree instead for faster rendering. And that's what got me thinking: how about the collision stuff? Do I want to put that in the game logic code? How would entities use the collision system – do they need to know things beforehand, or afterwards, or consistently… and so on?
For now, I've decided to create a new 'module' for the collision handling, that behaves much like the rendering module: entities can register an instance, update it, and request collision checks. A quad-tree for the static items, and a list for the dynamic items sounds like a fair solution, too.
With this approach, the entity system doesn't get cluttered with collision-specific code, and non-physical entities do not clutter the collision system. I hope…
And that all because of quad-trees… :)