Final Project Week 13 - Adding attachments

Last week I worked on creating attachments and applying their modifiers to the weapon, this week I will create the functionality to apply them to a weapon visually so that the user can have the ability to customise their weapon if the developer decides they want that functionality in the game.

Attachment Standards

This visual customisation system has to be able to apply the modifiers at runtime as well as place the attachments in the correct place. because of this, a standard must be put in place for how the weapons and attachments are set up. I will have to make this as clear as possible to the developers by including documentation, example weapons and attachments. 

The standard will be very slightly different depending on the developers' preferences and development style, but as long as all attachments and weapons are consistent within a project, it will work. Essentially the attachment model should be a child of the actual attachment point. its position should be set based on how you would like it to sit on the attachment point. Below is an image displaying what this means.

Front View Of Sight

Yellow Point Represents where it will attach to the weapon

Here you can see that I have positioned the attachment point to match the weapon setup in the image below. I have set it up so that the points on the weapon are on the edges of the rails, so the point on the attachment is on the inside of the gap for the rail, but the developer could choose to have the points at the base of the rail if they wanted, they would just have to adjust the point on the attachment to match.

Yellow Points Represent Attachment Points, where attachments will be set to.

Applying Attachments

Applying the modifiers

I wanted to make sure that the modifiers were as easy as possible to set up. I had been thinking of ways for the weapon script to know what attachments to be looking for. I was going to have a list of attachment scripts that the developer would have to populate but I thought that this would be unnecessary and lead to confusion if they forget to populate the list.

The method I decided to use was having the weapon find all of the attachments within its children. this wouldn't be a problem because all attachments should be children of the weapon anyway, this also has the added benefit that the attachments will not need any reference to the weapon that it is a child of reducing the chance of error. 

Finding the attachments this way can be a heavy task for the computer, so I wanted to make sure that it only checks when it is necessary. For testing, I have had the system check for attachments and apply their modifiers every frame, this is unnecessary and very inefficient. Now that I am creating the attachment application system, I can know exactly when the system should update the attachments. When the weapon is spawned into the game, it will find all of its attachments, and apply the modifiers that they have. It will do the same thing if any change is made to the attachments during runtime using the attachment application system that I will make. To help the developers, I have condensed the code into 2 functions that can be called, 'ResetToBaseStats()' and 'ApplyAttachments()' this will allow the developers to build their own attachment functionality if they would like.

Applying the modifiers at runtime

The first step towards applying attachments at runtime included creating attachment points. These are predefined points that the developer can set up to allow the user to apply attachments if the developer doesn't want the customisation, the attachment points are not required for the system to work.

Each attachment point has a list of possible attachments that it can apply, this allows the system to show the user a list of attachments that they can use. This list is populated by the developer using prefabs that they will create. These attachments do not technically need to contain an attachment script meaning that this same system can be used for purely visual customisation that will not affect how the gun handles.

Spawning attachments on the weapon

The attachment point is responsible for instantiating the attachments. It must be a child of the weapon, placed where the developer would like their attachments to be applied, this positioning is important and changes based on how the attachment standard has been altered. This is because it does not contain any special parameters for where the attachment is instantiated, it will always spawn it as a child of itself at the local position (0,0,0) This is why the standards for attachments is important.

Displaying the attach point of the attachment and weapon

The attachment in its final position

With attachment points set up on the weapon, I now had to create the method to spawn the attachments. This was quite simple, the system instantiates the attachment at the local position (0,0,0), that attachment is then set as the current attachment in the attachment point. if another attachment is selected, the current attachment is destroyed, and the new one is spawned. 

UI for controlling the attachments

Next, I started creating an attachment selection screen, this will contain some UI that will allow the user to easily see which attachments are available to them and swap them out quickly. This has a reference to the weapon system, it will get the current weapon, and find all of the attachment points. Using a camera attached to the weapon system, it will find the screen position of each weapon point and create a button at that position.

Squares are buttons to select which attachment to change

Having these buttons on the weapon, rather than in a list, allows the user to know which attachment they are choosing, without having to know the name of the attachment point. If one of these buttons are selected, a bot will appear with a list of possible attachments for that slot.

Demonstration of applying attachments to the weapon using the new UI.

The weapon camera can be changed based on what the developer wants their customisation screen to look like, I will include some variations below that are possible. Eventually, I decided that the best way to set it up without creating new assets was to have a solid colour background, and only show the weapon. 

Example of the attachment screen

Adding a background sprite

Change of Weapon Position

Originally I was going to have the modifiers be applied as the attachment is spawned, but I found that this wasn't very efficient. There is no point applying the modifiers if the user might change more attachments within seconds. Because of this, the attachments modifiers are applied when the attachment screen is closed because this means that they are done with the customisation.

Saving The Attachments

I wanted to ensure that my system came with a save feature so that it will remember what attachments the user chooses for their weapons, these can then be spawned onto the weapon as the game is started.

When starting this, I was looking at the different options for saving. Unitys player prefs are built into unity and very easy to use. I also looked at json, this would allow me to save a lot more data more efficiently, however, the saving that I am implementing only needs to save around 3 attachments for 3 weapons. meaning that json may be overkill for what I want. json is also not a standard feature of unity and harder to learn than player prefs, this wasn't a problem for me, I have already used it in other projects in the past, however, I am trying to make my system easy to make changes to if the developers using my system should want to so I decided to use player prefs.

The way this works is, each weapon, attachment point and attachment has a unique name for saving. These names will be used to form a key for a string player pref. As an attachment is saved, it will take the weapon name, then the attachment point name as the key, e,g. "M4Carbine_AttachmentPoint1", the value for this key is then set to the name of the attachment, e.g. "VerticalGrip". Using this method, we can save every attachment in every weapon within the system.

Loading attachments uses the same method as the saving, it will take the save names of the weapon and attachment point, except instead of setting the value, it will search for the value, and spawn the corresponding attachment. If the value is blank, it will leave the default attachment, this allows the developer to create default presets rather than just having a bare weapon because the player has never saved it.

Now that attachments can be applied at runtime, there is only one milestone left to complete before I complete what I planned for my project. Next week I will talk about the visual stat system I plan to implement.

The GitHub for this project is available here: https://github.com/ElliotChester/Modular-Weapon-System-Final-Project