Shmup engine bullet collision question

[laxa88]

Hi everyone, I am new here. My name's LWY although my username says laxa88. I'm working on a shmup on Unity 2d engine and have been making good progress with the mechanics so far... except one problem that's been bugging me -- collision detection.

In normal cases I used Unity's BoxCollider2D components to detect collisions between the bullet and everything else (enemies and players), but I noticed that if the bullets are too fast (as most player's bullets are), occasionally the bullets just pass through the enemies. I could, of course, make their hitbox bigger, but that doesn't guarantee collisions will occur between a bullet and smaller enemies (think popcorn ones).

I tried Raycast2D but somehow it wasn't reliable enough either. I don't know what I'm doing wrong -- so I'm turning to the forums here hoping if anybody has gone through the same problem as I had. If it's been discussed before then I appreciate if you could link me to the thread; I tried using the search button but the results weren't what I had in mind.

Thanks in advance!

[mice]

You could elongate the hit box in the movement axis by the speed of the object, if you now what I mean. Both for bullets and enemies.
But, personally, I wouldn't design an enemy going so fast or a main bullet being so small that this should be an issue.

[ptoing]

For bullets to be able move over enemies you would need the enemies to have pretty small hitboxes as well, same goes for the bullets. In DDP for example the playershot of the red ship at the lowest powerup level moves 16 pixels per frames, which is pretty fast. But that means that you would need an enemy that has a hitbox which is smaller than 16 pixels and/or moving really really fast for it not to be hit. Just make the hitboxes of your enemies big enough, and same for the player bullets and you should be fine.

Or alternatively you could look into sweeping collision checks. Which actually makes sense if you have enemy bullets with small hitboxes and also a small player hitbox.

[laxa88]

For bullets to be able move over enemies you would need the enemies to have pretty small hitboxes as well, same goes for the bullets. In DDP for example the playershot of the red ship at the lowest powerup level moves 16 pixels per frames, which is pretty fast. But that means that you would need an enemy that has a hitbox which is smaller than 16 pixels and/or moving really really fast for it not to be hit. Just make the hitboxes of your enemies big enough, and same for the player bullets and you should be fine.

Or alternatively you could look into sweeping collision checks. Which actually makes sense if you have enemy bullets with small hitboxes and also a small player hitbox.

I didn't think about it that way, makes sense. I'll skip the sweeping collision check for now -- I think it's way above my skill level at the moment. Thanks for the info!

You could elongate the hit box in the movement axis by the speed of the object, if you now what I mean. Both for bullets and enemies.
But, personally, I wouldn't design an enemy going so fast or a main bullet being so small that this should be an issue.

After thinking about it, combined with what ptoing said, I'll use your suggestion. And you're right; the enemy and/or bullet shouldn't be too small -- I was viewing the scene from far, thus it looked like the bullets were moving too slowly. Now that I zoomed in the right size and slowed things down, the collisions seem to be working consistently!

Thanks a lot guys! I hope I can show a demo of the game I'm working on sometime in the future.

[n0rtygames]

Unity is weird. I don't like using its built in collision detection and would roll my own (have done in the past)

I set up collision grids and check nearby grid squares for possible collisions. I then do distance checks based on arbitrary sizes.

That aside, if bullets are passing through you need to think about your design and ask - is it too fast?

Google for unity dontgothroughthings.cs which is useful for fast moving physics objects. See how it works and consider it's uses for you in a 2d environment

[laxa88]

n0rty, thanks for mentioning collision grids. I didn't know what it was, so I went and googled it -- these articles turned up, which I think are a good read (if there's anyone out there who's as oblivious as I am):

http://www.metanetsoftware.com/technique/tutorialA.html
http://www.metanetsoftware.com/technique/tutorialB.html

And yes, I rethought my design -- my bullets were indeed too fast. Thanks for recommending dontgothroughthings.cs, I've found it and have included it in my project to be used. Very helpful!

Edit:
Sharing more links I found on the same topic, in case people stumble across this next time:
http://gamedev.stackexchange.com/questi ... form-grids
http://gamedev.stackexchange.com/questi ... 9932#39932
http://gamedev.stackexchange.com/questi ... 8893#38893

[mice]

dontgothroughthings.cs

rofl. Best class name ever.

[Formless God]

grids

This has been bugging me for a while. If I understand this correctly, you split the screen into a number of cells, each cell having a list of objects. Every frame, you wipe all the lists and repopulate them by going through every collidable objects and calculating which cell(s) they're in. After that just do your collision check on the cell of interest's list of objects.

Well, how do you put an object into a cell without generating garbage?

[mice]

Well, how do you put an object into a cell without generating garbage?

Each bullet could have linked list capabilities or the object list could be a pool of bullet-references.

Code: Select all

...
// Linked list pseudo example needs two "arrays" firstBullet[NUM_CELLS_IN_ROW][NUM_CELLS_IN_COLUMN] and lastBullet[NUM_CELLS_IN_ROW][NUM_CELLS_IN_COLUMN], for instance
// start of frame
clearAllCells(); // sets all the cells in both "arrays" to the same nullObject

// calc grid cell and link
for each bullet{
 cellX = bullet.position.x / NUM_CELLS_IN_ROW;
 cellY = bullet.position.y / NUM_CELLS_IN_COLUMN;
 Bullet bullet = getLastBulletInCell(cellX, cellY);
 bullet.setChild(bullet);
 setLastBulletInCell(cellX, cellY, bullet);
}

...
class Bullet method setChild(Bullet bullet){
 this.nextBullet = bullet;
 bullet.nextBullet = END_OF_LIST_MARKER_OBJECT;
}

Or something like that.

[pieslice]

You might want to do a crude box-box collision to exclude bullets too far away from player and then raycast bullet's trajectory against player's hitbox. It shouldn't be too cpu-intensive as you are testing against only one box collider. Use unity's layer system to make raycasts to collide only on player's hitbox

[laxa88]

Just thought I'd note: The dontgothroughthings.cs doesn't work with rigidbody2D or collider2D, so i'll have to tweak the code a little. The issue here is the 2d counterpart of the rigidbody/colliders do not have the attributes that the 3d ones have, hmmm...

@mice i tried to make sense out of your pseudocode but I couldn't figure it out. I'm guessing you just quickly wrote some stuff off the top of your head to explain the concept of grid collision, which I still have trouble understanding at the moment. I mean, I get the idea of "checking for which objects are in which larger cell so the empty cells don't have to check for collision". I'm just finding it tough to literally write the code. I don't "see the light" yet. Will rely on the default unity colliders for now. When I complete the game, I'll work on improving the collision detection

[mice]

When I complete the game, I'll work on improving the collision detection

Yes, there's no need to optimize something that isn't an issue, yet.

[n0rtygames]

Most of this stuff wont be an issue when you're throwing a modern i7 at the problem with a 3d accelerator card though.

A decade old console though? Yeah, that's probably gonna give you issues.

How much you optimize at this stage really depends on where you plan to deploy the game. If it's PC - you can be inefficient (prepare for angry stares) and get away with it.

Depends what you want out of it. Do you want to just make a game or learn something a little deeper. You gotta answer that I guess

[BPzeBanshee]

If it's PC - you can be inefficient (prepare for angry stares) and get away with it.

[Stilghar]

Bit of advice. Throw away Unity's new Physics 2D and use the 3D Physics even if you are working with sprites. The new Physics 2D in Unity is at this moment still very much in development and full of bugs. Another option is to roll your own collision detection as they advised you. In our case with Unity Physics (3D) we are not having any issues, even with fast bullets.

[n0rtygames]

Bit of advice. Throw away Unity's new Physics 2D and use the 3D Physics even if you are working with sprites. The new Physics 2D in Unity is at this moment still very much in development and full of bugs. Another option is to roll your own collision detection as they advised you. In our case with Unity Physics (3D) we are not having any issues, even with fast bullets.

Agree 100% as I said previously with :

Unity is weird. I don't like using its built in collision detection and would roll my own (have done in the past)

I don't do this for complicated 3D games (i.e first person) though where the twitchy arcade playstyle is less prevailent. But for the case of a shmup? I think it would be beneficial to just roll your own stuff

[nasty_wolverine]

http://cokane.com/shmupdevarchive/index ... pic=1635.0
http://cokane.com/shmupdevarchive/index ... pic=1636.0
http://www.cs.ucf.edu/~jmesit/publicati ... 202005.pdf

how cave does it:
http://shmups.system11.org/viewtopic.ph ... 93#p673393

those should help, I built my collision engine based on those.
essentially the play field is divided into 4x4 grid, in which only collidable objects get registered to, and each object has a callback for each type of other object it can collide with. adding new collision types is just adding a new callback.

also, if the player should get hit and doesnt, its a good thing, watch some fancy ketsui dodging if u think i am wrong. but if the player gets hit when he shouldnt have, BIG NO NO. collision doesnt have to be 100% accurate, but it has to be fair.

[laxa88]

@Stilghar @n0rtygames
This is my first game and I'm trying to finish a prototype as fast as I can, so I'm using whatever's in Unity for now (as long as it works, even if not that well). But of course, I'd love to roll out my own collision detection logic when I'm more experienced!

At the moment I don't use any 3d physics components. I only have Rigidbody2D (for players, enemies, walls), BoxCollider2D (enemy and wall hitbox), and CircleCollider2D (for bullets and player hitbox).

@nasty_wolverine
Thank you so much for the links! The reverse engineering thread looks interesting, I'll read up on it in a bit. And I'll keep your advice regarding player lenience on getting hit. Thanks!

[Stilghar]

At the moment I don't use any 3d physics components. I only have Rigidbody2D (for players, enemies, walls), BoxCollider2D (enemy and wall hitbox), and CircleCollider2D (for bullets and player hitbox).

That's what I'm saying I would not use those if I were you. You can easily replace them by Rigidbody, BoxCollider, and CircleCollider that are also part of Unity. And then just replace your OnTriggerXXX2D or OnColliderXXX2D functions to OnTriggerXXX and OnColliderXXX. That's what I was meaning when I recommended you to move from Unity 2D physics components to the 3D ones (that have been tested for a long time).

Just an example of current bugs in Unity 2D physics. OnTriggerStay2D sometimes only fires once while OnTriggerEnter2D sometimes behaves like OnTriggerStay2D!

[laxa88]

Oh, the "bug" you mentioned isn't really an issue for me. Collider2D components must always be included with Rigidbody2D, or else it'll behave as you say (OnTriggerEnter2D triggering as if it's OnTriggerStay2D). So far I haven't encountered any other game-breaking bug for the collider2D's.

If I happen to face any weird bugs with the Collider2D for my current project, I'll try switching to the 3D colliders.

[mogumbo]

Sounds like you might already have this problem sorted out, but here is my two cents anyway. I had the same problem in my own game, though I wasn't using Unity. I saw it mainly when an enemy was traveling toward an oncoming bullet. Sometimes the bullet's collision segment would be in front of the enemy the first frame and then basically swap positions with the enemy on the second frame. No hit.

To solve it, I simply add the enemy displacement to the starting point of the bullet collision segment. After that, I have never seen a missed shot. I don't know if Unity gives you enough control to do this, but it works great if you can.