CAGD 370 - Goo Game Sprint #2
Continuing with the Goo game, we were told to make a signature move for the Goo Character, so my team started brainstorming what would make the most sense for Goo to be its special ability, and we ended up with two main ideas that we wanted to implement which where climbing through sticky walls and gliding down. But in order to develop that movement, we needed some of the more basic and core mechanics down for that to start development.
For my part, I began to work on a movable crate that the player would be able to move around the level and use it to hold pressure plates to make progress. At first, I thought a normal 3d Rigid Body in the player and the Box would be enough to make it move since there was a normal collision. However, I couldn’t have been more wrong about this theory; once they collided, then the crate would be launched outside the level. There was a player visor in the Character model that had a collision, which caused the crate to fly far. Once that was removed, the collision was better but still not what I was going for, so I decided that a script was probably the best approach to move the crate smoothly. After testing for a while, I figured out that if you took the player-looking direction and added a force to the crate in that direction while the player collided with it, you could achieve “smooth pushing”.
Along with the crate being pushable, I needed a way to make the crate respawn if the player managed to push it outside the map. That was fairly easy to achieve; I added a Death Volume at the bottom of the map so that if the crate entered, then it would be teleported to its starting position. But this came with a problem: the crate would keep its momentum for when it was falling. The fix was once the crate was teleported, freezing and unfreezing it, and all its momentum would be gone.
Another mechanic that I had to implement was the respawning mechanic of the game; now, there were various things that I wanted to achieve with the respawn. The player should be able to grab a respawn but not be able to grab a previous respawn. Using the death volume for the crate, I managed to make the player have the same behavior; when touching the trigger, it will be teleported to its last checkpoint. To do this, I made a parent game object that would be the master checkpoint class, and it will count and assign all its children to a List in which they would be in order from top to bottom. Once in the list, we would check the order when the player collides with it and check if it's a new checkpoint or a newer checkpoint. To my belief, part of a puzzle game is trying to achieve shortcuts, so I made it so you can skip checkpoints. Finally, the checkpoints were turned into a prefab for the designer to place them.
Overall, this sprint was very productive; we were able to work further on the core mechanics of our game that will later be used for the level design. My partner in this project also managed to make the climbing work and added a crane asset that the player was able to move by colliding with it. Both of which are very impressive. This project has taught us about pre-production of what a prototype should look like and that these prototypes are less than a minimum viable product; it is to test the core mechanics, just the Essentials. Fantastic work by my teammates, who are up to date with everything in the project.
For my part, I began to work on a movable crate that the player would be able to move around the level and use it to hold pressure plates to make progress. At first, I thought a normal 3d Rigid Body in the player and the Box would be enough to make it move since there was a normal collision. However, I couldn’t have been more wrong about this theory; once they collided, then the crate would be launched outside the level. There was a player visor in the Character model that had a collision, which caused the crate to fly far. Once that was removed, the collision was better but still not what I was going for, so I decided that a script was probably the best approach to move the crate smoothly. After testing for a while, I figured out that if you took the player-looking direction and added a force to the crate in that direction while the player collided with it, you could achieve “smooth pushing”.
Along with the crate being pushable, I needed a way to make the crate respawn if the player managed to push it outside the map. That was fairly easy to achieve; I added a Death Volume at the bottom of the map so that if the crate entered, then it would be teleported to its starting position. But this came with a problem: the crate would keep its momentum for when it was falling. The fix was once the crate was teleported, freezing and unfreezing it, and all its momentum would be gone.
Another mechanic that I had to implement was the respawning mechanic of the game; now, there were various things that I wanted to achieve with the respawn. The player should be able to grab a respawn but not be able to grab a previous respawn. Using the death volume for the crate, I managed to make the player have the same behavior; when touching the trigger, it will be teleported to its last checkpoint. To do this, I made a parent game object that would be the master checkpoint class, and it will count and assign all its children to a List in which they would be in order from top to bottom. Once in the list, we would check the order when the player collides with it and check if it's a new checkpoint or a newer checkpoint. To my belief, part of a puzzle game is trying to achieve shortcuts, so I made it so you can skip checkpoints. Finally, the checkpoints were turned into a prefab for the designer to place them.
Overall, this sprint was very productive; we were able to work further on the core mechanics of our game that will later be used for the level design. My partner in this project also managed to make the climbing work and added a crane asset that the player was able to move by colliding with it. Both of which are very impressive. This project has taught us about pre-production of what a prototype should look like and that these prototypes are less than a minimum viable product; it is to test the core mechanics, just the Essentials. Fantastic work by my teammates, who are up to date with everything in the project.
Comments
Post a Comment