Placeholder Team Name has finished its second sprint for Roto-Rescue and it went amazing! Our velocity has increased, we've found more directions to take our game, all while suffering some fun setbacks, meaning our team can withstand stress! I am Liam O'Hare, the game designer, assistant programmer, and an artist on this team. My team includes Jonathan, our artist and producer, Pablo Vazquez, our programmer, and Patrick Yang, our level designer.
I especially had a lot of fun this sprint, mostly because I was able to get and watch so many important tasks become complete. With each new features I found new routes to take our game, and as I predicted, it was pivotal that these cards were completed early for us to playtest and find our game's fun! So while I'll be discussing my own work here today, a lot of my work is also based on the team's progress in total because all of our work accumulates to me finding the fun in our game.
Firstly the playtest for our paper prototype went very well. We gathered lots of useful data, pinpointed some critical areas of game that will need extra attention, and even got some morale boosts. The most valuable data gathered was that players heavily disliked not being in control of the tools they use in a turn and tools that are not properly balanced will hurt the entire sandbox of the game. What this means is this game will likely require a honed attention to the dichotomy of player tools and the level sandbox. If favor tilts too far to one side everything comes crashing down. In other words, the player needs to be powerful, but the environment can't be too weak. This is where the crux of this game's fun lies, at least for now.
Personally I focused on scripting sandbox elements of the game rather than player controls and tools. Firstly I tackled
destruction, which wasn't difficult but had a good amount of scaling and physics bugs to be solved. I personally prefer tackling critical bugs like this early, which is what I did. I wanted to fully understand this system because it was important for me to know what was necessary to make our modular pieces function before we started to fill in art for what are now simply boxes. After this was done I could quickly throw some prop destruction tests together. I'm not sure if the art I made will be used in the final game, since it was more for testing and quickly thrown together, but the point of this card was to prove destructible props were achievable. A destructible table and chairs can be found in the gif above. Additionally I made some heavier props to serve as a bigger obstacle in future levels, such as a safe and a piano. To conserve on performance I
made a quick debris despawn script, which can be thrown on any object we want to act as "destruction decor" that provides visual interest rather than staying in a scene affecting performance. This can be seen to the left, where debris will slowly shrink and then despawn, leaving behind only critical pieces of debris that may still be used for gameplay.
The most difficult script I built this sprint was the goober's health system, which had many interlinking elements. It took me a lot of research and time but finishing this system and watching it work exactly the way I set out for it was very rewarding. The final result was goobers that would take damage from incoming forces applied to each of their body parts (hips, head, left hand, right hand, left foot, and right foot). As a goober takes damage they
lose "blood" which is stored in a variable, and when a goober is collected in our "goob-tube", seen on the right, the player earns points based on blood left in a goober's body. Personally I didn't want to render an HP bar over every goober in a level as I thought it might take our player's focus away from the actual interacting sandbox. I didn't want players having to check little colored bars above a group of goober's heads. My goal was to have a diegetic UI element where a goober's material is instanced and edited, losing saturation as their goober loses blood. So a goober at 100% blood would be a saturated yellow, but a goober at 50% blood would start to look grey and desaturated, both literally and figuratively. Finally, since this system would make it difficult to tell the difference between a dead goober and a nearly dead goober, I will switch a dead goober's material to the shade I've coined as "corpse-blue". I won't detail how difficult this script was for me to make, but I will say I'm very proud of myself for building this system and taking a load off of our main programmer's shoulders to allow them to focus. While there may be a knowledge silo forming in our goobers, as I am the only one who knows how they work, at least we can say our goobers are fully understood by at least one person. Perhaps down the line I can resolve this silo by getting Pablo to work on goobers as well.
Here you can clearly see this damage system taking place. Goobers falling in different places on their body will take different amount of damages, and a safe falling on one of the three unfortunate goobers will instantly crush and kill the goober as they turn corpse-blue (Crayola doesn't recognize this as an official shade though I'm sure you're following). All of these thresholds for force applied are public and editable for our level designer, so technically, a goober's right leg could be made of iron, and their head could be a soft playdough-like substance.
Through Pablo's work in this sprint I quickly found that our rope tool idea, simply put, was too difficult and frustrating to use. I chose to cut this. While this feels like wasted work, I'm glad we have chosen to refrain from making art, especially since the only thing we've lost here was the scripting Pablo and I put into a rope claw. The problem wasn't anything Pablo did in the scripting, the tool was simply a bad idea by me. We've decided to have a claw directly under the helicopter instead, which feels much better. I wish I could have come to this conclusion earlier to save us on work, but the idea for this game was first based upon tools on the end of a rope explicitly, so for me the identity of the game was in this rope. It took about a week for me to realize this delusion was warping my understanding of our game, and I think we've found a much better, less constricting, design for our game. In the future I need to practice freeing my mind from conceptual ideas of a game, and trying to identify what could be limiting the fun and creativity of our game, resulting in me making decisions sooner. Luckily, Pablo was very receptive to the change I made and happy to stop work on the rope claw and replace it with an entirely different idea. I appreciate this so much and it's quite possibly the nicest quality to have in a team member, especially when you feel like you're having to make difficult decisions that won't make everyone happy. This sentiment has been shown by every one of my team members and I can't express how this streamlines my process and eases stress on my shoulders. This has allowed me to achieve so much for our game and continue to push forward.
Additionally, this sprint we had multiple members come down with some sickness, as well as a lost wallet and ID along the way, and so I am really proud to see everyone continue pushing and getting through our work. While I think we can learn to better use our team members for cards in the future to improve our velocity even more, I am proud of our team for staying strong!
Finally, at the end of our sprint one of my professors Dan recommended I put together some pillars for our game, which I though was a super fun prospect and idea. It had been a while since I put together some real pillars for a game, and even longer since I made pillars for a game I was currently building, rather than just concepting. I'm not sure if these are complete and my team and I will refine these in the coming week. However, I believe these pillars will do really well in keeping our team focused on what is important when our game inevitably becomes less exciting to work on. There will be a time where we become blind to our own game and can only understand it through the eyes of play testers, and so its important we write these pillars out and stick to them, especially in the later half of development, so that this game is actually completed.
Balanced Sandbox: Our game’s sandbox, controls, and mechanics are set in the context of a physics-based world. Players should feel that destruction, gravity, tools, fire, and more should be interesting and dynamic enough so that players must experiment to learn to control the environment. However players should never feel overwhelmed or incapable of controlling a distracting and unpredictable sandbox. This balancing act is critical to the game’s fun and success.
Accessible: This game’s controls will be intuitive, the difficulty ramp will be shallow, and players of almost any skill level should be able to enjoy this game. The game will be short and sweet so we shouldn’t expect a lot of respect or focus from players that simply pick up and try the game.
It is fun to lose: Losing conditions should always include something interesting, funny, or unpredictable happening within a level. The player should not lose to the same factors repeatedly. Instead players should feel the game throws more situations and circumstances at them that are new and couldn’t have been predicted. Additionally, many levels should use drama, setting, and stakes to add a thin layer of narrative and humor in each level. An example would be a family of goobers having dinner next to a warehouse filled with explosives. This way, when players are forced to experiment with our balanced sandbox, at least they get a laugh and spectacle when they lose a level.
Replay-able: Our game is accessible so that new players feel they can progress quickly and see everything this game has to offer without getting stuck, frustrated, or bored. However, our game includes a completion score reminding players that they can always do better. To “three star” a level in this game will be no easy feat, thus giving our more dedicated players a fun challenge to strive for. To 100% a level players should be required to show skill and understanding of our sandbox rather than get a lucky run.
Overall, lots of things were learned in this sprint and I'm excited for the next one, here's a sneak peak at what you might see me working on next sprint:
コメント