CAGD 370 - Postmortem
We have reached the end of the Final sprint, and with it, we have our last version of the prototype for the game "Ooze." It is fantastic to look back and see how much we have learned during these three months of prototyping development. At the start of the development process, we wanted Ooze to be a physics-based puzzle game. We started laying down what we would need for the game to work. As the assigned programmer, my job was to implement the game mechanics to the game.
On Sprint 1, I focused on getting some of the basics done. I started with the most essential thing, the player, and the first challenges that came with it. Before this project, I used methods in the Update Function to get the keys to make the character move. For this project, I wanted to learn new skills and ways to approach character movement, and while doing some research, I found the new Unity Input System.
This new system allowed me to use some dynamic callbacks to get the player input, which could later be translated to controller input if that was the direction in which the project drifted. With the basic movement done, I started working on the third-person Camera, and with it came my first roadblock. I needed the Camera orientation to control the player movement script so the forward direction would be wherever the camera was facing. I did my third-person camera script. After reviewing some references, I achieved player movement based on the camera orientation.
I last worked on the moving platform that interpolates between two set points. To achieve this, I researched linear interpolation, its meaning, and how to apply it in the Unity project. The moving platform allows the player to be on top of it, and the player's movement would be relative to the platform movement, meaning that the player does not have to follow the platform while the platform is moving.
On Sprint 2, I focused on more interactables that would work as a tool for the level designers to do puzzles. My first instinct was to use the Unity physics system to move the box. However, this caused some bad collisions between the player and the box, and sometimes, the box would fly away after colliding with the player. To solve this, I made a quick script that would add force to the box in the direction the player is colliding with it. This solved the issue, and the box moved flawlessly.
Checkpoints were one of the things I was most excited to implement in the project since I wanted to make it modular, meaning that you could add as many checkpoints as needed, and those would be included in the script. I made a parent gameObject that would hold all the checkpoint prefabs, and then anything inside would be the order of the checkpoints, with the top of the inspector being first and the bottom being last. Once the game starts, the Checkpoint Manager will loop all the children's Checkpoints prefabs in the checkpoints game object and assign them to a list. With the respawn done, I did a DeathVolume to make the player respawn to the last active checkpoint.
Sprint 3 was very nice for developing more tools that the level designs could later implement and polishing some old ones. I added a material change for the checkpoints that would work as a visual representation that the checkpoint was reached. I also added a pressure plate and a door that would be connected to the pressure plate. Finally, I made a quick main menu, allowing the player to start on the level. Overall, it was a quick sprint, and I was able to polish a bunch of mechanics already implemented in previous Sprints.
Sprint 4 was one of my favorites because I learned a lot of things. We had a playtest in which players found out that if the camera collided with an object, it would go outside, so after a lot of research, I got to add that the camera zoomed to the player if it was obstructed. I also made it so that the previously added movable box could now be picked up and held in front of the player. Another thing that was pointed out to us during the playtesting was the mouse sensitivity, so a pause menu was added, and many options with it, including x and y sensitivity and invert the x and y mouse inputs. Finally, a Death Counter was added to make the player keep track of how many deaths it had on the level.
Along with the development of Ooze, many things went right. We were always on schedule, and thanks to our Trello Board, we were able to be easily organized and keep track of the work being completed for the game.
A couple of things went wrong, including one of the team members dropping the project, and we had to re-adjust some of the distribution for the project to be completed by the deadline. During development, we wanted the Ooze to be a Softbody object, but there wasn’t much documentation, so the idea was dropped. Finally, many mechanics were worked on and didn’t make it to the final game because there wasn’t any place to implement them.
The Ooze project helped me better understand how a team works under the Agile Framework and Scrum. It was a very efficient way of managing a project and distributing work among the project members. Doing Standups helped get the team centered on what each person was doing and how much work they had completed during each sprint. It has been an incredible experience, and a lot has been learned about the structure of a project and using many new Unity-provided features to enhance the project. Finally, this project wouldn’t have been the same without my group members, who were great at understanding each other’s situations and being flexible with the meeting hours. Also, fantastic Leadership from our Team Leader.
Ooze turned out to be a fun physics-based puzzle game.
On Sprint 1, I focused on getting some of the basics done. I started with the most essential thing, the player, and the first challenges that came with it. Before this project, I used methods in the Update Function to get the keys to make the character move. For this project, I wanted to learn new skills and ways to approach character movement, and while doing some research, I found the new Unity Input System.
This new system allowed me to use some dynamic callbacks to get the player input, which could later be translated to controller input if that was the direction in which the project drifted. With the basic movement done, I started working on the third-person Camera, and with it came my first roadblock. I needed the Camera orientation to control the player movement script so the forward direction would be wherever the camera was facing. I did my third-person camera script. After reviewing some references, I achieved player movement based on the camera orientation.
I last worked on the moving platform that interpolates between two set points. To achieve this, I researched linear interpolation, its meaning, and how to apply it in the Unity project. The moving platform allows the player to be on top of it, and the player's movement would be relative to the platform movement, meaning that the player does not have to follow the platform while the platform is moving.
On Sprint 2, I focused on more interactables that would work as a tool for the level designers to do puzzles. My first instinct was to use the Unity physics system to move the box. However, this caused some bad collisions between the player and the box, and sometimes, the box would fly away after colliding with the player. To solve this, I made a quick script that would add force to the box in the direction the player is colliding with it. This solved the issue, and the box moved flawlessly.
Checkpoints were one of the things I was most excited to implement in the project since I wanted to make it modular, meaning that you could add as many checkpoints as needed, and those would be included in the script. I made a parent gameObject that would hold all the checkpoint prefabs, and then anything inside would be the order of the checkpoints, with the top of the inspector being first and the bottom being last. Once the game starts, the Checkpoint Manager will loop all the children's Checkpoints prefabs in the checkpoints game object and assign them to a list. With the respawn done, I did a DeathVolume to make the player respawn to the last active checkpoint.
Sprint 3 was very nice for developing more tools that the level designs could later implement and polishing some old ones. I added a material change for the checkpoints that would work as a visual representation that the checkpoint was reached. I also added a pressure plate and a door that would be connected to the pressure plate. Finally, I made a quick main menu, allowing the player to start on the level. Overall, it was a quick sprint, and I was able to polish a bunch of mechanics already implemented in previous Sprints.
Sprint 4 was one of my favorites because I learned a lot of things. We had a playtest in which players found out that if the camera collided with an object, it would go outside, so after a lot of research, I got to add that the camera zoomed to the player if it was obstructed. I also made it so that the previously added movable box could now be picked up and held in front of the player. Another thing that was pointed out to us during the playtesting was the mouse sensitivity, so a pause menu was added, and many options with it, including x and y sensitivity and invert the x and y mouse inputs. Finally, a Death Counter was added to make the player keep track of how many deaths it had on the level.
Along with the development of Ooze, many things went right. We were always on schedule, and thanks to our Trello Board, we were able to be easily organized and keep track of the work being completed for the game.
A couple of things went wrong, including one of the team members dropping the project, and we had to re-adjust some of the distribution for the project to be completed by the deadline. During development, we wanted the Ooze to be a Softbody object, but there wasn’t much documentation, so the idea was dropped. Finally, many mechanics were worked on and didn’t make it to the final game because there wasn’t any place to implement them.
The Ooze project helped me better understand how a team works under the Agile Framework and Scrum. It was a very efficient way of managing a project and distributing work among the project members. Doing Standups helped get the team centered on what each person was doing and how much work they had completed during each sprint. It has been an incredible experience, and a lot has been learned about the structure of a project and using many new Unity-provided features to enhance the project. Finally, this project wouldn’t have been the same without my group members, who were great at understanding each other’s situations and being flexible with the meeting hours. Also, fantastic Leadership from our Team Leader.
Ooze turned out to be a fun physics-based puzzle game.
Comments
Post a Comment