Better ways to classify than a bunch of lists?

Performance Tuning
#1

I’ve got a game that has some pretty complicated collision algorithms and draw prioritizing (to make texture binding happen in a happier order), and as a result I ended up with 5 different lists that all do basically the same thing except they keep the groups organized for collision checks and drawing ordering. Can anyone think of any ways to make this a little bit better? This is basically what I’ve got:

EntityTypeA - Collides only with type A (and pathfinds only with A’s), also drawn in 3D mode so some OpenGL flags get set before drawing, not ordered.
EntityTypeB - Collides only with type B and does some other B-related logic, ordered by Y position (game is isometric).
Particles - All the particle effects go into this layer. They don’t collide with anything and are ordered by their texture id.
Emitters - All the particle emitters go here - they do absolutely nothing special except emit particles. They are not drawn, but can be attached to an Entity separately (which means they aren’t in this list).
LevelGrid - a 2D array, contains all the different spaces in the level, links to other spaces ( ex. (0,0) might not link to (1,0) if there is a wall), and some Object inside, could be null (if the space is empty) or any Entity (an inactive Entity goes into one of these spaces).

The question is if there is a better way to do this. I need to keep the groups discrete from one another but repeating the exact same for loop with 4 different lists is pretty annoying, and I am thinking of adding yet another list.

Ideas?

#2

Just put them in 5 classes and don’t expose the Lists themselves. Those classes are all doing more or less the same thing. Don’t abstract too much. You could put everything ‘behind’ an interface, but in the end you’ll probably be doing a lot of instanceof because you need one type to do a very specific thing.

If your code is for ‘internal use’ (within your engine)… it’s all about what you think is easiest.

I’d make TypeAManager, TypeBManager, ParticleManager, EmitterManager, LevelConnectivity.

Most important is (as said) not to expose your list, so that you can replace them with probably more efficient datastructures later on. If you want to be productive, don’t code it until you need it – don’t build an abstraction layer if you can manage it just fine with a quick and dirty solution – until it gets in the way.

#3

Yeah, I’m keeping the unexposed already (getEntityCount and getEntityAt(int) are basically how you get to them all), although potentially I should use Iterators instead. They’re all in different classes already, actually, I just figured that it would save a bit of processor if my (very commonly performed) task of comparing every entity of one type with another was limited to that one type and didn’t require any instanceof.