Last updated
Last updated
In FP Motion a is a game-object that the player can hold in its hands and used to perform different actions in the world.
As we mentioned before, a Weapon is an object that the player can hold in its hands. We make this possible by including weapons as children of the player's camera. This allows us to have the items follow both the player and its camera.
There are ways to get around this parenting, but they are not within the scope of the asset, and are thus not part of the feature list.
Aside from having the objects parented to the player's camera, FP Motion also has them parented to an empty Holster game-object. This object contains all the necessary, and also has a script to allow the player to switch guns at runtime.
Putting all the Motion Effects on a single object is something we do for both performance and utility. It's faster to tweak when all the effects are in the same place.
That said, you can still place these scripts wherever you like, and they will work all the same.
As for the actual Weapon structure, there is no 'required' way to set them up. In the asset we have the gun parented to empty game-objects of the same name.
We also have the bullet spawn point, and other similar objects parented to this empty game-object. This allows us to keep everything related to a gun in the same place.
Because we developed FP Motion in a way where you can easily integrate it with other assets or your own code, all the components that are not motion-related are simpler, and easier to replace.
Other components are: WeaponAnimator, ProjectileSpawner, FirstPersonObject and more.
These scripts exist to showcase what a complex game would look like with the use of this asset. Meaning they are not part of the 'core' of the asset.
We call these objects weapons because the asset only has weapon placeholder models, but as we mentioned before, these can be any object that the first-person player can hold in your game.
Yes. As we mentioned before, you can use any 3D model for the objects that the player can hold. These objects will properly receive motions.
The main reason to use the concept of a Weapon in FP Motion inside your own projects is to allow for an easier integration with the asset. That said, there are ways around this.
The process of adding new weapon is made super simple in FP Motion, by following this guide you will have your new weapons up and running in mere minutes!
If you're looking at the basic demo scene, and using the default player, you should see the following:
As you can see in the previous image, there is one Weapon parented to the Holster, that being the MP5. Now that we know that, we can get to adding our own!
We can start by right-clicking on the MP5 (the weapon parented to the Holster) and clicking on Duplicate when the drop-down menu appears. This will create a copy of the weapon, allowing us to create a new weapon easily.
Let's being modifying this Weapon!
First, we will rename it. We can do this by clicking on the object and pressing F2 on the keyboard. Another option would be to right-click and press Rename.
It's a great practice to name your objects according to what they are, or what they do in your game.
Now that we have our Weapon renamed, we can enable its game-object, this way we'll be able to see what we're working with.
You can enable a game-object by clicking on it and finding the toggle at the top left in the inspector panel.
After enabling the game-object, make sure to reset its position, rotation and scale.
Changing the 3D-Model of a Weapon in FP Motion is simple, you can do this by removing the Weapon's children, and replacing them with the model you want to use.
If we use the MP5 in the asset as an example, replacing it would mean deleting the "Arms" and "MP5_Model" game-objects as these two are its children.
This will allow you to parent your own 3D-Model to it!
Our default Weapons all have a game-object called "Spawn Point" as a child. This object's purpose is to direct where the projectiles come from.
You can only remove this object if you don't require the ProjectileSpawner script to be running, otherwise doing so will cause errors.
These state-files are currently stored as a field in the FirstPersonObject component, which gets automatically added with the Weapon script.
When creating new Weapons by duplicating a pre-existing one, you will find that the new one is using the old one's states.
If you require your new Weapon to use unique values for its effects, you can find the states file the old Weapon is using, and duplicate it. This will give you an excellent starting point for your new effect values!
You can find this file by clicking on the Weapon game-object and finding its FirstPersonObject component. This script has a value called Object States which will have the correct file.
To find this file in your project folder, you can double click on the value in the inspector.
Once you have duplicated the file, you can drag it onto the Object States variable that you previously clicked on and complete the replacing process.
So you want to make your very own shooting components work properly with FP Motion, huh? Do not fret, we have just the right guide for you!
Making custom shooting scripts work with FP Motion is something you can do in two distinct ways. You can do it the 'hacky' way (the way we are forced to do it for third-party support), or do it the proper way.
Both versions will work properly, but the 'hacky' one might run into some problems down the line.
The quick version is: The Weapon component takes into account the values specified by the developer, calculates when the player is allowed to shoot, and sends the shooting event at that point in time.
What this really means is that the Weapon takes the rate of fire you specify, and sends the shooting event at that rate whenever the player holds the mouse (if we're doing full auto).
We have purposefully created multiple ways of calculating the Weapon's fire rate to allow you, the developer, to have an easier time 'hacking' together an implementation.
This way of doing things is a little simpler, as you need not write custom code that works perfectly with our asset, and can just use your pre-written code as usual.
Doing it this way will ensure that the Weapon component will fire the shooting event at the same time as the custom script runs its own shooting code. Keep in mind that, when doing things this way, it's necessary to be precise when syncing the two rates of fire.
We recommend that you only use this for testing, not for proper game development as this may create problems.
We strive to make the proper way to implement things as simple as this in the future!
To make your shooting scripts perfectly work with FP Motion, you will have to allow them to do the heavy-lifting that our Weapon component currently takes care of.
What we mean by "heavy-lifting" is sending the correct shooting event whenever it needs to be sent. This includes both the semi-automatic and the automatic shooting event.
Now, to make sure your script allows the other parts of FP Motion to know whether shooting is happening or not, you can do:
Add your custom shooting component to the weapon along with the FirstPersonObject script. Now, open your custom script inside of your code editor of choice.
There are two important things that you need to make sure are present. These are adding a trier for the shooting events, and moving the shooting code to the invoked function.
That said, adding triers to the different events will allow you to stop them from firing when you don't want them to.
Once the code editor is fully open, you can click on your shooting script to edit it, and go to the Start
method. If you're not using a Start
or OnEnable
method inside your script, shame on you!
Never mind that, if you don't have either of these methods inside your code, you can start by typing (or copying) the following:
Inside this method we will need to add a trier for the correct shooting event based on the kind of weapon we want to create. What this means is that we will need a field that determines if this gun is fully automatic or not, and then we can use this to subscribe to the correct event.
We will start with adding the field, or variable, that determines how this weapon functions.
This will allow us to make unique weapons by changing variables in the inspector, which is great for any game!
Now that we have our value, we can check it inside of the OnEnable
method, and add a trier, and a listener to the appropriate shooting event.
This may seem a bit complex, but bare with us, it's not as hard as it sounds!
In case you don't know what triers are, they are custom functions that you can use to stop an event from running under certain conditions.
In our case, we might not want to allow the player to fire while waiting for the correct rate of fire.
Now that we have our trier, we need to add it to one of the shooting events. We can select which one of the two we need to use based on whether the gun is automatic or not.
As you can see, we now have the correct trier added in either case. This will allow us to stop the shooting events from firing when the actual gun isn't (rate of fire de-sync).
You can now use the CanFire
function to make the fire rate checks. An excellent example would be to do:
That's basically it for that! You can also subscribe your shooting functions to the event if you want them to use FP Motion's input system. This would further solidify the connection. Here's what that would look like:
Adding custom animations to your guns is simple. This process need to go trough FP Motion's systems and thus you can just use the Animator component together with a script to update its parameters.
We don't recommend using this component in production as it's nature is very simplistic. You can however use it as an example to build a better version of it, this being its intended purpose.
Within these simpler components, the most important one currently in the asset is the component itself.
To read more about this script, you can go to its . In short, its fundamental purpose is to update events related to shooting.
We recommend using a setup, but using one might disrupt the basic workflow for adding new weapons, and thus the following information might not be accurate.
First, expand the player's hierarchy and find out what are currently parented to it. This will be very important later on.
From here on out, there are multiple things that you can do to tweak this game-object. Whether it be changing the 3D model used, creating new or even including your own custom scripts and animations.
You might also want to learn how to tweak the weapon settings to make them suit your needs. You can learn how to do this by checking out the page.
are data files that comprise the for all the states that the player can be in at any given time. Each Weapon has one of these files attached to them, allowing you to make changes at the individual level.
Sometimes this can be good. Some games may use the same for all the guns in the same category, and thus may not need separate files.
To explain to you what the differences between these two ways of doing things are, we first need to explain how the component works.
The way to do this is just by adding your script to the weapon game-object as you normally would, keeping FP Motion's component added too, and syncing their rates of fire.
You will also need to add a FirstPersonObject component to your weapons/objects, no matter if they're using custom shooting scripts or not. This component makes sure that each weapon has its own .
Using the asset correctly requires that you make use of our . As the asset already handles all the input required for shooting, there is no need to include input checks in your code.
To add a trier we will first need a trier function to subscribe. These types of functions need to return a boolean. You can learn more about them .
We included a component named Weapon Animator in the asset. This script does exactly what we just described. It keeps the Animator component up-to-date with the state.
The goal of this document is to give you enough information on how the process of creating, changing and removing Weapons in FP Motion works.