Questions about bullet hell optimizations: Movement and collision

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.
  • I'm making a bullet hell game, so there's going to be plenty of bullets on screen, but i start running into frame drops much earlier than your average shooter game.
    I control bullets by giving them Alterable Values for angle, speed, X and Y. Use cos sin functions to update the X and Y Alterable Values based on the angle and speed ones and the physical X and Y positions are rounds of the X and Y Alterables.
    For collisions i have the bullets spawn an active the shape of a square and have it deleted next frame.

    Is there any way to optimize any of this, i was thinking if testing distance between bullets and player for collisions instead of testing if the player's hitbox overlaps the bullet's hitbox would be more efficient.


  • For collisions i have the bullets spawn an active the shape of a square and have it deleted next frame.

    Do you mean every bullet on screen is creating a new object to test for collisions - then destroying it every single frame tick? That *could* be a reason for slowdown, but without seeing an MFA file (or profiling if you have Fusion 2.5) it's hard to say what's going on exactly.

    Instead of creating and destroying an object for every bullet, you could change the animation to the size of the hitbox you want, check for overlap, then revert it.

  • ^This

    Spawning an active at the sight of a bullet is going to result in effectively creating dozens of actives on every frame. Either follow the above advice, or have a pool of collision actives that you create at the start of a frame & reuse (frankly, you should do the bullets this way also if you aren't already). Creating & destroying actives is a quite heavy operation in Fusion, & especially if being done every frame.

    If you aren't doing this already, I'd also recommend to only check for overlap type collisions between "proximate" objects.

  • Creating objects can be relatively expensive when done a lot in a short space of time, so that's probably part of the problem. Marbenx's solution is worth trying. Or you could try just using the same square object that you're using now, but instead of creating and destroying it, you just create it once at start of frame, then move it onscreen and offscreen again. You could potentially reuse the same single detector object for every bullet. Just keep moving it to wherever you need to check collisions in that moment.

    Please login to see this link.
    My Fusion Tools: Please login to see this link. | Please login to see this link. | Please login to see this link.

  • Why do you use a separate object to text collision? Your bullet objects should be able to do by itself.
    If you have a collider, use one and move it around by linking it to the bullets fixed ID, its more efficient than creating new ones.
    You could also add a separate animation of the bullet with a frame of the collider detector, then in a fast loop, switch to it, check collision and switch back the animation.

    Please login to see this link.
    Please login to see this link.|Please login to see this link.|Please login to see this link.

  • Do you mean every bullet on screen is creating a new object to test for collisions - then destroying it every single frame tick? That *could* be a reason for slowdown, but without seeing an MFA file (or profiling if you have Fusion 2.5) it's hard to say what's going on exactly.

    Instead of creating and destroying an object for every bullet, you could change the animation to the size of the hitbox you want, check for overlap, then revert it.

    Upon some investigations, i found out some bullets stay for a while even when leaving the screen. How big is the auto-delete frame? Or maybe is there something that prevents it (Destroy object if far away from frame is checked)? It has behaviors applied to it, but it's just a single function to change the rotation of the sprite.

    The method you mentioned for collision test optimization sounds good, until i remember that i use animation frames to store different sprites for the bullets.
    Was thinking i should just make the bullets test how far away the player is and subtract player and bullet hitbox radius, if < 0 then get hit, this would have the benefit of circular hitboxes but idk the performance. I could only test bullets that are close to the player

  • Why do you use a separate object to text collision? Your bullet objects should be able to do by itself.
    If you have a collider, use one and move it around by linking it to the bullets fixed ID, its more efficient than creating new ones.
    You could also add a separate animation of the bullet with a frame of the collider detector, then in a fast loop, switch to it, check collision and switch back the animation.

    You've got a point, i can just move a single hitbox to each bullet, i didn't think of that.
    I don't test for collision with the actual bullet because that's pretty rough gameplay-wise

  • Upon some investigations, i found out some bullets stay for a while even when leaving the screen. How big is the auto-delete frame? Or maybe is there something that prevents it (Destroy object if far away from frame is checked)? It has behaviors applied to it, but it's just a single function to change the rotation of the sprite.

    How were you checking for out-of-window bullets? If you were just using "is out of play area" or some other event that just compares bullet coordinates, those conditions by themselves are only checked once per frame, so you could've been missing bullets that are moving faster than 1 pixel per frame & as a result avoid being detected as out of the frame for a while. You should remove bullets in a loop of some kind.

    I'm making a shoot em up too (not a bullet hell type shooter though), so I'm just interested how other developers of shooters go about it :)

  • How were you checking for out-of-window bullets? If you were just using "is out of play area" or some other event that just compares bullet coordinates, those conditions by themselves are only checked once per frame, so you could've been missing bullets that are moving faster than 1 pixel per frame & as a result avoid being detected as out of the frame for a while. You should remove bullets in a loop of some kind.

    I'm making a shoot em up too (not a bullet hell type shooter though), so I'm just interested how other developers of shooters go about it :)

    Huh, i just leave them be because don't they get auto deleted by default? There's an option called 'Destroy object if far away from frame' in active's properties

  • Huh, i just leave them be because don't they get auto deleted by default? There's an option called 'Destroy object if far away from frame' in active's properties

    They should do, but as it's an application property, I have no idea how often it triggers or how exactly it gets "deleted" (are actives with running behaviours all destroyed? etc..). I don't really understand how it works so I just set this to "no" & handle it myself.

  • They should do, but as it's an application property, I have no idea how often it triggers or how exactly it gets "deleted" (are actives with running behaviours all destroyed? etc..). I don't really understand how it works so I just set this to "no" & handle it myself.

    Thx, will implement it

  • bullet hell bullets are usually circles, right? not squares. a circle to rectangle check is really performance-friendly, since it is only a single distance check. you can easily have a few thousand of these with full framerate, no sweat. i made an example for you. make sure your player rectangle is cropped so there's no empty space, and manually set the collision radius of the bullets in their values.

  • if the bullets are small and the ship is big enough u can use a cheat i use where u hav a flag toggling on/off.
    wen flag is on run collision checks on all bullets above the middle centre point of the screen,
    & wen flag is off check all bullets below the middle center point of the screen

    the bullets will always be on the player for at least 2 frames before they pass, so u will catch it on one of the flag states

    this should straight up half the amount of collision u hav to do :D

  • if the bullets are small and the ship is big enough u can use a cheat i use where u hav a flag toggling on/off.
    wen flag is on run collision checks on all bullets above the middle centre point of the screen,
    & wen flag is off check all bullets below the middle center point of the screen

    the bullets will always be on the player for at least 2 frames before they pass, so u will catch it on one of the flag states

    this should straight up half the amount of collision u hav to do :D

    Why? You're effectively creating an un-necessary collision delay. Seems like bad practice . . .and if the combined speed of the player and bullets are great enough you have the potential to miss collisions all-together.

  • Why? You're effectively creating an un-necessary collision delay. Seems like bad practice . . .and if the combined speed of the player and bullets are great enough you have the potential to miss collisions all-together.

    i gave an optimization for if all other options have failed, if u are at the limit & struggling on lower end machines, then this trick can save your neck.
    no one will every notice 1 frame of delay at 60fps.
    and even in normal circumstances if the combined speed of the player and bullets are great enough you still have the potential to miss collisions all-together lol

    if the game is optimized enough to not need to use this method, then it's all good ;D

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!