What is Robot Rocket Rumble?

Robot Rocket Rumble is a 2D arena party-brawler game where 4 players vie for dominance and to be crowned the Robot Rocket Rumble Champion by blasting their opponents out of the arena with rockets and powerful ultimate abilities.

Robot Rocket Rumble was prototyped in DigiPen's proprietary Zero Engine and developed in a custom C++ engine as my sophomore project at DigiPen Institute of Technology. It was devloped by a team of 11 students consisting of 5 programmers, 2 game designers, 3 artists, and 1 sound designer.


What Did I Work On?

I worked on Robot Rocket Rumble for both of its semesters of development as the gameplay designer, level designer, and user researcher.

As gameplay designer:

 - Designed ultimate move system and ultimate powers to appeal to a wide range of player archetypes and play styles. 

 - Collaborated with programmers to create physics-based combat, tight movement, multiplayer camera systems and pipelines for efficiently iterating on them

 - Rapidly prototyped game mechanics during pre-production leading to major gameplay shifts and solved usability issues.

As level designer:

 - Created level design guidelines to emphasize all ultimate abilities and create key points of conflict to maximize player engagement.

 - Designed arena levels and brought them from paper prototypes through full implementation in custom engine.

As user researcher:

 - Conducted usability tests on control systems leading to significant improvements in ease of use and satisfaction for players.

 - Moderated group playtesting and data collection to create heatmaps, design briefs, identify bugs and lead data-driven design changes.

 - Created unbiased tracking data across development to see if we're matching design goals


What Did I Learn?

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.