nate-gibson

[nate-gibson]

Week 13

25/10/2021 Monday

Colour Editor UI

Today I worked on implementing UI for the colour changer. I first started by creating 5 colour wheels. The colour wheel types are red, blue, green, orange, and white. The red to orange wheels have 12 colour buttons within them, while the white contains only 6. I then made 4 buttons to control which body part is being edited. These are the primary, secondary, accent and emission. The accent was removed later as it’s changes weren’t visible on the BroBot model, and the emission was renamed to lights. Lastly, I made the BroBot parts change colour based on the colour button selected.

Gif of colour changer:

26/10/2021 Tuesday:

Improved Menus

I spent today improving on the buttons and menus. I firstly started by adding back in the loading screen we had made in semester one. I changed the text prompt to “press start on controller or space on keyboard”. I changed it to this as I plan to edit the player spawn to use these inputs. I also plan on only allowing players to spawn in on the main menu screen.

I then set up functionality between the different menus. Within the main menu there is the play, paint job (colour editor), and quit buttons. The play button loads the player into the levels. The paint job button transitions the user into the paint jobs menu. The quit button exits the application. I improved the BroBots title text and added blinking text saying the required button to spawn in a second player.

Within the paint job menu, I added a return to menu button. This button transitions the user back to the main menu. I also added a “paint job” title text to this menu and copied over the spawn player prompt from the main menu.

Button Effects

I created button effects for each word button, such as resume, quit, etc. These effects are a grow, shrink, and click effect. The grow makes the button bigger and brighter when selected. The shrink reduces the size and dims the button when deselected. The click shrinks and then enlarges the button creating a clicking effect.

27/10/2021 Wednesday:

Crate Button

I started today by creating a crate spawning system for Ashton’s button asset. It works similarly to the buttons in semester one. When a player enters a trigger collider over the button, a pressing in animation will play for the button followed by a crate being spawned. Upon the player leaving the button an animation for the button lifting out will play.

The button required some tweaking as initially if one player was on it and then a second got on, the button would press again. To fix this I had to create two booleans that check if players 1 or 2 are already on the button and if they cancel any new button presses until all players have left the button.

Gif of crate button:

Dead Zone

I then created a dead zone and respawn system. I made it so that on entering an invisible collider under the map the player's manager and mesh would be disabled. I then set it up so that after 1 second the player would be moved to a respawn point, with their player-manager and mesh enabled.

I set-up 4 respawn points for the 4 levels that will be in the prototype. The dead zone uses a trigger surrounding each respawn point to determine which respawn area to use. You can only trigger a respawn point once, this disables potential backtracking ruining the player spawners.

Gif of dead zones:

Updated Player Spawner

I redesigned the player spawn system. I had to redesign this system to work only in the menu and to allow colours picked in the paint job menu to persist in the game scene. Firstly, I made start and space spawn the players into the project. This was because pressing A on Xbox, X on PlayStation, or enter on keyboard would also press the menu buttons.

Next, I worked to make colours picked in the paint job menu persist between the menu and game scenes. I originally made it so that the player mesh and input provider would spawn on a persistent gameobject (does not get destroyed between scene loads). Then when loading into the game I would spawn in proper players based on the number of controllers recorded in the menu scene. I thought this was a decent approach, but it proved to be extremely difficult assigning the players in the scenes to their appropriate controls. The difficulty came from having to assign the players without being able to use device input.

While trying to get the previous approach to work I realized I could just spawn in the proper player and have them persist between scenes. Then all I’d have to do is disable their player-manager and cameras when in the menu and enable them in the levels. This worked and was simple enough to set up, only requiring a few edits to properly disable and enable the players. With this finished the menu system was functional and finished.

Gif of finished menu:

28/10/2021 Thursday:

Target Button

Today I started by creating the functionality for the target buttons. The targets are used to activate disabled jump pads. Similarly, to the crate button, this target button has a pressing in animation. However, the idea for this is that the player has to fire a crate at the target, and it will then stay down. In order to do this, I set up a trigger collider in Infront of the target that when a crate enters will play the pressing in animation. It will stay pressed in and activate a close by jump pad. This jump pad is then used to get to a previously inaccessible area.

Gif of target button:

Button and Jump pad Lights

After getting the target button working, I realized the buttons and jump pad lack flare. They all have lights on them that I decided to turn on and off depending on the objects state. To do this I created a colour value that edits the brightness and colour of the light. It sets the lights to dull when inactive and then assigns them to bright when activated by a player.

Level 4

My last additions to this project for semester two was the creation of level 4 and a return to menu event. Since Ashton was handling the design of levels 1 through 3, he helped me to use and snap into place the correct assets. Ashton and I had previously brainstormed the levels and aimed to introduce one new element in each level. For level 4 I was tasked with introducing the magnet gloves interactions with magnetic walls.

I created gaps that the player can only cross using their magnetism on magnetic walls to pull them over the gap. There are two gaps in the beginning, the first being easy to cross and the second being more difficult. After that, to the left, there is a platform with a magnet wall that has a crate button spawner. To the right, there is a target and a jump pad that gets the player up to an area that returns them to the menu. This area is a trigger collider that requires every spawned player to enter, after they all enter the players are loaded back to the main menu screen.

Video of level 4: Watch from 3:48 to see level 4.

[nate-gibson]

#ctec709 - Final Entry - Nate Gibson - ‘BroBots’

Pre-University Blog Link:

1.) Semester Plan

Blog links:

1.) Week 1 2.) Week 2 3.) Week 3 4.) Week 4 5.) Week 5 6.) Week 6 7.) Week 7 8.) Mid-Semester Break 9.) Week 8 10.) Week 9 11.) Week 10 12.) Week 13

BroBot's Download Link:

https://ashtito.itch.io/brobots

[nate-gibson]

Week 10

27/09/2021 Monday:

Added jump buffer

I started today by adding a jump buffer to the player movement. The jump buffer allows players to jump if they’ve pressed the jump button just before reaching a platform. This is done by starting a timer when the player presses the jump button, the timer then ticks down while the player is in the air. If the player reaches the ground before the timer reaches 0, they jump. This is a common quality of life addition to platformer games, like Coyote time an element I’ve previously implemented.

Set up PC player

The last thing I did today was set back up the PC player. Earlier in development, we had both controller and PC players working, but as I’ve mainly been developing the player with a controller in mind I had yet to update the PC player. It was fairly easy to set back up the PC player as all I had to do was make some edits to the PC player's control scheme.

28/09/2021 Tuesday:

New player spawner

I improved on my player spawning system. The original spawning system was extremely clunky, it spawned players based on their controller connection order. This was okay for testing but severely needed a rework. The new system I created now works by checking all the connected controllers, then waiting for input from them before spawning in a controller player. It also checks for input from keyboard and will spawn in the required PC player. I also added a checker into the spawning code to make sure no more than 4 players could be spawned in total.

Horizontal Split screen

The next thing I worked on was horizontal split-screen. Our original camera layout was vertical, when playtesting with this layout our testers specified their dislike, and how they would prefer a horizontal layout. For this new camera layout, I created a function to determine each player’s window size and position. Since there will be a maximum of 4 players this means there can be 4 potential layouts in this function. The function will change the screen layouts based on the number of players spawned into the project and their spawn order.

Gif of all potential layouts:

Changed player movement speed

I next removed the sprinting option from the player movement. While playtesting we found that walking is basically irrelevant as most of our playtesters chose to run for the entirety of the test. This led to our decision to make the players base movement speed become their sprint speed.

When testing this out it felt more natural than the previous movement. However, when using a controller, it felt weird to constantly move at top speed even when the movement joystick was not pushed fully outwards. When looking at similar games to our project that don’t use sprint, we found that the movement was controlled by how far the movement joystick was pressed outwards. So, I created a speed variable that tracks how far out the joystick is pressed. This value was then used to determine player speed and animation. This created a more realistic motion for controllers.

For keyboard and mouse movement we decided that the speed variable will be set to its max when pressing just a movement key. But if a movement key is pressed while holding down the control button the movement speed would be reduced to a walking speed. I chose this approach as it is what 3rd person platformers with keyboard control schemes do.

Blend animations

My last contribution today was to rework the player animator. Since we had moved to changing the player animation through a value rather than a sprint button the movement animator had to be re-done. I created a blend tree animation; blend trees can hold multiple animations and transition between them using a value from 0 to 1. Using the speed variable, I was able to transition between 4 animations Ashton created. These are idle, walk, jog and run.

Gif of new movement:

29/09/2021 Wednesday:

Tweaks to colour editor

Today I added some tweaks to the colour changer. While calling with Ashton today he pointed out how the lights on the BroBots had no customization option. So, I created a new colour field to allow colour customization for this area. I Then made the materials editable while the project was running to make it easier to find colours we liked.

Gif of material change:

New player animations

I next moved on to adding in animations Ashton has made for the player. These animations are jump, fall, land, ground dash, and air dash. This basically consisted of creating transitions between each animation state. The jump state is called while the player jumps and is moving upwards, while the fall state is called when the player is moving downwards. On the player hitting the ground they are transitioned into the landing state. These 3 animations together create a smooth responsive feeling to the player jump/fall.

The ground dash is called when the player is on the ground and they press the dash button, at the end of the dash they transition back into normal movement. while the air dash can only be called if the player is in the jump or falling states. It will stay in the air dash animation until the dash has finished, it will then transition into either a jump, fall, or landing state based on the player's y value.

Gif of animation transitions:

Pause and options menu

I then moved on to creating a pause and options menu. I have yet to properly set up a pausing system for this project. I previous transitioned the players back to the menu screen when pressing the pause button. I chose this approach due to a lack of time before last semesters submission deadline.

Now that I have time, I decided to implement it correctly. I added bindings to the controller and keyboard control schemes that when pressed will enable a pause menu. The pausing code works by checking every player to see if they have pressed the pause button, if pressed every player will be disabled while a pause menu will fade in. The code will then check if any player pressed the pause button again or if the resume button on the menu is pressed. If done so the pause menu will be removed, and the players will be enabled again. The game will not freeze for the players unlike most pause menus, this was decided on because multiplayer games cannot be paused, and we aim to move this to an online multiplayer game later in development.

I also created an options menu. I created UI buttons for this menu for eventual options we want to give the player. However, none of these options apply any changes as I am yet to implement these features.

Gif of pause and options menus:

Animation for mantle

My last addition today was incorporating Ashtons new mantle animation into the animator. This animation transitions when the player encounters the edge of a mountable platform. After the animation is played it will transition into the landing animation. This landing animation is a placeholder for a later additional mantle animation.

Gif of mantle animation:

02/10/2021 Saturday:

Aim animation

Today I added aiming and firing animations into the project. These animations had to be handled differently as they need to override the players head, upper body, and arm animations. This is because aiming can be done when in any animation state other than mantling. What this means is that we need the normal movement animations to play for the players lower body while the upper body animations are overridden with these new animations. To do this I had to create a new layer over the base animation layer. This new layer then purely handles these aiming and firing animations. Using an animator mask, I was able to make this new layer override the upper body animations creating a nice and smooth aiming and firing effect.

Gif of aiming and firing animations:

Emotes animation

The last thing I did today was adding in emote animations. I started setting up basic animation states like my jump animation state. But this caused clutter in the animator, so I decided to create a blend tree to handle all the emotes. The emote blend tree contains 4 animations; these animations change based on a value that is assigned based on which D-pad button/number key is pressed. The value changer is assigned before the animation is played and cannot be changed during. This ensures the playing animation will be maintained throughout its playtime. I then set ways to cancel this animation. These are, if the emote is finished, if either of the triggers is pressed, or if the player moves. This allows for easy to cancel emotes that won’t negatively affect gameplay.

Gif of emote animations:

[nate-gibson]

Week 9

20/09/2021 Monday:

Magnetism usage bar

I created a magnetism bar. This bar functions similarly to a sprint bar, it will deplete when using the negative or positive power glove abilities. When the bar runs out the player is unable to use their magnetism abilities. This was added to nerf the ability as it’s far too overpowered. I also made the positive ability take a small amount while the negative ability takes larger amounts from the bar.

Gif of magnetism bar:

Negative pole burst

The negative magnet gloves pole is now a hold to charge and then fire once, rather than a constant firing. This was changed as when the player uses the negative pole, they never constantly interact with magnetic objects like the positive pole does. This is because the negative pole functions to fire away from the object/player while the positive pole is used to attract the object and player.

I have also made it essentially charge up the longer the player holds the negative ability down. Currently, it has 3 values it can push objects away at, they are classified as small, medium, and large. Each of these values takes differing amounts from the ‘charge bar’ and have differing controller vibrations.

21/09/2021 Tuesday:

Fixed magnet wall push velocity.

As you might’ve been able to see in the above gifs when the player fires away from a magnetic wall, they gain more thrust on the y than the x or z axis. Funnily enough, I discovered this issue was essentially the same as the jump pad skewed movement issue. Using the same fix I used for my jump pad issue I was able to create a smooth and uniform movement.

Gif of fixed push:

22/09/2021 Wednesday:

BroBot values

Today the group called to set the BroBot’s values that we will be using throughout the project. By this, I mean determining the player's max jump height, movement speed, platform widths, ramp slopes and so on. This is a highly important step for us as once these values are determined it makes creating levels infinitely easier. From this call we have changed the player’s jump height, platform height, width and length. Platform/ramp dimensions will now increase in multiples of 6. We decided on this as it is the perfect height and width for the players jump height and distance.

Magnet Objects issue

We then moved on to finding the values for the magnet gloves but had to stop due to an issue appearing. The issue was that the player would be moved upwards briefly by magnetic objects when standing on them. This happens because the point the magnet objects moves to is relative to the position of the camera, the cameras position changes when going from normal camera to aiming. There is a 0.5-second transition between these camera states, in this time the player can ride a magnetic object upwards.

While trying to fix this issue I discovered additional clipping issues when attracting magnetic objects. Due to this, I decided to recreate the magnet object movement code tomorrow.

23-24/09/2021 Thursday-Friday:

New magnet pull system

I dedicated Thursday to rewriting my object move code. The main issue with the object movement is it jitters when colliding with objects and can sometimes clip through them. This has been an issue I have been dealing with since first implementing this mechanic. After a tedious workday, I was able to find a solution to this issue.

I found that the reason my old magnetism system would sometimes clip through objects was due to it being parented to the move point. The reason I would parent it to the move point is that it smoothed the object's movement. The new system I created moves magnetic objects using a minimum and maximum speed and then dividing it by the total distance the player can be away from the object. This method creates smooth movement, accurate collision and allows the object to be dropped when its distance from the player exceeds a certain threshold. It also allows for momentum to be maintained when releasing magnetic objects, previously I had to set its velocity to zero making it drop like a brick when letting go of magnetic objects.

One issue has occurred with this new system and that is a slight jitter on the moving object. I spent Friday investigating this issue and believe it is due to Matt’s camera causing the jitter. Since I did not create the camera code, I will wait to fix this issue with Matt later.

Lastly, I thought of a potential fix for the move point taking 0.5 seconds to reach its desired location, and that is to give the attraction magnetism a 0.5-second charge-up time. I am unaware if this will interfere too much with the attraction magnetism so for now, it’s only a potential fix.

Gif of the new magnet pull system:

26/09/2021 Sunday:

New player setup

Today I called Ashton to set up the new player character. Ashton has finished the new player model and requires it to be set up as a working player, this is so he can create animations that match the player's movement speed. So, I created a new prefab and animator for the new model. I set up the animator so that Ashton can easily test out his animations within the project.

Fixed mantle

While doing this I discovered that my mantle system wasn’t properly working, this was because I had put the wrong mantling script on the player. This is an additional script that determines whether a collider on the players head has collided with a mountable surface. I added the right script and then tweaked some values to make the mantle nice and smooth.

New colour editor test

The last thing I did today was to create a test colour editor for the BroBots. We want the BroBot to be customizable giving players a personal attachment to their BroBots. This was somewhat of a new area for me, so it took most of the day to figure out how to incorporate this element into the project.

Eventually, I got a colour editor working for the BroBots. The BroBot model is separated into different segments that each contain one of 3 materials. These materials are ‘Primary’, ‘Secondary’, and ‘Accent’. I sorted these materials into 3 new parent materials. These 3 materials are then controlled by their respective colour which is editable in the inspector. This allows each player to have their own unique colour scheme while saving on space and processing power. Currently, the proper colours aren’t in so the below image is just a test to represent how it can look.

Image of colour editing:

Additionally, I plan on adding the colours into a saving system that will keep track of the player's customisations. It will function similarly to my checkpoint code from semester one, but instead of reloading the player's position on dying, it will save the players customisations.

[nate-gibson]

Week 8

18-19/09/2021 Saturday-Sunday:

Rewrote movement system (reformatted)

During the weekend I rewrote the player movement system. My previous movement system handled player movement, mantling, and the magnetism mechanic. Due to it handling all three of these areas the code was exceedingly long and difficult to follow. The rewritten code has been separated into 3 different scripts. They are the ‘Player Manager’, ‘Player Movement’, and ‘Player Magnet Gloves’.

The ‘Player Manager’ is where the code written in the ‘Player Movement’ and ‘Player Magnet Gloves’ is executed. This new addition allows myself and others to easily understand and rearrange my code. The ‘Player Movement’ script now only handles moving the player character normally and when mantling. The ‘Player Magnet Gloves’ purely handles the magnetism mechanic. This rewrite has proved beneficial as it has removed some small issues that were caused due to the previous code’s erratic execution order.

Sticking players to magnet walls

I also made the player stick to a magnetic wall when the player is attracting themselves to it. This was simple to add as I just had to freeze the player's position when they are colliding with a magnetic wall and are using the magnetic gloves positive pole on the wall. I then made them unfreeze when they stopped using the magnet gloves.

Gif of mantle movement:

Post-processing effects

I also add post-processing effects to my scene within the project. While working on our space image and sound project I learnt more about these effects and was able to add some effects that I feel complement the look of the game.

[nate-gibson]

Mid-Semester Break

Player Jump pad movement fix

During the mid-semester break I got my new jump pads working with the player. Originally, when the player would interact with a jump pad, they would move further on the y axis than the x or z. This created a strange, skewed movement. The jump pad works by adding a force to the player which is predetermined by the jump pads direction and speed value.

I found that in order to fix this issue I had to override the player's y velocity value. However, I couldn’t override my x or z velocity values since that would stop the user from being able to move the player. This meant that I had to create a new system to handle vertical (y) and horizontal (x, z) jump pad movement. After some trial and error, I created a function that replaces the player's y velocity with the jump pad y velocity, it then adds force onto the player's x and z velocity. This creates smooth vertical movement and adds extra horizontal movement that does not override the player’s horizontal position.

After these values are applied to the player, they will begin to decrease over time creating realistic movement. When the player collides with the floor their x and z jump pad velocity values are decreased at a higher speed to give the impression of traction.

I have some additional code I need to add such as cancelling the jump pad code when colliding with a wall and transferring the jump pad movement values onto another BroBot on collision. However, since I have written these before in previous jump pad prototypes I will next work on the player as they are a higher priority.

Gif of jump pad movement:

[nate-gibson]

Week 7

25/08/2021 Wednesday

Jump Pad Issue Fix

Since studio’s assessment 1 is due this week we spent all of Tuesday and most of Wednesday working on our assignment together.

On Wednesday we had a meeting with Clinton to show our progression. Before we had this meeting, I investigated my jump pad issues. When I changed my player colliders back in week 1, I had to make it so that when you are on the ground no gravity is being applied to the player. This caused jump pad platforms to stop bouncing the players. I fixed this by making jump pads enable gravity the player's gravity.

New Jump Pad Issue

While fixing that issue I found a way to make angled jump pads. I discovered that I could use the up direction of jump pads and propel the player in that direction. This however did not work as my movement system was interfering with this new jump pad movement. However, it did work with normal objects proving it was my movement causing the issue. I would’ve done more to it, but we had our call starting soon, so I’ll work on that issue at a later date.

Gif angled jump pad working with magnetic object:

[nate-gibson]

Week 6

17/08/2021 Tuesday

Magnet Objects Attract With Velocity

Today I started by setting up magnetic objects in the positive poll to move with Rigidbody.Velocity. I wanted the objects to get attracted towards the player and then stop in front of them. To do this I applied a velocity to the magnetic object being attracted. This velocity will move the magnetic object towards the new position in front of the player (this position was set up in week 5). The position has a sphere collider placed on it, when the magnetic object collides with this collider its velocity is set to 0, the object is parented to the sphere collider and its rigidbody is connected to the collider object. All these components combine to create smooth and accurate movement.

Gif of attracting and aiming:

Issues

A few issues have occurred from implementing the above. The first issue occurs when a magnetic object is attracted and positioned under the player, it will cause them to ride that object upwards infinitely. The second issue happens when the player attracts a magnetic object and pushes it up against a wall, corner, or floor, this causes it to move erratically. The last issue occurs when the player attracts a magnetic object and moves up against a magnetic wall, this can cause the player to fly towards the position of the magnetic object. These bugs while game breaking is not the most important elements to be working on currently, so I will focus on them at a later date.

Gifs of different bugs:

Magnet Objects Repel With Velocity

I next set up Rigidbody.Velocity with the magnet gloves negative pole. Unlike with the positive pole, the negative version is not required to stop when it gets within a certain distance of the player. So, all I had to do was add a velocity to the magnetic objects when in the negative poll and aiming at them. This made them fly away giving accurate and fun object movement.

Gif of repelling magnetic objects:

Magnet Wall Movement Angle Fix

The last thing I did today was change the angle the magnetic walls attract/repel the player at. Before this change the magnetic walls would move the players inaccurately, it would move them up higher than what they were aiming. I asked Matt for his opinion, he recommended an addition to my movement position value. This addition was adding the value for the distance from the player to the magnetic wall. This means that as the player gets closer to the wall the angle the player moves to is reduced.

18/08/2021 Wednesday

Magnet Gloves Testing Areas

I setup a bowling and hoops area. I made this to test out the new magnetic object velocity movement. The bowling section was made to test how the new magnetic object movement handled sloped areas. The hoops section was made to test aiming and how the new magnetic object movement worked with in mid-air. I setup the bowling and hoops section using ProBuilder. When testing the bowling section, I found that the ramp required a physics material with low friction otherwise it would lose too much speed.

The importance of these sections is to see how my magnetic objects new movement works in various circumstances. I also made this to give future playtester some sort of objective.

Gif of bowling:

Gif of Hoop shooting:

Control Scheme Change

I got the guys to test out the magnet gloves. While it was fun to use, they said the controls felt wrong. When attracting an object with the positive pole you then must press X/O to switch to the negative pole, this then repels the object away. This approach allows players to pick up an object aim it and then fire it away. However, this caused them to think that the X/O button repels the object and not that it changes the magnet gloves poles. They would then try to pick up another object not realizing they were now in the negative pole. They said that this didn’t feel right prompting a control scheme change.

Originally, it was left trigger to aim, right trigger to shoot the gloves, and X/O to change the poles of the gloves. The new control scheme is now left trigger to set the pole to positive, aim, and fire the gloves. The right trigger functions the same except setting the pole to negative. When testing this version out it felt a lot more enjoyable to fire objects and magnetize to walls. Although I will say I think it requires a slight bit of extra tweaking since it still feels a bit strange. It feels fine for interacting with magnetic objects, but with walls, it feels wrong. In the future, I might try making the positive pole attract small objects while repelling the player from magnetic walls, and have the negative pole repel small objects while attracting the player to magnetic walls.

Controller Rumble

I made the controller rumble while using the positive and negative magnetic glove poles. It took a while to find out how to properly incorporate it but eventually, I got the left trigger to give a low long rumble, and the right trigger to give a strong burst rumble. These lengths and strengths were decided on while testing with the guys.

Magnet Gloves Particle Effects

The last thing I did today was test out particle effects for the magnet gloves. These particle effects would start at the position of the glove and go out towards the aiming reticle. With the help of a Youtube tutorial, I made a basic tornado swirl. Some issues occurred while making this. Due to the angle of the player's camera, the tornado looks strange and sphere-like, this looked wrong and did not line up with my intention of a capsule-shaped force field. The other issue was the images I used for the particle effects disappeared when looking at them side-on. This happened because they are 2D pngs. I need to fix this as while the main player won’t see it the second player could. To fix this I need to change it to 3D objects. This is an area I am very new to so it will take much refinement and testing to get to a standard I am happy with.

[nate-gibson]

Week 5

10/08/2021 Tuesday

Magnet Gloves onto Player

I spent today moving the magnet gloves mechanic onto the player. I first moved the magnet glove code into the player movement code. The control scheme is the same as the last prototype, aiming with the left trigger, firing with the right, and switching magnetic poles with X/O (on a controller).

Raycast to Spherecast

While setting up the magnet gloves mechanic I decided to change my raycast to a capsulecast. For a refresher, a raycast is an invisible ray that is shot from one point in a specified direction. I used this raycast ray to determine the object being hit and the hit position on the object. The reason I changed to a capsule cast is that it allowed me to tweak its radius. Unlike the capsulecast the raycast is stuck at the thickness of a single line. The capsulecast now allows my magnet gloves to have a decent radius for detecting magnetic objects and walls.

Currently, the magnet gloves can magnetize objects, however, when aiming the capsulecast to detect magnetic objects it cannot be angled up or down. This is because the capsule cast is currently going in the direction of the player rather than the camera.

Aiming Issue

The magnetic gloves component is working on the player, however, there is one main issue that still needs resolving. The capsulecast used to detect magnetic objects cannot be angled up or down. This is happening because the capsulecast is using the direction of the player’s rotation. Since the capsulecast can’t be aimed up or down it gives the magnetic gloves inaccurate aiming. To fix this issue the capuslecast needs to use the rotation of the camera. This is an issue I’ll aim to resolve tomorrow.

Gif of Magnet Gloves:

Sprint change

While setting up the magnetic gloves for the player I had to change the sprint control. It previously used the right trigger to initiate running. This trigger is now being used by the magnetic gloves, so the button had to be changed. Sprinting is now determined by pressing down on the left joystick. I made this a toggle, so you only need to tap it down once. This is a common addition for third-person and first-person games, so it made sense to switch to this method.

11/08/2021 Wednesday

Fixed Magnet Gloves Aiming Issue

I started by fixing the aiming issue I discussed yesterday. As I previously stated the aiming is inaccurate due to the capsulecast being unable to rotate up or down. To fix this I set the capsulecast to rotate based on the camera’s rotation rather than the players. This now gives an overall more accurate aiming system.

Accurate Magnet movement

I changed the position the magnet moves to. Originally, when the magnet gloves are in positive mode and aiming at a magnetic object that object would move towards the player. This magnetic object would not stop and when reaching the player would begin to push them backwards. To stop this from happening I set the magnetic object to move towards a position in front of the player. This position is also assigned to the camera angle so that it changes relative to the direction the player is aiming. Now instead of constantly moving towards the player and pushing them backwards, it moves in front of the player and stops there.

Gif of magnet movement:

Magnetic Walls Push with Velocity

The last change I made today was how magnet walls move players. My magnet glove code directly moves objects/players position rather than applying a velocity. This causes 2 issues, firstly the object being moved can clip through other objects, the other issue is that momentum will not be maintained. I fixed these issues for only the magnetic wall movement. I did this by changing the magnetic wall to move the player using Rigidbody.Velocity. This is the function I’m using to move the player. This allows for objects to accurately interact with obstacles in the scene, aka no more clipping into other objects. It also allows for the speed gained from moving the object to be maintained after the magnetism has stopped. I will be applying this fix to the magnetic objects the next time I work on BroBots.

[nate-gibson]

Week 4

03/08/2021 Tuesday

Magnet System Fix

While testing out my magnet system I found the player was attracted to the wrong location for magnetic walls. Instead of being attracted to where the player was aiming, they’d move to the origin position of the walls. When looking through my code I found that I was taking the wrong value for where the player would be moved to. So, I changed that value to be the point of contact where the raycast line from the player hits the magnetic wall. The player now moves as intended.

Slideshow

Ashton, Matt and I set up a slideshow for tomorrow’s crits. I was in charge of getting gifs for the slides. I acquired 6 gifs in total. The first 2 were of our original prototype and our current prototype, this was for comparing our progression. I recorded videos of the original magnet crane mechanic and my new magnet gloves prototype. I then made them into gifs and used them for comparing our core mechanics progression.

I then got my last 2 gifs, one for ragdolling and the other for mantling. I used a gif I had previously made of the ragdoll. Since this ragdoll gif looked quite good and was prominently orange, I decided to create a mantle area under purple light. I chose purple so it would contrast with the ragdoll gif. For the level, I placed pillars at increasing heights in a circular formation. I recorded myself working through it and made it into a gif for the slides.

We then made writer notes for our slides. I am going to be discussing what is captivating in our project. So, I spent the rest of our session making a structure for discussing the most captivating elements in our game.

Images of all slides:

04/08/2021 Wednesday

Presentation:

We presented our slideshow today. Ashton spoke for the first two slides. They were the description of our concept, and how can the project enhance the happiness of everyone. Matt spoke for the anticipation and innovation sections, and I discussed the captivation section. We didn’t receive any useful feedback from the crit session. This was somewhat to be expected as not many people in our degree are creating a game for their project.

Dash Movement Mechanic:

After the presentation we had a bit of time remaining, so I decided to implement a dash into the project. The new dash works by propelling the player forward at a high speed for less than a second. The direction the dash goes in is based on the player's rotation. I showed the guys and they helped me tweak the speed value and length to a reasonable amount. Currently, you can easily spam the dash movement, but since the project still requires development, I’ll tweak the cooldown for the dash at a later date.

Gif Dash movement:

[nate-gibson]

#ctec709 - Project 1 - Nate Gibson - ‘BroBots’

Pre-university Blog Link:

1.) Semester Plan

University Blog links:

1.) Week 1 2.) Week 2 3.) Week 3 4.) Week 4 5.) Week 5 6.) Week 6 7.) Week 7

Creative Workflow Document:

1.) Document Link

[nate-gibson]

Week 3

27/07/2021 Tuesday

Mantle Movement

Today I implemented movement onto the mantled platform. Firstly, I needed to find the height of the object the player is mantling onto. Last week I made a variable that finds the height of mantled game objects, I added an extra 2f to this height variable so that I could use it for the players new y position. From there I needed to move the player onto the object, to do this I made a variable that takes the forward direction of the player. This variable is then used in a function that moves the player for 0.1 seconds. This gives a nice quick mantle movement.

I found that the player needs to stop rotating towards the object before I move them on top of it. This is because the player would no longer be colliding with the object that the player is turning towards, making the player continuously turn. To fix this issue, I created a check that would only allow the player to move once they have rotated towards their desired position.

An issue has occurred, the player will rotate at inconsistent times. This is an issue with the function I’m using to rotate the player. The closer the player gets to reaching its desired value the smaller the rotation becomes. This becomes obvious when one mantle takes 1 second while another can take around 6 seconds. For now, the movement does work but I will need to fix this issue later.

28/07/2021 Wednesday

Repeatable Mantle

I spent today working on my mantle system. Currently, the player is stuck after they are rotated and moved. So, I prioritised making the player transition back into normal movement and making the mantle a repeatable process.

My mantle system disables movement and enables my mantle movement code when the player is not on the ground and has collided with a mountable surface. To re-enable this movement code, I created a Boolean that I will refer to as ‘mountedWall’. When ‘mountedWall’ is set to false it allows the player to collide with mountable surfaces, this would then transition it into mantle movement. After this movement is completed ‘mountedWall’ is set to true. This stops the player from mounting onto objects and re-enables the movement code.

With this base setup, I next had to make the mantle reset. To do this I had to set the ‘mountedWall’ Boolean back to false. I also had to reset certain variables in my mantle code otherwise it would not work as intended. To do this I made it so that when ‘mountedWall’ is set to true those certain values would all be reset. Then after a set time ‘mountedWall’ would also be reset back to false.

While I was working on this Ashton and Matt got the following feedback for some new Brobot designs.

Images of design data:

30/07/2021 Friday

Mantle Orientation

Today I fixed the mantle orientation issue. I started off our call by chatting with Matt about my mantling system. While walking him through my code we found that the object I was using to get the rotation for the player was changing while the player rotated. This was because it was parented to the player.

I tested the mantle with an object that wasn't parented to the player, this reduced the frequency of its position changing but didn’t completely stop it. I found that I had basically let the ‘new rotation’ variable call repeatedly causing it to change throughout the rotation. To fix this I moved the variable into a function that only allowed it to be called once upon mantling. This stopped the position from changing but the speed at which the player rotated was still inconsistent. This had something to do with the function I was using to rotate the player. When looking it up online people recommended against using this function. Due to this I just made it so the player would instantly rotate towards the object with no time delay. This fixed the player rotating at different speeds.

The last thing I did for the mantle was to edit the length of it. I did some testing to find a length that I thought was appropriate. This was to give a one-second delay after the player rotates towards the platform and has moved up to the edge of it. After this delay, it will move the player on top of the platform.

Gif for final mantle:

Coyote Time Fix

While testing my mantle system I found that my coyote time function was not working. This coyote time function basically gives the player point one of a second to jump off a platform after leaving it. The reason I added this is because it is a common addition to most platforming games and is basically a necessity to make your movement feel smooth and responsive.

In my jumping code, I had created a checker that basically says if the player is on the ground, is pressing the jump button and if coyote time equals greater than 0 the player can jump. Coyote time would countdown while the player is in the air then reset back to 0.1 when they touched the ground. I thought this would allow for the player to have that small window when leaving objects. However, when looking back at my code I found that coyote time was never being used because it also required that the player was on the ground. I fixed this by making it optional so that it would be if the player is on the ground or if coyote time was greater than 0. this fixed the issue and it's already made the movement feel a lot more responsive.

31/07/2021 Saturday

Magnet Prototype

Today I decided to create a test for the magnet system. I created this on a new game object because I didn't want to deal with editing the BroBot movement code just yet. I started by creating 4 states Off, On, Positive, and Negative. By default, the system is set to Off. I am using a float value that I have assigned to the right trigger on a controller, this value changes the system's states between Off and On.

When the system is set to On the Positive or Negative states are then activated. By default, the Positive state is set but this can be changed by a Boolean which has been assigned to the X/Square button on a controller. This Boolean like the trigger float changes the states between Positive and Negative.

The next thing I did was create a raycast checker. What this does is create an invisible line from the front of the object the script is on for a specified length. This checker returns true when the line interacts with objects that I've set to be on the magnetizable layer. I created two-sphere game objects in my testing scene, I made one have the magnetic script (call this “player”) and the other I set to be magnetizable (call this “magnet”). From there I just did some testing to make sure the raycast accurately collided with the magnet. I next created code to get the position of the magnet object through my raycast checker.

From there I made code that would move the magnet towards the player when hit by the raycast. This code would be called in the Positive state. I then made code for the Negative state. To do this I made a value that would be positioned at the very end of the raycast line and made the magnet move towards that instead of the player.

The last thing I did was creates surfaces that would magnetize the player. I started by creating two tags that the magnetic objects could have. “Small” was assigned to objects that would be moved by the player. “Large” was assigned to objects that would move the player. From there I created a checker in my code to get the tag of the game object the raycast collided with. If the tag was “Small” the movement I had previously explained would take place. If the tag was “Large” some new movement would happen. This new movement would move the player to the position of the magnet when in the Positive state. When this was in the Negative state, the player would move to the end of a raycast going in the opposite direction of the normal raycast. This basically gave the effect of the player being repelled from the object.

Gif for magnet test:

[nate-gibson]

Week 2

21/07/2021 Wednesday

Weekly Plan

We have decided to dedicate our Wednesday sessions to gaining user feedback and setting up marketing for BroBots. Tuesdays and Friday’s will now be our development days where we will be working from 10am-4pm. We will be working over discord on these days just like how we have done in previous semesters.

Company name

In class today we officially decided to choose Sneaky Panda Studios to be our company name. Everyone we asked seemed to really like it, so we decided why not. Ashton was able to set up an email address and multiple social media accounts that we will use for documenting our progress to the public. these accounts will most likely only be used for when we reach certain milestones and not for weekly updates.

Website

We then moved onto setting up a website page. We planned on using Squarespace for this and set up the following website using one of their provided templates. Most of these sections have placeholder images and text, but this is how plan to have it arranged.

Images of website plan:

We noticed that to release the website it will be a monthly subscription so we will be putting this website on hold for now.

Player collider/New player

The next thing I did was show the group the new player colliders. I wanted to do this as the changes I’ve made could cause some confusion. I then talked with Ashton about the new character animations, mainly that they cannot be orientated forwards like the last ones. This is because when the character is orientated the colliders must orientate to create realistic movement, but this also means the players would easily get stuck. By keeping them at the same orientation it will eliminate this issue.

User feedback for BroBot head designs

The last thing we did today was to get feedback on BroBot head prototypes. Ashton had made some designs in blender that he wanted feedback on to see which of his designs were more popular. Image of acquired data:

23/07/2021 Friday:

Mantle System

Today we called over discord, we worked from 10:00 AM to roughly 5:00 PM with breaks in-between. Days like these are valuable as it allows for us to work on our tasks, receive help from each other and to put pressure on ourselves to finish our areas.

I spent today working on my manteling system. I have done some previous work in the mid-semester break; this was mainly spent researching how to create one of these systems and applying some foundation code. This foundation code was simply to stop the player's movement when a box Collider around their face interacts with a mountable surface. I had also spent some time trying to make the player rotate towards that surface but did not have any luck with it.

My day was spent trying to get the player to orientate towards the surface. Now while this does sound easy it proved to be a very difficult task. When testing how to make them rotate correctly I tried some simple code that makes them look at the centre of the object. I found this to not work as they need to be facing forwards relative to the surface they are on.

So, what I had to do was create a system that would fire out invisible lines in the north, east, south, and west directions for the player. From there I made it that if the line encounters an object that is mountable and some extra conditions are met, the player will rotate to the point where the line hit the object. This will only work for objects that have no orientation to them. Either only straight objects will be mountable, or I’ll investigate creating a new system, but I do believe this system will suffice.

Lastly, I tested moving the player up after they mantle. Since mantles were going to be something that happens all in one go, I planned on orientating the player towards the wall and then moving them up onto the surface. I somewhat found a way to do it, but I needed to re-write some code and didn't have enough energy to refactor my mantle. Before I finished there was one more thing I wanted to do. This was to move the player up to the edge of the object they’ve mantled onto. I did this by getting the height of the object subtracting 1 from it then moving the player up to that height. I subtract 1 from the height to allow the player to sit nicely on the edge. Now when an animation is ready the player will move to the accurate rotation and height of the object when mantling.

25/07/2021 Sunday:

Mantle orientation fix

I made it so that the player can orientate towards angled objects. I did this by making the “lines” go north, east, south, and west relative to the object instead of the player. I then based these “lines” at the player position. This does not account for objects that are not square-shaped, but this won’t matter as most mantle-able objects will be.

Gif of normal and angled mantle:

[nate-gibson]

Week 1

14/07/2021 Wednesday

Company name/Branding

Today was a big reintroduction day. This means it was the day where we find a place to work and are told basic programme information. This left us with little time to work on our project. So, we decided to spend our remaining time thinking of a company name.

We want a way to represent ourselves as a group working on BroBots, to do this we need a name to represent us. From there we can set up accounts all aimed at advertising our progression. We thought of 8 company names and asked a couple of people their opinions on them. The one with the most votes was “Sneaky Panda Studios”. The name was said to be funny while also being somewhat professional. As we finished for the day “Sneaky Panda Studios” was sitting as our backup company name since we still wanted to think of more names.

Image of company name doc:

16-18/07/2021 Friday – Sunday:

Collider changes

In my own time, I did some edits to the players. I switched the main collider from a box to a capsule collider. This was because the movement from the box collider was somewhat restrictive compared to the capsule collider. The capsule collider also safely envelops the head area and body of the player.

One old issue arose from this change. When using a capsule collider and standing on a corner of an object the capsule Collider will begin to fall off that object. I'm not exactly sure why but it has something to do with the curve of the capsule and gravity being applied to it. When looking around online for insight on fixing this issue I found a very smart comment that recommended just disabling gravity. Upon implementation, this fixed the issue, but it meant I had to remake some jumping/falling code which took quite a while. this new code also caused an issue with jump pads, but I will fix that after implementing the mantle system.

Images of collider changes:

[nate-gibson]

Semester Plan

05 - 11/07/2021 Prior to week 1:

Made rough plan

A week before university started Ashton, Matt and I called to plan out next semester. We had previously decided to continue with BroBots semester. This was because it was still incomplete and would look good on our portfolios.

The call started by going over our feedback from last semester. From that feedback, we decided on some major changes we wanted to make to the project. We then assigned these changes to each group member.

For the first couple of weeks, Ashton will be working on redesigning the BroBots. I will be testing the new models in the unity project throughout this redesign. This is so I can give Ashton feedback on their dimensions as they need to match certain colliders. These colliders are what make the player move and interact with their environment.

Matt’s initial focus will be creating a toon shader. Toon shaders are commonly used to add a certain style to games and overall increase that games look. Since unity by default does not look great having a toon shader is a must.

I will initially be working on adding a mantling system. In our previous prototype, our biggest complaint was the neck ragdoll. For a reminder, this neck ragdoll meant that if the underside of the player’s head hit an object that player would ragdoll. This was added to the project because the player model had a bigger head than the body. This meant that the player would get their head stuck over ledges. We thought that the neck ragdoll fixed the issue and added an interesting gameplay element, but it only made movement unnecessarily hard. Due to this, we decided to replace that system with a mantle. This mantle would bring the player up over a ledge if they were to just miss it.

Along with adding this system, I will be redesigning the colliders. This is to remove that head getting stuck issue completely as not all surfaces will be mountable.

Decided on milestones

After choosing our initial focusses we create a plan on Trello. In this plan, we gave a rough time to finish these additions. We then discussed everything else we wanted to add and assigned them to each team member.

Trello board image:

While the power glove has been set to Matt both he and I will be working on it.

New core mechanic

Leading up to week 1 we realized that BroBot’s was missing a unique game mechanic. Our initial project had a unique mechanic being that both BroBot’s were controlled by 1 player. As our project progressed, we scrapped this idea. We need a unique mechanic as it’s a common requirement for small indie games to have one. This is because those small games need a unique hook to attract in players. Since removing that mechanic, we had been focusing on setting up a stable foundation for this project. Now that we essentially have our foundation, we have time to add a new mechanic.

When thinking of a new game mechanic I thought about the magnet we had in-game. I really liked the idea of the magnet sucking up the player and moving them to another location. I was thinking of how we could expand on that, potentially taking the idea of magnetism and converting it into our core mechanic. After some planning and refinement, I came up with “power gloves” (placeholder name). In my plan these gloves would consist of 3 states off, positive, and negative. These gloves would be set off by default. When pushing the left trigger, they would be set to positive, and for the right trigger negative. These gloves would function as a magnet, if they were set to positive, they would attract small objects to the player or attract the player to larger objects. If they were set to negative, they would repel small objects away from the player or repel the player away from larger objects.

These power gloves fit the idea of a unique multipurpose mechanic that could become the hook in BroBots. I told the group my idea and reasoning behind it, they were on board, and we discussed some implementation surrounding them. Matt and I will both be working on this mechanic after we finish our initial additions. We will both be working on this since the idea will be very difficult to implement.

Image of my google doc plan:

[nate-gibson]

Motion Capture Project - Documentation

Script

Put together by group:

Storyboard

Created by Matthew and TianLin:

Shot List

Created by Ashton:

House plan

House I created in floor plan creator:

Unreal engine Plan

House I created in Unreal engine to test out the dimensions:

Final Blueprints

Blueprints I create for 8 total zones:

Originally there were going to be 9 zones but the 8th one became redundant so I removed it.

Playthrough of the 8 zones

The following video consists of a playthrough of all the 8 zones in the project:

Unfortunately when recording the character could not collide with doors. This meant we were unable to use zone 2 (Bathroom zone).

Final Videos

Work-in-Progress:

Final Video:

[nate-gibson]

#ctec708 - Final Entry - Nate Gibson - ‘BroBots’

Original Development blog:

1.) BroBots Development

Blog links:

1.) Week 1 2.) Week 2 3.) Week 3 4.) Week 4 5.) Mid-Semester 6.) Week 5 7.) Week 6 8.) Week 7 9.) Week 8 10.)  Week 9 11.)  Week 10 12.) Week 11 13.) Week 11 Playtest

BroBot's:

1.) Download here

BroBot's requirements/instructions:

1.) Requires Windows PC 2.) Download the BroBots_0.3 folder 3.) Unzip the folder 4.) Connect 2 Xbox/Playstation controllers 5.) Launch the BroBots.exe file