I am making an Android shooting game. I have done some research as to the pros and cons of using raycast and instantiate and I would just like more information on themy really. I understand that using projectiles can be more expensive, but I don't think this will be too much of an issue (hopefully) as I can use object pooling. Other than that the only thing I notice is that the projectile seems to pass though objects no matter what colliders I have on them. Is there any real need for me to use raycasts, and if so why? They seem much less customizable (not that I am very clued up on them) and as they are instant hit I can't see them being very good for various types of weapons with diffevent trajectories, and projectile speeds etc. Thanks in advance for any input!
Look for hitscan vs projectile weapon in fps, there is design issues and it's not a either, as the best game use both (destiny, doom, etc ...)
Thanks for those, I found them very helpful. Although my game is going to be top down (with similar mechanics to unity's survival shooter) I will try to make use of both projectiles and raycasting. However, is there a way to add things like bullet trails to hitcast?
Yes just set up a Trail render at one location in the current frame and move it to the hit location in the next. Not sure if it would work from the instantiated position (weapon launch point) then moved to the hit location, in the same frame, so give that a test and let us know. Or you could just use a beam object setup it's pivot point at one end and scale it to the desired length. Should be lower draw calls than a trail. Two double sided planes or 8 tris vs a trail renderers need to work out the camera facing angle and draw a triangle strip.
The problem with colliders is that if they move very fast (e.g. several hundred meters/second) then you may end up with a situation where they are behind an obstacle in one frame, and in front of it the next frame - so there is no frame in which the colliders actually intersect, and no collision is detected. The best way to deal with this afaik is to store the bullet's position at the end of each frame, and raycast from the previous position to the current position each new frame to determine if there was an obstacle there. This is also great for instantiating hit effects in the correct position, because when only using a collider, even if a collision is detected, it is not detected at the collision entry point but rather wherever the bullet ends up at the end of the frame, usually somewhere inside the object that has been hit. In terms of trails, I think it is best to use a rigidbody on the projectile and move it using physics, but leave out the collider and use the raycast method I described. That way you can have a physically accurate bullet (non-instantaneous hits, and you can even add bullet drop and other nifty things) and then just add a trail renderer to it as well. PS this is not a game design question btw, should have been posted elsewhere.
Thank you for the input! Sounds like a good idea. Would using a trigger instead of a collider face the same issues? Also, if there is no collider on the object how will the script no when the projectile hits an object? Apologies, I didn't know where else to post a query like this. It's not really a scripting problem
A trigger collider is simply a collider which does not physically react to hitting an object, like a 'ghost' collider. It still registers the collision by detecting intersection with another object, but it will not bounce off or anything like that, but will pass right through. So the problem still applies because it is due to the collider being on different sides of the obstacle from one frame to the next, and never registering an intersection. The way you detect the collision without a collider is as I described, using a raycast from the previous position. You simply: Store the position of the bullet at the end of each frame; In the next frame (the bullet will have moved from the previous position) you raycast from the stored previous position, to the current position. If your raycast detects a hit, then your bullet has hit something between the frames, and you can create hit effects etc at the hit position (see the manual). FYI the game design section is for overall design strategies such as how to prevent players getting bored in an openworld game, or something like that. This is an implementation question and belongs in the Physics or the Scripting section.
A trigger and collider are the same apart from a trigger allowing things to pass through it without any physics collision happening. So same issues in speed. A collision can be detected by either object having a script with OnCollision/Trigger methods.
Do you know a good way to make the physics collision still happen as normal in that situation? I'd like my projectile to bounce off and also knock back the thing it hit just like it does in a normal collision.
As far as I know, the best way would be to script the collision - there's really no way to make physics work great at very high speeds. So when you detect a collision with the raycast, place the bullet at the impact point, clear its velocity, and add an impulse force to throw it backward - and another opposite force on the object you're colliding with.
You can normally make physics work at high speeds by altering the rigidbody collision settings to dynamic or continuous and also increasing the physics solver iterations.
Re reading OP I realize it was a technical question lol, I totally read that first as a game design question, glad my answer did help though lol
Just thought I'd throw my own personal experience on this (or lack of!). This topic interested me as I was running into the challenge that Billy4184 mentioned (collision detection for fast moving objects can be tricky). To start, I used a bullet object with a sphere collider on it to detect a collision with a target. That bullet was moving so fast though that collisions frequently were not picked up because the bullet would basically warp past an enemy between subsequent frames. So I then decided to ditch the projectile collider idea and go with a Raycast from my gun-tip to a set distance away in the direction it was aiming. That ended up working, but I lost the nice visualization of a bullet sailing off. Tip of the cap to both Billy and Arowx for coming up with good solutions to that problem... Raycasting from the bullet's last known position to the new position (not sure why I didn't think of this simple idea) in Billy's suggestion, or doing a trail of some sort in Arowx's suggestion and just Raycasting.. no bullet required. I think I like the trail idea best, so I'm going to give that a whirl tonight. I haven't tried using continuous detection yet just because I'd heard others still had the problem even with that set on.. but I may give that a go first, as I like the simplicity of just having a projectile fly out and do the collision detection. Anyways, my post isn't meant to offer advice.. just saying thanks for the good suggestions by Billy + Arowx