This week I have created classes to manage entities in our game “Flight of the Giraffa”, which is group 9’s project for Game Design II. Flight of the Giraffe is a 2D, side scrolling space shooter with a bullet-hell theme, where you play as a giraffe dodging bullets in space.
To manage every object appearing on screen, I have managers for every type of entity in our game. The manager will keep track of a certain type of entity and update it, draw it on the screen, and later destroy it when finished. Important functions like collision will also be checked in this class by testing one entity with every element stored in the manager.
I do collision checking using Separate Axis Theorem with two shape objects stored in a base class every entity inherits from. Right now it can only check for overlap between two convex polygons but collision with circles will be implemented.
By keeping every entity type separate, collision check is much more efficient. When having every entity type stored in a single manager the collision will be troublesome because when I want to check collision between every player bullet and every enemy, I’d have to iterate through the whole list again and bypass every entity that is not an enemy. Another problem would be when I want to check collision between the player and a power up and the manager contains another 1000 elements of enemy bullet. Then the program have to iterate a 1000 times more instead of only one.
Later I will give each entity manager its own vertex array and run it through a shader program. With this shader I can tint sprites or make them glow if that would be necessary.
In Flight of the Giraffa, there is a power up that clears the screen on enemy bullets. This feature is a 100 timer easier when having a separate list for enemy projectiles.
My first attempt for a separate entity manager was to use a generic class using templates. This manager does not depend on the data type and only focuses on storing, updating, and drawing elements in a vector array. The problem with this approach that every entity have different needs and behaviors, and most problems occurred in the realm of collision detection.
Most of the problems using a generic manager could be solved by using a more complex structure. But I see no reason to over complicate my code when everything works just fine with multiple entity managers.
adladclxvi 
Having all ‘entities’ in a single vector was the mistake we did at first for the reasons you explained, things got way simpler to keep track of when we separated everything to its own manager classes. It’s guaranteed to be pretty damn faster as well, like you said. I hope this post somebody the trouble of throwing everything in a single generic manager. 🙂
But why would you use SAT for collision checks? Unless you’re doing something whacky with the gamespace or really need some precise collision for bosses or something. Even then you probably could get away with using AABB and multiple collision boxes for a single entity. In our game we simply use Circle-circle collision due to the fact we’re rotating entities like crazy and if we were using AABB the edges of the boxes would cause the collision to feel pretty off. My point is, why use some complicated collision checks if there’s no real use of them? And even then most bullet-hell shooters I’ve played only have a tiny circle as a collision box for the player that is a lot smaller than the actual sprite.
Also, an image would be nice. Even now when there’s little to show due to making a bunch of classes that are managing stuff are all behind the scenes. Maybe an image/gif of a bunch of bullets flying around, to show off how much more efficient the new structure is?
Anyway, nice post!
GillaGilla