Help with effective way to calculate and do effective shooting and hit mechanic on enemies?

I have done several games but actually never a game where you shoot "bullets" at enemies and need to have an effective way to check if an enemy is hit etc. I feel quite clueless as to what is the best method for this or how to go about it.

The first problem is actually how to shoot the actual "bullet" toward the enemy, I am reusing the example I made for the circle aiming behavior where you steer the aim with the left analog stick of the controller in a 360 movement around the player (this movement was actually better and more smooth with the SDL object but in this example I am using the regular xbox gamepad object since I don't think everyone have the SDL object installed)

I looked at another example that used angle and tried to implement that but it seems the aim that I have in my example does not actually have an angle even though it circulates around the player? In my example now the bullet just shoots straight up so it is an epic fail. So the first thing would be how to actually shoot the bullet in the angle toward the aim?

My next thinking though is what is the best method for actually handling the "hit check" on enemies? Is the regular "is bullet overlapping enemy" the way to go or is that really primitive and there are better and more performance friendly ways to do it? The main reason I am asking is that I am making a game where there will be tons of enemies (perhaps in the 100s if possible) so checking overlapps for multiple bullets fired and active on every object and obstacles on every frame might be very performance heavy and the wrong way to go? Also the bullets in my game is planned to go incredible fast (pretty much instant like in real life) so not sure that would also be an issue. Perhaps there are other methods that are better for this sort of thing like drawing a line somehow that calculate a hit when you fire and the line overlaps an enemy? The problem then though also is that if it is a line that goes straight over the frame it should still not hit the enemy if he is behind cover. I am a bit at a loss as to what direction is the best to go with this sort of thing?

Quote from Phi

Collisions are better, and the runtime will check it in an optimised way for ya. Overlaps are far less efficient, and don't select the matching objects anyway, so you have to for-each loop > is overlap...

The formula you're looking for in 360 shooting for x y coord to another xy is ATan2(). That will give you an angle. Then, normally, to move an object with a 360 angle, you get x speed and y speed, which you store in alt values because alt values allow decimal places.; then you set a new x y, which you store in alts, then set real x y to those.

X Y speed are calculated with sin and cos, I think.

Nivram has some examples of 360 movement/shooting on Please login to see this link..

Thanks for the examples! I have actually been wondering about collisions vs overlaps and what is best to use. I have normally used overlap events (but just fire them once by checking with a flag on the enemy that is off and sets on if detecting an overlap) but are collisions much faster then still? Is the downside with collision events not scoping since the collision condition have to be at the top of the event?

Say for example you have 100 enemies in a game and the player is in the middle. Would it not be more efficient when firing a bullet to the right of the player to then be able to scope to only check overlap if the enemy is position with an X position that is greater than the player and using a flag? That would reduce the amount of checks to half if half the enemies are located to the right side of the player since there is no need to check the ones on the left since the bullet is traveling right?

So the condition would be something like:

If enemy flag "hit" is off and enemy x position is greater than player x and bullet overlaps - > Then register hit and turn "hit" flag on

But if using just a collision check you can't do any of that scoping so it would always check collision of all enemies no matter their position?

Quote from danjo

re this; you still could draw a line, but do it using a fast loop, and draw it pixel by pixel using the angle method (sin/cos) and when the draw loop part for the pixel for the line hits an obstacle - stop the loop. so effectively you draw a line until it hits a wall or something

That sounds like an interesting and solid idea, I wonder if this would be as performance friendly as just "shooting a bullet" though or if it would be much more heavy?

Quote from Linky

It seems like you need bullets that can handle high speeds while still having collisions detected, and as they are bullets, you may have a lot of them at once so you probably need them fast performance wise..
You can go for rays, but considering it's for bitmap collisions that may be overkill for bullets, way too much performance overhead than it's worth, it would be more suitable for lasers and such

......

I actually made an custom 360 bouncing ball movement with DeltaTime support and even Quality checks (step checks) meaning with higher quality values, the less likely collisions will be missed in case of higher speeds in the cost of worse performance (Quality value 1 is fine for most cases really)
I posted the example on Click Converse discord server, Steam Workshop and Clickstore, but will post it here too for faster access:

Custom Bouncing Ball Movement Features:

• Custom 360 Bouncing Ball Movement
• Can be easily adapted into a widget, just drop the "Balls" group inside a behavior or global events
• Collisions easily checked with one event, can be placed anywhere
• Works with multiple objects
• Easy spawning by just creating the object
• DeltaTime support
• Step Checks support (and dynamic steps via deltatime)
• Bonus "shooters", each one shoots a customizable amount of object with a customizable margin between each one
• All runtimes compatible

Please login to see this picture.

Files:

• Please login to see this attachment.
• Please login to see this attachment.

......

And as I just mentioned above, you can go for rays, but I think that should only be reserved for actual rays like lasers, but if really needed, maybe check how I implemented the rays in this custom 3D raycasting engine (Minor note: I made that example before I obtained 2.5 PLUS DLC, meaning I didn't utilize child events nor any other 2.5+ DLC features, so performance can be better if a simple modification is done)

Custom 3D Raycasting Engine Features:

• DeltaTme support
• First Person Movement Widget (Works with multiple instances)
• Raycasting Engine (Works with multiple instances)
• Customizable properties, (with debug sliders and checkboxes)
• Use Actives or Surface to draw the scene

Please login to see this picture.

File: Please login to see this attachment.

Display More

Thank you I will check these examples out! I am thinking that bullets might not be optimal because I need them to travel almost instantly from the player to the enemy, but perhaps it is feasable

Quote from Phi

Collisions are better, and the runtime will check it in an optimised way for ya. Overlaps are far less efficient, and don't select the matching objects anyway, so you have to for-each loop > is overlap...

Wow you seem to be correct and I had no idea about this since I have always used overlaps instead of collisions since they seemed to me much more flexible being able to check other conditions above it etc. I tried to run an experiment with a modified example of an object spewing out bullets every frame and then having 1000 "enemies" that check for collision or overlap with the bullet. If running the frame for 3 seconds according to the profiler the collision event takes 0.231ms (0.39%) and the overlap event 54.592ms (92.92%)!!. I assume no amount of scoping or other "tricks" can make up for that huge difference :O

Btw regarding the profiler, is it possible to see how performance heavy the whole 3 seconds are if wanting to compare that to another 3 seconds in another example with totally different events to see which version is fastest? I was first thinking to look at the total time in ms if that is the one to look for but that number varies vastly from one run to another?

Quote from Phi

Both the collisions and overlaps check for general coordinate zones overlapping, before they do pixel-by-pixel checks. Overlaps are considered more inefficient anyway.

If you're only checking one object and you have to do it within a loop, then overlap is the only option. End of the day, if something's slower, the CF2.5+ profiler should be able to show it.

I see thanks! I will try to stick to collision checks from now on!

I have made some progress on the shooting example and the bullet is now shooting out from the correct angle of the joystick and hitting enemies (with the collision check). In this example I have removed the controller input and replaced with mouse just for testing.

However I have one problem where I have set the bullet speed to 50 since I want really fast bullets, but that means the bullet seem to pass though object before checking for collisions sometimes since it is moving so fast. For example in the example if shooting toward the blue wall to the right with the enemy behind it the bullet actually passes through the wall and hits the enemy behind it. And if shooting at the ones above the bullet does not just hit the one in front but takes out two at once or sometimes even the one in the middle.

Is there a way to prevent this while at the same time preserving reasonable performance?

Quote from Linky

You have to implement step checks, you can also move the object in fastloop where it runs the same amount of pixels to pass and check for collisions on every iteration, but that would be too heavy for multiple bullets and very high speeds

The bouncing ball widget I linked above already handles them and should very fast performance wise.. (you can for example, set the velocity of the balls to a really high value but try setting the general quality value to something a bit higher than 1, like 3 or 4)

And in case you want rays (that are fast performance wise, step checks implementation), I also linked an example for that, just only check the rays part, not the rest of the raycasting engine (check the performance mfa one as it's the cleanest, see how rays were implemented there)

Thank you, I tried to do some loops instead to move the bullet(s) in iterations and that solved all the issues with the bullets and how they hit enemies or walls etc. I tried to set it up so that a loop is running 10 times and setting the bullet speed to 10 so the bullet(s) are effectively moving 100 pixels per frame so pretty much instant and they seem to collide flawlessly without any issues to what they are supposed to connect with or passing through walls etc. I made an example with 100 enemies and even when using rapid fire (right mouse button) to shoot bullets in every frame it seems extremely light and performance friendly if I understand the profiler right? If I run the frame for 3 sec with the profiler and rapid fire shooting bullets every frame with 100 enemies the loop event costs about 4 ms so that sounds extremely performance friendly if I understand correctly?

By contrast if running the Bouncing Ball mfa for 3 sec I get events that cost 950 ms and another with 500 ms.

Not sure if that is a fair comparison since maybe a lot of other stuff is also going on but if I am not misunderstanding something completely this example with running a loop 10 times to move the bullet(s) in iterations seems like an extremely efficient way to handle this?

As for the raycasting example I find that one a bit confusing

Please login to see this attachment.

Quote from Linky

Also after checking the example you posted, I noticed some problems

• It can only really handle 1 bullet at a time, no foreach loops were implemented (I know it works there, but actually, with more complex scenarios it might fail, and would introduce performance problems as well)
• While this is not exactly a problem, but a normal collision check won't make any difference compared to overlap when ran constantly (like when checked inside a loop), as it's not immediate anymore and just switches to overlap behavior, resulting in 0 performance gain compared to overlap checks, better use overlap checks when actually needing to check for collisions constanly (like your case)
• Intsead of: Projectile : Add Sin(Angle( "Projectile" ) + 180) * Bullet Speed( "Projectile" ) to Ypos no need to add the 180 to the angle, you can subtract from the position instead: Projectile : Subtract Sin(Angle( "Projectile" )) * Bullet Speed( "Projectile" ) to Ypos
• Utilize child events for faster performance, no need to check for the loop multiple times
• The loop is used a bit weirdly there, you run it 10 times, but inside the loop you move ball more than 1 pixel, meaning if the speed is 10 like you set, 10 * 10 means it's moving 100 pixels every frame (as the loop is ran every frame) but teleporation still skips 10 pixels because it moves the speed amount in the loop it self, I think you meant to run the loop speed amount of times and move the ball by 1 pixel inside the loop to not skip any pixel
  
  While your implementation is not completely wrong, and is actually similar to how step checks work, it's not quite the same..
  this is how you can implement step checks the "right" way:
  Please login to see this attachment.

And in case you need help with the bouncing ball example, I can try providing guidance if needed on how to use it (even though it should be pretty simple to use for the most part)

Thank you!

profiler records the total time, not per frame, if you want per frame, check the "Record slowest loops" option

- Recording 3 seconds in one example vs 3 seconds in another should still give me an estimate on how performance heavy one is vs another if I make two variants though and want to compare what method is the fastest?

It can only really handle 1 bullet at a time, no foreach loops were implemented (I know it works there, but actually, with more complex scenarios it might fail, and would introduce performance problems as well)

- I tried to make a version where there are 10 bullets shooting out in random directions for ever time you fire and it seems to work fine to me and hitting enemies etc unless I am missing something? Please login to see this attachment.

While this is not exactly a problem, but a normal collision check won't make any difference compared to overlap when ran constantly (like when checked inside a loop), as it's not immediate anymore and just switches to overlap behavior, resulting in 0 performance gain compared to overlap checks, better use overlap checks when actually needing to check for collisions constanly (like your case)

- Ah I see you are right, hmm there seemed to be such a huge performance boost to using regular collision so that is a bit of a bummer but I have changed to overlap in the loop instead since I see there is no difference

Intsead of: Projectile : Add Sin(Angle( "Projectile" ) + 180) * Bullet Speed( "Projectile" ) to Ypos no need to add the 180 to the angle, you can subtract from the position instead: Projectile : Subtract Sin(Angle( "Projectile" )) * Bullet Speed( "Projectile" ) to Ypos

- Thank you I changed to this instead!

Utilize child events for faster performance, no need to check for the loop multiple times

- I tried to do some child events on the loops but I see no difference in the profiler when running it (unless I am doing it wrong, I have really never used child events before)

Please login to see this attachment.Please login to see this attachment.

The loop is used a bit weirdly there, you run it 10 times, but inside the loop you move ball more than 1 pixel, meaning if the speed is 10 like you set, 10 * 10 means it's moving 100 pixels every frame (as the loop is ran every frame) but teleporation still skips 10 pixels because it moves the speed amount in the loop it self, I think you meant to run the loop speed amount of times and move the ball by 1 pixel inside the loop to not skip any pixel

- I did this to save on performance as I am thinking I will probably not need such pixel perfect as it has to check every single pixel with the bullet flying so fast since the walls and sprites will probably not be smaller than 16-30 pixels. My thinking is that it if the bullet does not hit enemies behind walls or hit the wrong enemy it is all good. But again, might have missed something

And in case you need help with the bouncing ball example, I can try providing guidance if needed on how to use it (even though it should be pretty simple to use for the most part)

- Thank you so much, I am a bit confused about it, so if it was at all possible to modify the example and remove the unrelevant parts to better represent the same thing I am trying to achieve(shooting a bullet at an angle from the player and detecting collisions on enemies or walls) I think I would have a much easier time understanding it as it is very different now and I am not sure exactly what parts are relevant or not for it to work as intended.

Quote from Linky

No, not really, the example I sent is also a stress test benchmark, there are a lot of things happening at the same time, balls (bullets) are created constantly, and more than just one per frame, each "shooter" constantly fires multiple bullets all at the same time, so it's not a correct comparison

Oh sorry I think I was unclear. I mean that if I was to adjust my own example with a new formula I could test that for 3 seconds and then test the other formula to perhaps evaluate what performs the best. Like with the example of testing overlap vs collision events etc or even for testing with one version using child events and another without them etc.

Quote from Linky

It would work fine there because it's a very simple scenario, as soon as it starts being a bit more complex, like adding real collison handling (bounce and all) it will show problems and start breaking, even showing performance problems as well in some cases
As long as you manage multiple objects, a fastloop cannot be just used for all, you should instead run a foreach loop on the bullets, and on each one, you run the fastloop, then check for both in the same event (the fastloop should be checked first at the top, then the foreachloop under it, again, in the same event, so basically two conditions, the fastloop check, and foreach loop check)

A foreach loop would loop on all of the filtered objects by the event it ran in (in case of an always event, it will just loop on ALL instances of that object, but if it was something like a flag check, it would only run on the objects picked by the event), one at a time (in the same app loop, aka frame of course) on each one, it selects that instance, this is where the "One foreach loop" condition is called and where you can do stuff specific to that filtered object under it, and as we want to run the fastloop for every instance of the ball, you do it inside the foreach loop as I mentioned above, but we check for both because fastloops don't carry object selection, therofre the selection needs to be restored by checking for the foreachloop again in the event where we check for the fastloop (I hope that makes sense xD)

I will probably not have any bouncing, but yes it is good if it is possible to scale to more complexity without things breaking as that would be a real pain down the line I imagine if it is unstable and a bit "wonky" like that. I am sorry but I don't follow completely with the explanation of mixing fastloops and foreach loops. I am not really that savvy when it comes to coding in general (I am more of an art guy really so it does not come natural to me) but if there is an example out there demonstrating this I think I could get my head around it!

Quote from Linky

No to mention that child events are cleaner looking, easier to read, reduces duplicate code, and can be even used as if\else statements with the help of the "break" action, so you definitely should use them more next time, I use them all the time myself and can't really go back as they are hands down the best Fusion feature of the 2.5+ DLC

Yes I should really try to learn to start using child events more! One issue I have had though when trying to use them is that the "interface" for adding them feels very unintuitive unless I am doing it wrong. For example say I have two events and I want to add the bottom event as a child event to the one above, is there no way to do this in a smoother way than to have to first right click on the event above and pick "add a new child event" and then just create a placeholder event to get the child indent and then drag the bottom event into that and then erase the child event you created before. It feels very clumsy to have to do it that way. I was thinking if you could perhaps just press a keyboard shortcut to indent an event to the one above it as a child event etc? (tab would make sense to me to do that if it actually worked that way)

Quote from Linky

I will try making an example soon, just very busy currently with my main job and other stuff..

But the example should be easiy to use regardless, You don't need to care about the "Balls" group unless you want to know how it works internally (I even mentioned that you can just drop it in a behavior and forget about it), and no need to check the "DEBUG" or "Shooters" Group, unless you want to study how the shooters are behaving in the example, no need to even worry much about the "DeltaTime" group

The only things you might care about are these:

Please login to see this attachment.

I think this should be pretty self explanatory, event 10 and 11 spawn 10 balls under the mouse when you click LMB, and the balls go to a random direction

In terms of event 13, it does what it says, checks for collision, the Colliding flag only needs to turned ON if you want the ball (bullet) to bounce, when it overlaps with whatever you check for, if you don't want it to bounce, destroy the enemy there or something without turning any flags ON

All in all For setting the "speed" of the ball, you modify it's "Velocity" value, and in terms of direction, modify the "Direction" value
To check for collisions: first check for the "IsColliding" fastloop, under it check for the "Select" foreah loop of the ball, then check for the object you want to check the overlap with.

For your specific use case, you would want to create the ball at the player or so, set the direction value to point at the mouse, and check collisions with the enemies\walls in the way I showed and mentioned above

It's kinda like how PMO works if you think about it, just instead of a platformer movement and extension, this is a bouncing ball movement and a widget

Display More

Thank you so much I would be extremely grateful!! I will do my best in the meantime to try to clean and study the current example to see if I can get my head around it so far!

Quote from Linky

A very simple example, I hidden the core events of the custom bouncing ball movement and deltatime in object behaviors to avoid any confusion..
I also found some problems with the og example, all are very rare and may be considered as minor, but I fixed them anyways, for both this example and the og one (updated og example: Please login to see this link.) plus some general improvements

Most notable front end side change is the renaming of "IsColliding" and "Select" loops
Now the "IsColliding" fastloop is called "Movement.BouncingBall.IsColliding" and the "Select" foreach loop of the "Ball" object is called "Movement.BouncingBall.Select"
I made this change so the naming makes more sense and be more focused on what they are actually associated with

And again, no need to worry much about how the custom bouncing ball movement works, unless you want to study how it "internally" works, if so you can check the "Bouncing Ball Movement" behavior of the Ball/Bullet object (Same applies with DeltaTime)
Just check frame events and see how the movement was used there, it should be very simple to understand, it's like working with PMO or even the built-in movements of Fusion

Custom Bouncing Ball Movement: Simple Bullets Features:

• Same feature set as the og example, like Deltatime, Step checks (Quality) and multiple objects support
• Use case scenario of high speed bullets shot in the same direction as the player (Which is facing the mouse pointer)
• Very simple example cut out of any unnecessary fat

Please login to see this picture.

(don't get overwhelmed by the big red comment there, it's just a notice with detailed explanation about a minor thing that is already handled and accounted for anyways )

Please login to see this attachment.

Notes:

• The bullets move in high speed of 100 pixels, but the bullet "Velocity" value is set to 1000, why? because it moves in 1/10 pixels, that means a speed of 10 moves the object 1 pixel, it's done this way to to be able to set speeds with greater flexibility directly from object properties, instead of having to set speeds with decimal points only with events (as values don't support decimal points in the properties editor)
• As the bullet moves in 100 pixels, a step (quality) of 10 is set, therfore it only actually skips 10 pixels per move (because 1000/10 = 10), if you happen to need less or more precision, you can always modify the "Quality" value of the "DT" object (and again, as you increase the value, the more checks, aka steps it takes, the worse the performance gets, so you have to balance it correctly between precision and performance)
• As DeltaTime is one of the features, this allow the movement to function in a consistent speed no matter the FPS (more info about it in my written guide on gamejolt: Please login to see this link. and this video: Please login to see this media element.), so it's not frame based, if you game is frame dependent and want things to sync up with the rest of your frame dependent game, then disable line 5 (under the "DeltaTime" comment) in the "DeltaTime" behavior of the "DT" object, but do note that you will lose features like how "DtRatio" value of the "DT" object can be used to control the general speed of the bullets without manually modifying the velocities of each bullet, which can be used to create smooth slow motion effects as you increase the value or even easily pause the movement by setting the value to 0 (the default value of 16 would behave like a normal 60fps application as 60fps = 16.66666666666667 and 16 is close enough to that) and of course, the fact that you will lose the main advantage of DeltaTime which is making things behave the same way across different frame rates

MFA: Please login to see this attachment.

Display More

Thank you so much!! That is an amazing example!

I have modified it a bit to try to get me head around all the events and study it more! I hope I did not mess something up in it though by removing some additional events (it seems to be working for me) for example I removed some of the "always" child events (seemed to be mostly triggers to activate loops and moved them up to the parent event), and also removed all the bounching and "pushback" events. These looked really cool and I could really see a great use case for this for say a "scfi game" where the bullets bounce or bend around walls etc, but it is not needed for what I am making currently. Also I renamed some loops and values and extracted out the behaviors as groups. I actually used behaviors a lot in the past, but I found them to me more confusing since you dont get the same easy overview of all the events and also from my understanding they always trigger last in the event order (?) so it made for the occasional odd behavior in the past when I used them and wanted an event to trigger before other events etc.

I have uploaded my modified version here: Please login to see this attachment.

I hope I have not "broken" anything important and that everything looks alright still?

As for deltatime that is a really cool feature though I assume it would take a lot of work to actually implement a slowdown effect consistently over a project? I just tried and slow down the bullets by adjusting the DT Ratio but since the ratio is not affecting the rate at which the player fires his bullets it becomes odd so I assume one have to make a lot of adjustments to other things to make it look consistent and right. Also btw, I am planning to using a lot of physics in this project I am working on, do you know if you can affect physics speed with delta time or in some other way that could complement for making a slowmotion effect of the bullets and say enemies with physics movement moving?

As far as performance I do notice this example is still very much more demanding than the simpler one I had before, but it is probably well worth it if it is more reliable. I tried to make a comparison with as much the same factors as possible with firing bullets so always 4-5 are existing at one time and from the profiler if I understand it correctly this example is about 10 times more performance heavy? Running the previous example for 3 seconds and total time is 63ms and with the new it is 621 ms. I guess there is no way to reduce that? I am actually not sure if it is anything to worry about at all or not in either case though as I don't know how many ms is actually demanding or how much difference is regarded as something that makes a real practical difference?

Please login to see this attachment.Please login to see this attachment.