collision detection implemented

[bseto]

pretty cool! We will iron out the details for optimized collision detection later. Just curious though, atm, all the monsters/enemies are checking themselves against other monster/enemies too?

[enochtsang]

Yea, I think for flexibility we will want to be checking against everything. I think it'll be complicated to not do it this way as well due to types and stuff in c++, let me know if you can think of a simple way for some game objects to only check against some game objects.

As much as it is an optimization, I think once we have block maps implemented there'll be minimal performance gain, in fact I wouldn't be surprised if it was slower due to caching.

[bseto]

game objects will have a "type" to them as a member variable, and then you call the member function like... object.type() and it will return its type and you can seperate them into two arrays, bullets and enemies. So already, instead of (B+E)^2, its B*E. Where B = bullets, E = enemies,

And after this, we could further optimize using block maps.

EDIT: I think these are potential candidates too. http://stackoverflow.com/questions/8084525/collision-detection-with-many-objects

quad tree's (Another comment stated that octree's are usually for 3D, quad for 2D) https://en.wikipedia.org/wiki/Quadtree BSP-tree's https://en.wikipedia.org/wiki/Binary_space_partitioning kd-tree's https://en.wikipedia.org/wiki/K-d_tree

[enochtsang]

I think blockmaps better suits our purpose than quad trees. I think quad trees work better when there are many stationary parts, so the tree doesn't have to shift around as much. Blockmaps is also easier to visualize and therefore program I think.

Also with the object.type() implementation you described, I don't think it scales because an object's type and it's subtype may both be important, and in that case, what would be it's type? I like the idea overall, but we need a way to make it scale.

The reason I was saying there would be minimal optimization with separating what checks what with block maps is because there will be minimal checking in the first place. With sufficiently small blocks, the values of B and E in your example would be very low so (B+E)^2 and B*E would not have much of a difference anyways.

[bseto]

Well to my knowledge, there's only going to be bullets, and enemies. Their subclasses won't matter to the universe in terms of collisions. That being said, I think the separating bullets from enemies might not be too large in effect in this game (Because there won't be hundreds of enemies and hundreds of bullets at a time), however, if this was an actual bullet hell game, I'd definitely suggest applying both optimizations.

So ya, I guess for now it'd be okay to not separate it, however in the future if things do change, I don't understand the problem with its type. We could make make a member variable of main types, stating bullet or enemies, and then have a list/array of subtypes if you really want scalability.

If bullets had special attributes to them against different enemies, say water bullet against fire enemy. You would first need to check their main attributes to see if they even interact, Bullet on Enemy, after you notice the collision, then you can call a function from the bullet to see if it applies a special effect or not by comparing their sub-types. I think it scales well and its a scalable optimization.

[enochtsang]

This is a good talk, we should leave this conversation outside of this pull request though. If you think the changes in this commit are good, merge the pull request. We'll talk more about these topics when we see each other in person :)

[bseto]

Sounds good. Merging pull request.