Is there a method to have hit box detection with any other box?

[enigma22133]

I'm using: if(PLHitBox[ i ].intersects(e1HitBox[f])) in one of my loops. It seems kind of tedious that I will have to set up hit detection for every single enemy with the lasers.

I tried PLHitBox[ i ].intersects(); but that doesn't work. It seems like this is going to become a real problem when I get to the point where I am needing walls/objects to prevent movement.

Does anyone know of a way to generically write "if any intersects detected, then do this"?

[eXpl0it3r]

Collision detection is a quite a big topic and there are many different ways to do it and since programming has nothing to do with magic, the answer is unfortunately no.

Can you be more specific on what you actually want to do? What kind of objects you have etc.

[zsbzsb]

It seems kind of tedious that I will have to set up hit detection for every single enemy with the lasers.

Why is it tedious? Once you have the code in place any new enemies should "just work" with your collision detection code.

[enigma22133]

-eXpl0it3r: I will try to elaborate on this in as few words as possible. Say I have 10 enemy space ship variants to fight. A blue one, yellow one, red one, etc. I set them up such as enemyblue[30]. That way i can make multiple renders of the blue ship sprite if I need to. The ships need to be able to fight so I set up lasers for them. Then say I do the same 10 variants for ally ships. since the hitbox detection requires that I compare two boxes (opposed to how I would like it to check for any boxes) I have to write for loops for
player vs enemyblue[]
player vs enemyyellow[]
...
...

then allyblue[] vs enemyblue[]
        allyblue[] vs enemyyellow[]
...

As you can see, the amount of loops I will have to code will grow exponentially with the amount of player/enemy/ally variants I create. I think a solution to this would be to allow an entities hitbox to be checked for intersections with any other hit boxes, rather than specific hitboxes.

This very well may not be possible, but I figured I would try to inquire if there was a way to do this with SFML. The abstract way I imagine this would work would be say: grid 1,1 contains hitboxes a,b,c. Then The program is told to check for hitbox intersections for the hitbox "a", which is located at 1,1,  it would see that b,c, also occupy that grid spot and sends back 2 collision data.

Thanks for any help, I'm a new to programming and everything I know if self taught. So sorry for unintentional ambiguity. 




-zsbzsb: My plan was to have many different types of enemies (right now, probably a few hundred). I'd set up it up something like thing enemy1[30],enemy2[30] ene.... ...enemy100[30]. (I figure 30 is the max of any enemy I would draw on screen).

Now, say I do the same for an ally variant (ally1[30]...). It seems to me that, I would have to program player laser detection against enemy 1, 2, 3..., Then ally 1 laser detection against enemy 1,2,3,4 and then ally 2 against all possible enemies. Then I would have to program each variant of enemy's laser hit detection against the player and all all ally variants.

I'm not statistician, but i think that would be an exponential number of for loops to write. It seems like there has to be an easier way, which I thought might be in the ability to detect any intersections of hitboxes, not just checking for two specific hitboxes. But maybe I'm just wishfully thinking.

 

[zsbzsb]

You are really over complicating your code by making an array for different colors/variations. You should instead setup a enemy class that contains the properties of each enemy. The properties can then determine the colors/variations of your enemies. Then all you need is one list of your enemies.

Also you should avoid using arrays and instead use STL containers like std::vector<T>. I also suggest if you can afford it that you should pickup a good C++ book and/or the SFML Game Development book.

[enigma22133]

Yeah I plan on picking up I plan on getting  SFML Game Development book, but I don't have the free time at the moment with my university (non-computer science major). I figured doing this was more productive than going to reddit lol. Thanks for your input, once I graduate and get a bit more free time I plan on getting more serious about learning.

I think I understand what you are saying though. I have a C++ book, which I am told is a terrible book, but I haven't gotten to vectors yet. I'm guessing they work similar to arrays, but are less resource intensive? In terms of arrays, I would set up enemy[10][30], and then could use one loop, with a loop inside to check for hitbox intersections against all 10 variants.

for(int k=0; k<10;k++){
    for(int j=0; j<30;j++{
         if(EnemyHitBox[k][j].intersects(PlayerLaserHitBox)){
             //do something
                              }

           }
     }

[Ixrec]

The main difference between std::array and std::vector is that std::array has a fixed size that cannot be changed, but std::vector can change size at any time (and like every other STL container, it takes care of the annoying implementation details like reallocating the memory).  The difference between an ordinary array and std::array is that the latter has the same rich object-oriented interface as any other STL container.

tl;dr if you know exactly how many enemies you're going to have in advance, an array or std::array is fine.  If the number is going to change, you're always better off using std::vector.

If the ordering of the enemies matters, there are more complex STL containers which provide those features.  I'm assuming it doesn't.

[Nexus]

std::vector is the default choice when you need a dynamic container -- simply because it performs best in most cases. Other STL containers such as std::deque or std::list are useful if you have specific requirements.

In modern C++, there is no reason to use plain arrays anymore. std::array is superior in every aspect.

And I would avoid 2D containers unless they bring you a real advantage; you can simply use a 1D container and map the indices correspondingly. This simplifies a lot of operations such as iterating over all objects.