Hitbox question

[RotateMe]

Just a short question for I'm encountering this "problem" while making my own shmup. My intentional approach was to calculate the distance between bullets and ship "hit-spot" and if it's too close (depending on the bullets hitobox) the ship will explode... Then I realized that this would be a circular hitbox instead of a rectangular (square) box as it seems it always is used. Is it true that there are mostly square hitboxes (it's called box at least ) and if yes, is there any advantage to have a square box?

It might not be this much of a difference as it's just about 4 super-small edges of some super small box but there might come up some other interesting stuff about hitboxes so I just got ahead to ask this.

Thanks in advance

[ill6]

I presume they are (or were) square because they used pixels and not vectors. It would be easier to detect collision against a box (4 x,y points) then it would to detect against a circle (or using distance). Of course if you are using vectors (i.e. a 3d / pseudo 2d game) then a circle makes more sense (and I would imagine a lot of modern games do just that).

[Arvandor]

ESPGALUDA depicts the hitbox as circular as you start the game. And in some of the Touhou games, when you're doing slow fire, your hitbox appears; it's circular here as well. Many other newer games probably do indeed use circular hitboxes.

[raiden]

you can make the hitbox rectangular by first comparing x-coordinates and only if the are within, checking y-coordinates as well. That´s also quicker than doing a distance calculation, which might not be much for one bullet, but when you have a few hundred of them on screen, it might even get noticeable.

[RotateMe]

Yeah thats an argument... btw here's info about the game http://www.shmup-dev.com/forum/index.php?topic=879.0

Dunno if I'll be able to finish the game though.

[ReKleSS]

What's wrong with a round hitbox? Square hitboxes are common because, as was said before, it's defined by pixels, and because hit detection may be cheaper (1-4 compares vs 2 subtracts, 2 multiplies and a compare). If you're not working at low resolutions it probably won't make a much of a difference to the player either way.

[msm]

there is a mode in radiant silvergun where it shows you all the hit boxes, i thought it was interesting that they are all square/rectangular and stay in the same orientation.

[Pixel_Outlaw]

I would use a point_distance(x1,y1,x2,y2) type command. I think 2x2 hitboxes are best or perhaps 4x4. In manic/danmaku/bullethell shmups the outside shape doesn;t matter anyways. If you use a rectangular box shots from angles will actually hit sooner than shots in 90 degree directions from the ship. When you playing a game you want to have all directions equally susceptable to collisions. So if you plan to be moving all around the screen use a circular one.

[RotateMe]

Thx for your comments, I think I'll keep my circular hitbox for it doesn't seem to be such a great difference (or even has some advantages).

What do you think of the screenshots and do you think a system where espgaluda-like slowdown and progear-like jeweling are combined would work?

[Twiddle]

I'd say try to make your own scoring system

[RotateMe]

That's what the "like"s were trying to say

[Pirate1019]

Since it seems he is making this in a competition and under a time constraint, I think that just taking from another games scoring system is fine. It would be cool if he released another version of the game with an original scoring system after he's done though.

[Icarus]

Can you not run a check for sprite overlap? Something like setting an "invisible" sprite as the hitbox and seeing if anything hostile overlaps it, and if it does, blast the player craft into billions of shrapnel?

Just a thought.
(You can do it in Macromedia Flash, and Flash isn't anywhere near as advanced as most prog languages.)

[RotateMe]

Yeah it's of course possible. If the sprite is very small it shouldn't need that much system resources but it would take a lot more than just a distance check though.

Since it seems he is making this in a competition and under a time constraint, I think that just taking from another games scoring system is fine. It would be cool if he released another version of the game with an original scoring system after he's done though.

I will try to make it original and it's not really taken from the games it's just to explain how it works. I think slowdown and bullet cancelling are pretty basic ideas, though I have to admit the jeweling is just something I want to steal away from cave it's just such a great eye-candy.

[Pirate1019]

billions of shrapnel?

Sounds almost like Engrish! .

Anyway. I am sure you can do a check like that. It's how a 'game' that came as a demo program for TrueBasic in our Comp. Science class checked to see if you hit another object with your Tank's gun. If TrueBasic can do it then Blitzmax had better be able to do it while hundreds of bullets are flying around the screen.

[Icarus]

Yeah it's of course possible. If the sprite is very small it shouldn't need that much system resources but it would take a lot more than just a distance check though.

I'm not so sure. The way I see it is that you're just checking to see if something is overlapping your hitbox sprite. Considering that virtually everything that isn't your ship/shop shots, a powerup, and background/HUD is hostile, it should be somewhat easy to write a routine or two to check - something like:

Code: Select all

if(objType == "hostile" && objOverlap == true) {
    playerGoesBang;
} else {
    playerIsALuckyBastard;
}

Something to that effect. ^_-

[RotateMe]

The checking for overlapping graphics is what takes much resources. But now that you mention it there's a possibility to use a collision map where every bullet is on and it would require just one collision check for all the bullets.

And what will the "playerIsALuckyBastard" command do? nice

[ReKleSS]

If you define both player and other crap hitboxes to be rectangular and axis-aligned, the test is cheaper than your circular hitbox style.

If you use that then go down to per-pixel detection for the overlapping sprites, it should still be fairly cheap cpu-wise. Don't underestimate the amount of processing you can get done in one frame.

Your suggestion of a collision map sounds workable, but kind of inefficient. Think whether anybody will notice if you go for some very precise collision detection, or just something coarse. Just make sure it's consistent.

[shiftace]

I don't see how a collision map can save any time. To use the map, you have to blank an array; iterate on the bullets/enemies; copy the hitbox images onto the collision map; and check if the player's sitting in a marked spot or not. In a more typical approach, you iterate on the bullets/enemies and check if they touch the player. Looks about the same to me, except that you have to clear the collision map every frame.

Another "common knowledge" thing to consider -- it's faster to compute squared distances than distances, so if you do round hitboxes, do it that way.

[RotateMe]

Yeah I'll just do a check for the square and if it's in the square do a distance check. There are nearly no bullets (statistical) that will be in the square hitbox so this is the fastest way to determine collisions with round hitboxes. Thanks for your help!