Sprint 4: Spastic! Terror!
What an absolute monster of a sprint, with a damp squib of an ending.
The majority of my focus on the sprint was to wrap up character controller improvements and implement later-stage changes to the game design document. Over the course of Sprint 3, we realized that our game didn't have enough compared to both other people's projects and in terms of a unique movement mechanic. This was problematic, and we set out to make new cards in order to remedy this issue. We decided to slowly drop the idea of a fruit-based golf game and instead focus on what testers actually enjoyed; jumping and moving around freely. As it turns out, players don't like arbitrary limits that strangle their ability to play the game how they want.
Switch statement for fruitswapping.
There was some struggles with this approach; Unity really does not like changing rigidbodies, and my initial approach to this problem was doing exactly that. Instead, I realized that I have to change the radius of the rigidbody already present on the player. Swapping mesh filters and materials was trivial. Overall, my goal of creating a fruit-switching system that would be easy to debug, design for, and playtest was reached.
But we didn't playtest. Part of this was my fault. Everything I put into prefabs worked well in my test scene, however, I didn't design them so that they'd be easy to pull from prefabs and into the levels. This was problematic, needless to say, when we received the first draft of our level late at night and I was scrambling to get everything in. What happened was genuinely tragic. We ended up with an arrow that was scaled to be miniscule compared to the fruit, the levels proportions didn't match the physics of the fruit at all, and the ground slam (AKA, the one thing I finished that allowed for jump precision) was so strong that it'd launch the player directly into the ceiling when used.
Additionally, the playtest revealed severe issues with the control scheme as it was. The initial plan of having players 'lock in' in order to charge from a standing still position started to fall apart when people started to actually use it. The reality was that this system, when it worked, limited what players could do. When it didn't work, players found themselves locking up arbitrarily. The reality was that it was entirely too clunky to work; and with no signposting or control scheme guidance? Forget about it. It's Resident Evil Tank Controls for jumping.
My current goal is to turn the level we have into the best thing it can possibly be. Additionally, I'm planning on polishing the player controller, removing the need to stay still and toggle to a 'jump mode'. Just let the player move and jump, Jesus Christ. Finally, since I heard my group leader is planning on releasing a level 2, I'm aiming to avoid a repeat by making all of my prefab components decoupled from each other, allowing us to add them to the scene on an as-needed basis to test them individually.
The majority of my focus on the sprint was to wrap up character controller improvements and implement later-stage changes to the game design document. Over the course of Sprint 3, we realized that our game didn't have enough compared to both other people's projects and in terms of a unique movement mechanic. This was problematic, and we set out to make new cards in order to remedy this issue. We decided to slowly drop the idea of a fruit-based golf game and instead focus on what testers actually enjoyed; jumping and moving around freely. As it turns out, players don't like arbitrary limits that strangle their ability to play the game how they want.
Freedom!
Over the course of sprint 3, and into sprint 4, we worked on providing more options to the players, allowing people to make a more precise jump using the ground slam ability, creating a charge arrow to indicate direction, and adding keybinds to change how the controls worked. A vast majority of my time was devoted to making sure the fruit switching ability worked. How I decided to do it was simple;
The only things we had to effectively change to turn a fruit into another fruit was the rigidbody, the material, and the model. In order to make this as easy as possible to fix, I turned the fruits into scriptable objects that swap properties with the players current model whenever they decide to switch fruits. This was assisted by an enumerator to maximize readability, and finally a switch statement that changes the players properties on collision with the fruit towers that Andy modeled.
Fruitswap 1.0
The only things we had to effectively change to turn a fruit into another fruit was the rigidbody, the material, and the model. In order to make this as easy as possible to fix, I turned the fruits into scriptable objects that swap properties with the players current model whenever they decide to switch fruits. This was assisted by an enumerator to maximize readability, and finally a switch statement that changes the players properties on collision with the fruit towers that Andy modeled.
Switch statement for fruitswapping.
There was some struggles with this approach; Unity really does not like changing rigidbodies, and my initial approach to this problem was doing exactly that. Instead, I realized that I have to change the radius of the rigidbody already present on the player. Swapping mesh filters and materials was trivial. Overall, my goal of creating a fruit-switching system that would be easy to debug, design for, and playtest was reached.
The code to actively switch fruits.
Additionally, I was to work on necessary parts of the level; I ended up creating an acceleration track to assist in platforming, by giving the player a way to boost their horizontal speed. But we didn't playtest. Part of this was my fault. Everything I put into prefabs worked well in my test scene, however, I didn't design them so that they'd be easy to pull from prefabs and into the levels. This was problematic, needless to say, when we received the first draft of our level late at night and I was scrambling to get everything in. What happened was genuinely tragic. We ended up with an arrow that was scaled to be miniscule compared to the fruit, the levels proportions didn't match the physics of the fruit at all, and the ground slam (AKA, the one thing I finished that allowed for jump precision) was so strong that it'd launch the player directly into the ceiling when used.
This just rams you into the rafters like you're a pigeon at Costco in the current build.
The playtest, in a nutshell.
Comments
Post a Comment