A Retrospective on Rockin' Racket

The Concept

When I was introduced into Rockin' Racket, the game had been in the design process for a few months already. At the time, details were still a little unclear, but the majority of the foundational elements had been cemented as follows.

The game follows a college applicant raccoon named Harvey, who is looking for extra-curricular activities to improve his chances of being accepted into college. His little siblings have formed a band, Rockin' Racket, and in a ploy to improve his applications, Harvey offers to be his siblings' band manager.

The core gameplay revolves around concert sequences, where the player character, Harvey, must complete mini-games to maintain and increase the band's performance score. Between concerts, you discuss with your siblings future plans and work on improving your equipment to make future concerts more profitable and go over smoother.

The Team Dynamic

Rockin' Racket has been an informative and amazing experience in learning the development process for a full scale game collaborating with 10+ other developers and designers.

I felt that the dynamics amongst team members were relaxed but motivated, creating an environment where individuals did not feel stressed about their tasks, but more incentivized to do the best work they could.

Another important and beneficial aspect of our team mentality was that it was "our" game, as opposed to one person's "my" game. The distinction here is important, as it allowed every developer to propose suggestions and changes without fear, and this made each developer more invested in the final project, creating an environment where we all wanted to put our best work out there.

The Development Process

The original design build was not scalable to the hoped final project, so the original framework for the game was constructed over the summer by another programmer, Kevin, who felt motivated to delve into the basic system structures for the overall game.

From this framework, we were able to continually build onto it, creating inventory systems, cinematic transitions, mini-games, intermission sequences, dialogue sequences, and more. Each of the 4 programmers selected a focus area to develop into the game, and mine was the dialogue system, specifically focusing on Ink file integration since that is the dialogue sequencing structure the Narrative Designer was familiar with.

Each programmer worked in their own scenes, and we established feature relevancy, as in we determined what aspects of the design would affect each person's designated areas. Elements such as "current hub level" and "most recent concert score" affected dialogue.

After the dialogue was well developed, going through iteration after iteration, I ended up moving to work on background art, as the art necessity for a visual novel-like game is rather high, and based on the amount our team had been able to produce at that point, I used my hobby to help supplement necessary game art to ensure a sufficiently polished final project, as at this time it would have been more pain than benefit for me to help implement the systems the other programmers were working on.

Eventually, the project moved to the point where we had a working semblance of a game, and it was at this point that we started working on making more emphatic dialogue interaction sequences, meaning I was back to developing on dialogue. This time, I worked with the Narrative Designer to develop Ink-based tag systems for displaying different emotions for each character.

After, I went back to working on backgrounds and the "hub" system, where the player could move through the house and talk with each of the siblings.

Towards the final weeks of development, we implemented the image system for cinematic sequences, which used the Dialogue system with a modified component that gave the cinematic sequences before and after every concert more personality and life.

Design Successes

While I have thus far mostly detailed my work, the overall game had some very interesting and exciting concepts.

One of the most interesting aspects of this game, is that a large focus is actually on the music, which our composer, Nick, did an exceptional job on. The style of beep-speak him and the sound designer were able to come up with is a unique style that sets our game apart from others.

Another success is the contrasting intensities during a gameplay cycle. Usually, management style games operate on a consistent slow pace, meanwhile this game worked to create periods of high intensity within the concert, and then periods of low intensity between concerts. These disparate periods create the necessary contrasting intensities that helps make a game interesting.

The team dynamic and open discussion allowed within the team helped to create more interesting and developed wholistic scenes, such as the character's bedrooms. The posters are parody of specific aspects of pop culture, and it was only through open discussion that we were able to develop the character interests that would guild their interests.

Design Failures

While this experience was very positive, there were still areas that could have been improved given more time.

To start, the narrative was restricted to approximately 8-9 conversations per character, and 8 cut-scenes. This limited pool of mostly optional dialogue meant that the arc of the story had to be rushed, making some of the jumps between areas seem sudden, and character transitions lackluster.

There was also a significant over scoping problem. At the onset, the idea was to have 5 levels, and dynamically updated systems that would have required 3 different systems all interacting and updating each other and significantly more art than we were even able to produce.

While the team dynamic was incredibly relaxed and made anxieties low, there was a consistent plague that kept causing issues: communication between designers and programmers. Only the programmers were actively working in Unity consistently throughout the development cycle, and so often we would perform our tasks, and then be confused on what to do next. There was also an added issue where there was no designated art asset implementer, meaning that whoever's system had new art asset was expected to import it, however it was often not in written communication that the asset was in cloud storage.

Final Thoughts

Overall, through both its failures and successes I am proud of what myself and this team were able to do with Rockin' Racket.

There may have been persistent issues that caused some trouble, but the teamwork and friendly nature made problems always seem solvable.

I found myself asking how to push aspects further, rather than shying away from bringing on more work, and the issues we may have had have only informed myself and the team on how to mitigate them while moving forward.