During the final week of vertical slice, I worked on finalising and polishing my level design. I spent a lot of time also finding and fixing bugs within the game to ensure that it is fully playable. I added a new text display to show the player how much money they have collected when picking up coins and trophies. I also incorporated a Perlin shake function onto the text to make it shake whenever the player picked up money and the money count increased. This provided extra feedback to the player when collecting money. I also made the text fade out after a specified amount of time of not collecting any money. This is due to the fact that one of the aims of our game is to minimise UI elements as much as possible. I also changed the alarm system to trigger a door to open and set a list of guards to chase the player. This occurs after the player triggers a laser beam.
Due to the fact that my scene is the largest of the three for vertical slice I also had to optimise the level to cull objects which were not seen by the player. To do this I split my scene into 2 worlds which would enable and disable all objects within each world depending on where the player was in the scene. This worked effectively and increased performance within my scene. Finally, I also added a cut scene for the end of my level which switches to a second camera that shows the player taking off in their van as the guards try and stop him. This will be the final ending to our vertical slice level. Personal Reflection: Now that our vertical slice is completed, I am very proud after looking back at what we have achieved as a team as well as individuals. There have been many times during the vertical slice where we were unsure of the exact direction that the game was heading in and it was hard to see how the game would function with the combination of everything that we had been working on. Thankfully within the final week and a half of development, we managed to combine all mechanics and art into a level split up into three sections which is fun to play through and shows off the majority of the mechanics which we intended to implement. There are a variety of aspects of our game and production process which I am very proud of. One of these is the fact that we as programmers set out to make our systems within the game as modular and easy to use as possible. I believe that we successfully achieved this as the majority of our mechanics such as grapple swings, alarm systems, doors, lasers and AI have all been designed in a way which makes them easy to set up and use within future level design. I am also proud of the way in which we worked together as a team and communicated with one another to complete each of the tasks that we set out to do. We were rigorous with our planning for each week and the effective use of our team production plan ensured that we were always on track and knew exactly what we had to be working on. I was also proud that the team took our game down to Armageddon to have it play tested and get feedback on things to improve. This greatly helped our production as it allowed us to get feedback on the perspectives of others who played our game which could then be worked on to make the game better. On a more personal level there are a few aspects of the game which I am very pleased to have contributed to. The mechanic that I am proudest of implementing within the game is the grapple mechanic. I took this mechanic on board for the entirety of the vertical slice and continuously made an effort to optimise it and make it feel as smooth and satisfying for the player as possible. I spent many hours on this mechanic to get it to feel the way that it does in the current state of the game and I am very happy with how fluid and satisfying it feels to grapple within the game. A lot of thought went into this mechanic to perfect it and maximise its use within the game. For example, the way in which it prioritises grapples within the player’s view, pulls the player up when grappling from the ground, and the way in which it provides constant feedback via the line renderer and button prompts to make it easy for the player to notice them and use them. I was very happy when the majority of play testers told us that this was their favourite mechanic within the game and the one which they wanted to see more of. I was also very proud of my level design within the final level of the game. I placed a lot of time and effort in planning object positions and guard patrol routes in this level and I am very happy with the way in which the level plays out as a whole. I am also particularly happy with the end cut scene that I made for the player leaving the level in their space craft. I am also proud of the external saving and loading which I have implemented into the game using JSON. This can be expanded upon in the future to create a more elaborative saving system in the future. There were a couple of mechanics that I worked on which did not make it into the game at this point, however I am still happy with the way that they turned out. These mechanics include the ventilation system which would allow players to traverse the scene by entering and exiting vents as well as the over world car driving implementation which was super fun to drive around in. Hopefully in the production process we will be able to incorporate these mechanics into the game. There were however some aspects of the vertical slice which did not go to plan and there were times when we made some mistakes. One of the biggest challenges for me was the fact that for a long time our game seemed to have little direction as we had many mechanics which we wanted to implement into the game however were unsure of exactly how they would interact with one another when playing the game. We also initially over scoped the vertical slice process by trying to incorporate an elaborate story within the game. Initially we designed our vertical slice level to follow a story line and this caused us to waste a lot of time on a level which would at the end of the day not actually be used. However, as a team we were able to overcome these obstacles and at the end of the day have a successful vertical slice to show for it. I think that one aspect we can work on as a team is our use of time management when working on the game in the future. On a more personal level there were some mistakes which I made along the vertical slice process. One of these mistakes was when I was not willing to give up on the “arm physics” within the game. I wasted a lot of time on this mechanic within the game before realising that it was not the ideal thing to use within our game. I also failed to stick to the coding naming standards which we had set out to use at times during development and this is something I would like to improve upon in the future. On a whole I am very happy with the way that our vertical slice turned out. There were many lessons learnt along the way and it has been a great experience to work in a team environment over such a long period of time. I am confident in our team and our ability to further improve the game during the production phase to come.
0 Comments
This week our game jumped to a whole new level as we started to work on a finalised level design and implementation. After Josh and Zac planned the different stages of the level I was assigned the final part of the level to design. This section was intended to be made up of larger areas for the player to move around in and was aimed to incorporate as many of the mechanics learned to this point as possible. Much of my time this week went into designing this level using the new pro builder tool to construct the buildings and then manually place all the objects within the scene. Before creating the different rooms of the level, I first planned each room using a drawing to map out obstacles, goals and guard patrol routes. This proved to be very effective as it gave me a design to follow when putting the level together. The first small room/corridor is designed to introduce the player to the mechanic of laser beams within the game. The idea in this design is to get the player to navigate under and over the laser beams before reaching the next room. If a laser beam is triggered then the door at the rear of the corridor is required to open and release some guards which will run towards the player. This second room requires the player to navigate around guards on the floor before being lifted to a platform where they can unlock a door to the next room. It is designed in a way that requires the player to navigate through the room to reach the platform before being able to access the grapple points which are higher up and allow easy movement across the room. In this way, it combines our stealth mechanics with the fun mechanic of grappling within the same room. The third and final room in my scene is designed to focus primarily on the movement using grapples and platforms to stay above the guards which are on the floor below. However, if the player makes a mistake and falls to the ground they are then forced to traverse the room with more difficulty as they will need to be weary of the guards. The scene will end with the player reaching their space ship on the perimeter of the “space station” and then flying off to escape the space station. Other than level design and creation I also reworked the way in which platforms work within the game. This is because the moving platforms did not correctly update the players position whilst standing on top of one which would result in the player sliding off. To counteract this, I implemented the platform movement in a way which made the player and camera a child of the platform whilst standing on top. This ensured that the player remained on the platform regardless of its speed and allowed for smoother movement whilst on the platform. I also implemented the spark particle which Juane created to generate whenever the players rope connected with a grapple. This created some extra game juice as well as feedback to increase the fulfilment from grappling even more. Some other changes included reworking the way that the grapple pull works when engaging the grapple whilst grounded to accommodate for the new grapple animation. I also changed the pull to pull the player to half the distance between the player and the grapple. This was done to decrease the chance of the player becoming caught on the ground when pulling to a grapple.
After taking our game to Armageddon this weekend, one of the improvements that players requested was the movement and feedback within the game. As a result, this week I placed a heavy focus on attempting to improve all aspects of movement within the game. Firstly, I started by experimenting with the different physics materials which could be applied to the players. Originally, we were utilising a “no friction” material on the player to stop them from becoming stuck on walls and objects. This however resulted in the game feeling very “slippery” which made it hard for players to control their movement between objects. I replaced this material with a standard physics material to remove the slippery movement however this did not solve the issue of the player constantly becoming stuck on the walls. After analysing the code, I realised that our grounded check was in fact not being utilised properly which was causing us to become grounded whilst jumping against walls. I changed this grounded check to function as intended which improved the movement within the game. The grounded check for double jumps was also being calculated incorrectly which resulted in inconsistent jumping patterns and allowed the player to triple jump on some occasions. These minor bugs which affected movement were removed by rewriting a portion of the code and including a delay timer to stop the player from registering as grounded even after the jump had been started. I also incorporated a new object onto the player which holds children objects to ray-cast downwards to determine whether the player is grounded or not. By doing this I could specify the exact locations that grounded checks would occur which could then be used to incorporate a tolerance for jumping off objects. For example, placing a grounded check object which was further behind the player model now allows the player to jump even after falling slightly off the edge of an object. This small compensation is necessary in ensuring that movement feels smooth and slightly forgiving for players and ultimately improved the feeling of movement currently within the game. The grappling hook within the game proved to be one of the major mechanics which Armageddon players wanted to see more of within the level. There was however some criticism towards the way that it functions and the feedback given from the mechanic. For example, the players felt that some form of range indicator should be incorporated to make the grapple more obvious and to provide more feedback to the player. I took this information on board and decided to use a line renderer to draw a thin dotted line between the closest grapple point in range and the player. Now it is much more obvious when the player is within range of a grapple point and it is also clearer as to exactly which grapple point the player is closest to. The players at Armageddon also suggested that the button prompt for the grapple should not show whilst on the ground if the action requires the player to jump before grappling. This is important information as giving the player an instruction which cannot be carried out when prompted makes little sense and can make gameplay confusing. Because of this I decided to change the grapple hook implementation to allow the player to grapple even whilst on the ground and in range of the grapple. Now if the player grapples whilst on the ground they are first lerped to a pre-determined distance from the grapple point before they begin swinging. In this way, the prompts now match the action within the game and as a result the grappling mechanic is much easier to use and feels more fluid. This week has been a busy week with the preparation for Armageddon in Wellington this weekend. A major issue encountered during the week was the fact that our initial level design was slightly over scoped and lacked purpose. When playing through the level with such large open spaces it was hard to find the fun within the game as it felt like the player was not making any progress. To combat this problem, we decided to place a larger focus on designing smaller levels with puzzles made up of the existing mechanics within the game. Josh and I worked on creating our own individual levels which would help to teach the player the mechanics within the game incrementally. This worked well as we came up with different solutions and puzzles which we then combined to make the final level for Armageddon. This proved to be much more effective as the smaller level with focus on mechanics gave the player a sense of purpose as well as progress as they advanced through the level.
Apart from level design I also focused on finishing off the checkpointing system within the game, since it would be a requirement to respawn the player at Armageddon. Last week I managed to create a class which could save and load enemy positions according to their assigned ID’s. This week I improved upon this by creating a save and load manager to handle all saving and loading within the game. I also created a new script to manage the players data which was to be saved in a different file to the enemy data. By setting up the saving and loading in separate scripts it made it possible to specify which aspects of the game should be saved at any given time. Splitting the save locations into separate files also enhanced this ability to specify which aspects of the game should be saved and loaded depending on the requirements at the time. I also created a checkpoint prefab which would call the checkpoint saving function within the save and load manager whenever the player walked through its trigger box. This essentially allowed us to easily place and specify save locations for the player throughout the level. I also implemented a failure state for the game by incorporating a “kill zone” onto the front of enemy guards. The kill zone works by counting down a timer when the player stays within the zone without leaving. Once the timer reached zero the player would be caught and a death failure message was placed on the screen to communicate what had happened. Once a player was caught I also called the load checkpoint function to load the players last checkpointed position which had been saved. To improve the communication and player feedback I also incorporated a button prompt system within the game to tell players when they would be able to perform a specified action. For example, when the player is within a grapple hooks range it now displays the corresponding button prompt to complete the grapple. This works effectively as before it was hard to judge whether the player was within range of a grapple or not. The new button prompt gives a clear indication of when the player can complete the required action. So far, I have added the button prompts to actions such as the grapple, pick pocketing of guards as well as the interaction with the vents within the game. This has proved to be successful in aiding the player know what they are required to do. Up until this point in development we have been designing the game primarily to be played with a controller. I decided to incorporate keyboard controls into the game to cover the same functionality on controller. After implementing this it became clear to me that the controls feel more intuitive on the keyboard/mouse. This is primarily since the camera is easier to control and manipulate with the mouse than it is to do so on the controller. A challenge for us is going to be to ensure that the controls of the game feel just as easy to use on the controller as they do on the keyboard. This means that we will possibly need to spend more time on the camera controls within the game in the weeks to come. Finally, I also added a new effect in the game which will allow us to create an “explosion” of any specified game object. Currently it was designed to be used as a coin explosion whenever the player pickpocketed the guards. However, I have designed it in such a way that allows it to be customised within the editor to use alternative game objects to spawn. The effect also allows us to specify the minimum and maximum amount of force applied to the instantiated objects as well as the number of objects to be created in the explosion to generate different effects. I have also set up the coins, which are created on the explosion, to “magnetise” towards the player when within a specified range limit. The combination of these effects has made the pickpocketing of guards much more rewarding and fun to do. The new magnetising coins can also be placed around the level for the player to find which creates an incentive for them to explore the levels. This week has been an important week as we have begun combining all our mechanics into the first level of the game. One of the biggest steps this week has been the implementation of our AI plugin which we have designed to help us easily implement AI path routes, vision and hearing distances within the game. During the week, I focused on implementing the ventilation system which is intended to act as a means of travelling through the level. Originally the concept was to use a ventilation system which would allow the player to crouch and physically move through the vent from entrance to exit. However, after some thought we decided to change this to function more like a portal which will teleport the player from the entrance of the vent to the exit. This decision was made as camera issues would prove to be a big issue with allowing the player to navigate through the vents in third person view. When designing this I did not want to do it in a way which would just move the player between the vents immediately. Instead I decided to create a fade to black function which faded the screen to black before moving the player from one point to the next and then faded back in once the player had been moved. I also ensured when implementing this system to make it modular and dynamic so that vents would be easier to set up in each of the levels to come. To do this I created a vent prefab which allowed us to easily drag another “exit vent” into the script to ensure that the linking of vents was easy to implement and use. I also set up the prefab to require an “exit camera” which would be switched to when moving the player from vent to vent. The reason we wanted another camera was to allow the player the chance to look around at the exit side of the vent before leaving in case there were any guards which may be alerted. This allowed us to easily set up another camera in the precise location that we wanted for each vent which could then be switched to when the vent was used. I also created a separate camera script for these new vent cameras which allow the player to utilise the cameras to look around before exiting the vents. I included a public limiter which would allow us to determine exactly how far on the X and Y axis each camera could be rotated by. We have discovered two different types of camera shots to utilise with this mechanic which may provide very different effects during gameplay. The first shot utilises the classic security style cameras in front of the vent which allows the player to get a larger overview of the room they are about to enter. The second shot uses a camera inside the vent which provides a point of view shot of the player before they are about to leave the vent. This camera location is something we will have to tinker with and test to ensure that using the vents feel and look satisfying for the player. I have also set it up so that the player can exit the vent at any time by pressing the interaction button again. We decided to include a minor change in the form of a double jump into the game since one of the primary mechanics will involve movement and platforming. I incorporated this by adding onto the existing jumping system. I limited the jump force of the second jump to be half the initial jump force from the ground to provide a jump in the air which was of reasonable size. I also added the ability for the player to jump off guard’s heads. The reason for this is because we wanted to incorporate some form of “offense” that the player could use if a guard was running towards them and they needed to get past. This jump uses a trigger sphere around the guard’s head to detect whether a jump is available for the player. I also included a minor change to the grapple system which now allows the player to traverse up and down whilst grappling. This effectively allows them to shorten or lengthen the length of their grapple rope.
This week I also spent some more time working on the checkpointing system within the game. To improve on the work I did last week, I decided to learn how to use JSON to serialise and save the data to external files. The reason I have decided to use this is because it allows for the serialization of variables such as vectors which was not possible with the unity default serialization. With the new implementation, I can now save the positions, rotations and ID’s of each enemy within a list at any given time using a button press. I can also load these properties and re assign the properties to the enemies with the respective ID’s. This sets up the basic functionality for checkpointing within the game which also doubles as a saving system which can be used to load saved games data once the game is shut down at a later point in development. This is a system which will be constantly evolving and changing within the game as we need to save more and more data of different types and so it is something I will be working on in the future. My next step will be crating the actual checkpoint zones which will allow the player to save their progress.
After implementing the fully functioning audial detection I then ensured that the AI were not only alerted to sounds, but also stored the sound position and moved towards it in an attempt to find the player. After reaching the sound position the AI now also return to their original state after a short delay of searching and finding nothing. During the week, I also continued working on the grapple mechanic to perfect it. We received the new character model from the artists this week and I attempted to implement the stretchy arms in the same way as before in the hope that it would appear better visually with the new bone structure set up. This was however not the case and after a lot of time spent on the physics based arms we decided to call it quits and replace the system with a more controlling system using animations. I also improved the grapple by including functionality for the grapple to break and disconnect if the rope between the player and the grapple point was hit/interrupted by an object along the swing. This week I also started working on the overworld which will be used as our level selector within the game. The idea is to have an overview of a map with the different levels at different locations. The player is then able to drive their van to the different levels to select the one that they would like to play. To implement the cars movement on the map I wanted to continue the comedy aspect which our team is well known for and as a result decided to make the movement based on “drifting” the van around the level. To do this, I set up my own custom script to use as the movement for the van. This utilises physics and forces to move the van around using the analogue sticks. I managed to get the movement smooth and fun to control and included a public variable to determine how “drifty” the van would be whilst driving. This will be used during playtesting to refine the movement according to how people like it to feel. I set up line renderers on the four wheels of the van which render skid marks on the ground where the van drives. I have also set up a basic functionality for us to load specific levels using a level selector prefab which can be placed on the map and used to load a specified scene/level by driving in to its trigger box and pressing the A key.
With the way in which we are setting up the first level it is crucial for us to have some form of checkpointing system to respawn the player if they are caught during the first mission. This checkpoint system will need to store the players current progress through the mission each time that they reach a new checkpoint. It will also need to save the enemies positions and states within the level at the time the checkpoint is reached. To do this I have decided to utilise Unity’s serialization functionality to save the needed properties of the game in an external file. This data can then be pulled to load the level in the same state that it was in when the checkpoint was reached. This week I managed to implement minor functionality for saving positions and rotations in an external file and then using this file I could load those values and reset the objects to those positions and values when needed. This is something which is quite complex and will take a bit more time to fully implement within our game and as a result I will continue working on it in the week to come. During this week my major focus has been placed upon the grapple swing mechanic within the game. This is because this mechanic has many smaller aspects to it which must be combined in order for it to be successful and feel good. Because of this I have broken the tasks down into smaller segments which once combined will result in a fully functioning grapple swing. Last week I attempted to make a grapple hook purely by applying forces to the player in the direction of the grapple hook through code. This worked in the fact that it connected the player to the grapple point however, the movement felt very bouncy as the player would move further away and closer depending on the forces applied. This did not feel like an ideal way to connect the player to a grapple and as a result I have decided to rework it.
In order to overcome this problem, I attached a spring joint component to the grapple point and set the player as the connected body. I then reduced the elasticity of the spring joint in an attempt to remove the bounciness. This worked fairly well however the swinging movement was still fairly jittery and bouncy. To solve this, I had to set the maximum and minimum distance of the spring joint to be the same value which then removed all jittering and bounciness as it essentially maintained the distance between the player and the grapple point. This allowed for a much smoother swing visually much like the grapple swing which can be seen within Ratchet and Clank. I now needed a way to connect and disconnect the player from any particular grapple point whilst the game was running so that the player could determine when to grapple. To do this I added a trigger sphere collider to the grapple points and created a script to handle all grappling related tasks. In this script I set up a list of game objects which would hold all of the grapple points within the players range at any given time. These points would be added and removed whenever the player entered the trigger sphere of a grapple point. I then wrote a function to cycle through all available grapple points in the list and calculate the one which was the shortest distance away from the player’s model. This essentially set up the basic implementation for deciding if a grapple was possible as well as which point should be grappled to. The next step was to check whether the player was holding a specified “grapple” button to determine whether the player was attempting to grapple. It is now set up to connect the player to a grapple point and maintain that connection until the player releases the grapple button. This works by setting the player as the spring joints connected body through script. I also had to set the minimum and maximum spring distances in script to be equal to the player’s distance from the grapple when engaged to create a smooth transition. Now that the player could easily connect and disconnect from a grapple at any time the next step was to create the “rope” or link which would be the visible connection between the player and the grapple point. Juan and I were also able to improve the flexibility of the physics based arms from the prototype during the week which now allowed them to stretch without causing the model to break. This stretchiness is what I used to create the link between the player and the grapple as I essentially lerp the players arm towards the grapple point when attempting to grapple and then lerp it back to its starting position when ending a grapple. This created the effect of a connection between the player and the grapple point and made it look as though the player was swinging. This worked great however I then needed to ensure that the players rotation matched the angle of the current swing as it looked very odd to simply have the character maintain his rotation through the swing. To do this, I rotated the players model whilst grappling to face the direction of its current velocity vector. In this way, the model would rotate accordingly throughout the swing on the grapple hook giving it a much more realistic look and feel. I also added the ability for the player to control the movement of their swing to a certain extent by applying forces onto the character based upon the input from the controller’s joystick whilst grappling. This allowed the player to control the direction and size of their swings. Finally, I improved the way in which the grapple determines which point the player is trying to grapple to by adding another check into the selection process. Now instead of just choosing the closest grapple to the player the script will prioritise grapple points which are within the players view before calculating which one to grapple to. This is done by calculating the grapple points which are within the cameras field of view and storing these in a second list of grapple points which is prioritised over the standard points that are not in view. This works very effectively as it now allows the player to have complete control as to where they will be grappling even if the ranges for points do happen to overlap. The combination of all these tasks has led to a grapple which now not only feels good and is easy to control, but also visually gives the effect and feedback that the character is swinging. During the week, I also added the ability for the player to walk across wires/beams without falling off. This works similar to the rope walking within the game Sly Cooper. This will be useful in the later stages of our development when we design levels and different ways to traverse them. The system currently works by locking the position of the player to the top of the wire when walked on and then rotating the players model to face the direction of the rope. Movement on the rope is based upon the cameras forward direction so that the player can easily move along the rope no matter where the camera is located. When moving the player can only walk in either direction of the rope and cannot fall off. The players model also rotates towards the end of the rope that the player is walking towards and switches if directions are changed. I have also added the ability to jump whilst on the beam which disengages the beam walk. At a later stage once the new character is in the game we will be able to make separate animations for these tight rope walks. The current implementation of the beam walk can be seen below. Within the first week of development the team focused on discussing the future for the game and the expected result or outcome for the end of vertical slice. After discussion we quickly realised that the state of the prototype was respectable however, it lacked the replayability factor which would allow for longer periods of play. The game seemed to lose its “fun factor” fairly quickly after a few rounds of playing and this was an issue which needed to be addressed. As a result, we decided to try and add some form of storyline to the game in order to give it a purpose and meaning. We will now place a heavier focus on the stealth aspect of the game as opposed to the random stealing within the game. We also chose to incorporate the ability to jump and use verticality as another method to avoid guards. The reason for this is because having the player locked to the same height throughout the game seemed very restricting. Incorporating verticality into the game will allow for more diverse gameplay and mechanics to be developed. The current character will also be replaced with a new revamped character which would be more memorable to the player and suitable to the new theme/story. This character will have one normal arm and one robotic arm which will be used as a “gadget device” within the game. Some of the possible gadgets or uses of the arm will include the ability to stretch and grab objects, grapple to higher points and swing between grapple points above the ground.
During the week, I reworked most of the code used for the object interaction and picking up of objects within the game. This is because there were many bugs with the current implementation such as the ability to pick up objects through walls as well as the issue with objects not removing their highlight once out of their interaction range. To fix these issues I firstly included a check to see that objects were not behind walls using a ray cast from the player to the object within the player’s range. If no walls were hit along the path, then the object is indeed in the player’s view and possible to pick up else the object will be classified as behind a wall. I also included a list of objects within the players range and used a specific function to remove highlighting from objects which were removed from the list. These fixes optimised the object interaction within the game and it now functions as it was intended to originally. I have also added the grounded check for the jump mechanic which Zac Implemented. This now limits the player from jumping whilst i the air. Because AI plays a large role within our game we also decided to incorporate the use of sound as a way for AI to be alerted as opposed to just sight. We are currently working on a unity stealth plugin which will be utilised within our game to make the pathing and AI system much easier to control and set up. I have now incorporated basic functionality for AI to “hear” sounds within the plug in. The way in which this is handled is through the use of a “generate noise” function which allows us to generate a noise at any specified location with a specified volume. Each AI now has a sound detection range which is indicated and manipulated using a wire sphere surrounding them. I have also added the simple functionality to manipulate sound occlusion for the AI by selecting how many objects/walls the sounds can be heard/detected through. In this way, we can determine and set the number of walls each AI can hear through individually. This set up makes the noise detection easy to set up and use and provides the functionality to make AI with different detection difficulties in the future. During the week, I also began working on the new grapple mechanic which is to be implemented into the game. I have researched and tried various methods of implementation however have been unable to create a grapple swinging effect which feels good and is easy to control. As a result, I will flesh out this mechanic within the week to come. |
AuthorContrary Scholars ArchivesCategories
All
|