One more thing, put the code below into the script attached to the bullet. If there isn’t one then create a new script, put this code into it, and then drag the script onto the bullet prefab instance in the Unity Editor.
function OnCollisionEnter(other: collision) {
Debug.Log("I hit: " + other.gameObject.name);
Debug.Log("I hit: " + other.gameObject.tag);
}
This won’t fix your problem but it will tell you what the bullet is hitting, and whether it is the collider of your character or the gun.
Also, make sure that the variable “shootForce” in your code is not zero. If it is then the bullet’s velocity will be set to zero, and it will just fall on the ground. This variable should be declared outside of any function in the script that fires the bullet like this:
public var shootForce: float = 0.0;
This will allow you to set its value in the Unity Editor, within the inspector pane that is populated when you click on your gun object. You can assign a value to it when you declare it, but better to make it initially zero and then assign a value to it in the editor.
Since you seem to be new to scripting, let me explain a few other things while we’re at it, in case you are not aware:
By declaring shootForce outside of a function, it becomes an instance member variable on the gun game object. This allows its value to persist across different time, and be accessible in the scripts functions, such as Update. You can actually have three different types of variables: 1) One that has local scope which is declared inside a function. This variable persists only during the function call. 2) One that has object instance scope. Its value persists as long as the game object exists. 3) One that has scope across all instances of a game object.
The other thing I wanted to point out is that OnCollisionEnter is an event handler. When you see a function or method prefaced with the word “On”, this normally means that the function is an event handler, meaning that it is called in the event something happens. In this case, that event is a collision. Each object that can has a collider (or is a trigger) can participate in a collision event, and the script attached to that object can, but does not have to, implement an event handler which will be called when the collision occurs. You should only put code pertaining to a collision event inside a collision event handler.
Once we solve your problem, I can give you a few more pointers on how to organize your code, but generally doing as you are below, where you have your bullet’s collision event handler, handling different types of events for multiple game objects is not good design. Basically the bullet should only worry about animating an explosion (if applicable), playing an explosion sound (if applicable), and destroying itself. The different objects being hit, which can and should also define an OnCollisionEnter function can handle their respective behaviors accordingly. This is called encapsulation. The practice allows you to hide the information and logic used to implement an object’s behavior from other object. This then makes it easier to extend your game’s behaviors, and reduces the likelihood of bugs. Doing as you are below would require adding more and more conditional statements to the event handling code in your bullet each time you add a new types of game objects and behavior. Because you are doing it in a big “logic switchyard”, any bug you introduce will have the potential to impact your whole game not just one object or behavior.