What is Robot Rocket Rumble?

1) Talk about and resolve issues as they come up. During the first milestone as our team formed, I and the other designer on the team who was also serving as the producer were upset with each other. Essentially, they were not doing the design work they said they would, causing me to have to pick up the slack late in the week, because they were doing a lot of work as the producer. This caused them to be upset with me as I was having to do their designated design work, which they found more enjoyable. This issue was resolved when I asked to have a 1:1 sit down with them and talk about what was going on. This led to switching what design work we were doing, moving them away from tasks that would block other members, and planning out an additional week in advance what would need to be done so I could get ahead of any delays before they happened without taking their current work out of their hands.

​

2) Prototype fast to find flaws. Robot Rocket Rumble was actually started as a game called ElectroSwing which would be a similar game but with grappling hooks and dashes instead of rockets. We pivoted away from that game, changing our core mechanic, when we found that it wasn’t working well. Basically, with enhanced movement and grappling hooks, it would be near impossible to have consistent and satisfying collisions without constraining the grappling hook mechanic heavily. At that point, we did some quick testing and found that without the free and fluid movement, the grappling hook didn’t feel nearly as good to play with to justify shoehorning it in as our core mechanic. 

​

3) Don't be afraid to break convention. In addition to early testing changing our core mechanic, it also changed our control scheme away from the standard convention. As our game was designed to be played on controllers, we had to carefully consider and examine how the player would use their fingers and thumbs when playing the game. Normally in 2D games, the A button (X on Playstation) is used for jumping, but that means the right thumb cannot also be using the right stick to aim to shoot their rockets. To solve this problem, we playtested moving “Jump” to the left trigger and players found the game instantly more responsive, more enjoyable, and that they had better control over their character.

​​

4) Understand how to maximize everyone's time. As this was made in a custom engine by a team of sophomores, we all weren’t fully sure what we were doing or should be doing all the time. At this point in the degree programs, programmers hadn’t had to build custom tools for non-programmers before and designers hadn’t worked outside of professional commercial engines like Unity. Obviously if the programmers were to spend all their time on tools, core parts of the engine and game wouldn’t get made, and if no time was spent on tools, the iteration loop for designers would take so long the game would be awful. To solve this we took the approach of looking at what parts of the game would need the most iteration, how we could speed that up, and how speeding that up could be done with a low cost to the programmers. For example, rather than implement a curve editor for how much additional knockback a player takes based on how much they’ve been damaged, I made curves in Google Sheets and we took points from that curve and drew straight lines between them. This matched the curve close enough but being able to linearly interpolate between the closest two points was much easier to implement. This easy-to-implement solution took iteration time from 15 minutes to 30 seconds and took about two hours to implement, bug test, and fix.