Category Archives: Game Dev Logs

Confidentiality Dev Log 4: Play Testing/Feedback

Throughout the development process, I tested the various functions of my game to make sure they all worked correctly. In this dev log, I will show some of the game functions in a video as well as detail some issues that I found or that were given to me as feedback from other testers and how I fixed them.

These videos shows the functions of the player working correctly as I am able to crouch, open the vent, climb the pipe and take down the enemy correctly.

This video shows the restart function working as intended when the player is discovered by an enemy.

However, while testing these functions I also discovered that the colliders relating to the pipes needed to be adjusted. This is because the player drops too early while vertically climbing so the player can fall if they aren’t in the right position and the colliders activating the player animation to move horizontally are placed too close to the vertical pipes so that they can cause the player animations to glitch out if they don’t navigate the pipes the specific way I did in the first video displaying the player functions correctly.

This video shows these errors that I discovered have now been fixed allowing much smoother and less precise movement as well as no animation glitches when climbing the pipes to navigate in the game.

This video shows a bug reported to me by external testers of my game that allows the player to crouch while they are navigating the pipes. This breaks the illusion of the pipes in the game. This happens because the player is still able to enter the crouch animation while climbing which is definitely not intended to happen. This happens because the player collider at the top of the player object is disabled when the player crouches so the game no longer registers the player as being in horizontal pipe animation trigger.

To fix this bug, I had to change how the script for the horizontal pipe movement animation worked so that it is similar to how the pipe climbing function for the vertical pipes works. To do this I used an empty game object linked to the ‘pipeHCheck’ variable and a layer mask linked to a new layer created for the horizontal pipe animation trigger. This meant that the top collider of the player object being disabled no longer stopped the horizontal climbing animation from happening.

The testers also discovered a visual error in the end screen of the game where the title was clipping with some text. I easily fixed this by adjusting the position of the title sprite in the end screen scene.

This video is a play through of the finished game with all the errors and bugs mentioned fixed.

Confidentiality Dev Log 3: Skeletal Animation

This dev log will cover how I approached animation in my game. To create my sprites for my player character and enemies I had to add a layer for each part of the body. For example, the head and torso. To do this I used Adobe Photoshop and then saved it as a .PSB file which allowed Unity to see the different layers in the sprite image and separate them into different sprites. If I didn’t do this I would have had to import each part separately which would have been more time-consuming.

I then used the Unity skinning editor to add bones to the different parts of my sprite corresponding to the different parts and generated some geometry automatically on the sprite that corresponded to the bones for each part of the sprite. Some adjustments had to made with what bones affected the geometry for some of the parts of the sprite but it was very easy to rectify. After I applied this to the sprite, I could then start creating animations for this by manipulating the bones I created and using the animation window. To make an animation clip, I had to press the record icon next to preview and manipulate the bones to be in different positions at different key frames.

After the different animations were created, I had to use an animator controller to make sure they played at the right time. To do this I used transitions that worked only when certain parameters (left side) were met. The parameters are triggered through the respective scripts for the player and enemies as I touched upon in the dev logs for the player and enemy scripts.

Confidentiality Dev Log 2: Enemy Script

This script controls the functionality of the enemy objects in the game. There is a version of this script for each enemy so the script works correctly for each enemy since the script is disabled at the end. The script starts by declaring the variables needed for the script to work. The ‘enemyAnimator’ variable refers to a sprite animator that will be linked outside of the script (it will be the animator on the enemy object the script is connected to). The two ‘GameObject’ variables refer to UI elements that need to be enabled or disabled at different points which are linked to outside of the script. The two ‘Transform’ variables are used to link to empty objects that will be used to generate ‘rays’. The ‘LayerMask’ variable will be used to link to a layer that will be used as the basis for the area that the enemy can patrol. The three float variables are different values that are needed for the script: ‘speed’ refers to the speed of the enemy while ‘distance’ and ‘detectionDis’ are used to determine how far the ‘rays’ created in the script go. The one bool variable is used to determine that the enemy is moving in a direction so the direction can be changed if the end of the patrol area is reached. The ‘private void Start’ part of the script is used to make sure that the ‘rays’ created from the enemy can’t interact with the colliders of the enemy.

This part of the script contains the functionality for how the enemy objects patrol and how they detect the player. For this section of the code, ‘void Update’ is used so that the game will always be checking for these parts to be triggered since they need to happen immediately and also include some input from the player. The first line after ‘void Update’ is used to move the enemy but unlike the Player script no animation code is needed for the walk animation as there are only two animations for the enemies so the walk is the default animation that plays until the other one is triggered. The part after this is used to make the enemy change direction when they reach the patrol area end so they endlessly patrol the area determined by the ‘patrolArea’ layer mask using a vertical ‘Raycast’ as the ‘ray’ will be what looks for the layer that allows the enemy to patrol. The next if statement detects common input that would be used after restarting a level to resume the game after the ‘timeScale’ is changed to 0 by reverting it back to 1. The last part of this section uses a horizontal ‘Raycast’ that looks for the player so the fail function can be triggered. It does this by disabling the UI that the player will see in regular gameplay and then enabling UI that overlays the entire screen while also telling the player that they failed as well as freezing the game by setting the ‘timeScale’ to 0.

This last part of the script is used to allow the player to take down the enemies in the game. It first sets a bool in the enemy animator to true that determines if the take down animation should play and then disables the collider that triggers the take down as well as ending the script so the enemy no longer has any functionality.

This is an alternative version of this script that removes the movement function as there is a stationary enemy in the game that only needs the detect function.

Confidentiality Dev Log 1: Player Script

This script is the one that controls the majority of the functions of the player object in the game. The top part of the script shows all of the variables needed for the script to function correctly. The ‘rb’ variable refers to a rigidbody2D that will later be linked to the player. The two check variables refer to empty objects that are used to detect either a pipe or ceiling. The ‘crouchDisableCollider’ variable refers to the top collider of the player so that it can be disabled and let the player crouch. The ‘playerAnimator’ links to the animator of the player so animations can be played when certain functions are used. The two ‘LayerMask’ variables link to layers in the game so that the pipes and ceilings are able to be detected. The ‘input’ variables are used to allow the player to move horizontally and vertically. The three bool variables are used to determine different things about the player so that parts of the script know when they are supposed to activate. The ‘speed’ variable is a float that is used to determine the player’s speed while the ‘Radius’ variables are floats that determine the size of a radius around an object that detects the ceiling and pipes. The next part of the script is about creating a bool and event that can be used to play an animation when the player is crouching. The ‘private void Awake’ section links the ‘rb’ to the player rigidbody2D as well as some additional code needed for the bool event linked to the crouch animation.

This section (public void Move) contains code that controls certain aspects of the player. The first part determines whether the player is underneath a ceiling while crouching so the player object doesn’t play an animation where the player is stood up. The second part controls the functionality for the crouch as well as the crouch animation. The last part makes sure the player is facing the right way when moving by linking to the ‘Flip’ function.

This part of the script adds functionality to the ‘Flip’ function so that it will actually flip the player as well as linking a bool variable from this script to a bool variable in the animator connected to the player so that the animation will play at the right point.

This ‘void Update’ section is used to create the functionality for most of the actions the player can do in the game as the Update part makes it so the script will always be checking for the input so the player actions are never delayed. It starts by linking the A and D keys to horizontal movement using the ‘Horizontal’ tag and then determines the speed of this movement as well as linking the input to a float in the player animator so that the walk animation will play while the player moves and so an idle animation will play when they don’t. The next part links the C key to the crouch function so that whenever the C key is held down the player will crouch. This next part allows the player to climb pipes by enabling the ‘isClimbing’ bool when the player is in the radius of the pipe layer and they press the W or S keys and then disabling it when they aren’t in the radius anymore. After this, the ‘isClimbing’ bool is connected to the code for climbing using an if statement. If ‘isClimbing’ is true the W and S keys will now control the movement of the player vertically, the speed of the player will be added to vertical movements, the gravity of the player will be set to 0 so they don’t get dragged down while gravity while on a pipe and a bool connected to the climbing animation in the player animator will be set to true so that the climbing animation plays. If ‘isClimbing; is then set to false the vertical movement functionality will be removed, the gravity of the player is returned to 2 and the climbing bool in the player animator will be false so the animation stops.

The rest of the player functionality is contained in scripts that are connected to the game objects that the player interacts with rather then on the player object. These functions are the ability to open vents/trap doors using the E key and the ability to drop from a horizontal pipe by holding the Space bar.