Brawl Bunnies

DESCRIPTION

Brawl Bunnies is a class-based soccer game inspired by VIDEOBALL, designed for 2-4 Players offers exhilarating 1v1 or 2v2 action.

ROLES AND TASKS

During the Development Cycle of the game, I acted as a Game, Level and 3Cs Designer as well as taking the Role of the Scrummaster. I worked on Ideating and implementing the core parts of the Level Design and the Camera Manager.

Designed and Implemented Camera Manager
Worked on getting proper measurements for every single asset for the game
Designed and Scripted Game Feel Mechanics for Characters
Handle Player Playtests and Documenting Feedback as well as making Iteration Documents
Made Design Documents to Align the team to a Singular Vision

The BRIEF

We were tasked to recreate Tim Roger’s Videoball but with our own Twist. We decided to make the game 3D with a Slanted Camera Angle as well as add Character Classes and Abilities which the player can choose at the start. This would allow us to add more depth to the gameplay as well more Player Expression and Freedom.

I made a Feature Spec for the Original Game, Laying out the MDA Framework for VideoBall, as well as the Added Mechanics for our Game.

Getting the Basics Right

One of the few things I wanted to avoid :- "Scaling Assets in Engine."

To work around this, I set up a blockout with proper metrics which would be then given to the artists, this way we wouldn't have issues in the future whether it's with physics or lighting.

I made the blockout of the stage as well as the Characters with a Final Camera Position.

Early Iteration Sketches

I started sketching out some concepts of possible arena variations we could have. As well as started blocking them out in the engine to get a feeling of the scale.

Design Sketches

To get the entire team on board, I made a bunch of Design Sketches instead of writing down a GDD to finalize all the design sketches on paper.

My intention was to make the sketches as readable as possible, so that even a Non Designer would get the jist of how everything works.

These Sketches ended up being the go–to explanation, and every mechanic, vfx, animatrion implemented in game followed the Sketch.

Camera Manager: Design and Implementation

My Aim with the Camera Manager was to make it modular and scalable.

Since we initially intended to have multiple maps, it should be as easy as to just drop it in the map, and then tweak the values in the editor to make it work.

Basic Still Camera

Dynamic Camera

The Design for the Camera Manager was similar to how it works in Super Smash Bros Ultimate.

The Camera zooms in and out based on the player distance, as well as pans left and right based on where the average position of all the players is situated.

The Problem

Since the game supported 2-4 players, the Camera Manager had to work in all scenarios 1v1, 1v2 and 2v2

There was an issue in 2v2, since the Camera Zooms worked based on Player Distances,

The initial plan was to use the average location for each team of 2 players, but based on how players move in game, this would lead the Camera to not zoom or pan at all.

The Solution

This was fixed with switching to a “Farthest Player System”, Instead of averaging location for all 4 players, the Camera Manager would instead only look for the farthest players in the XY Distance.

Final Camera Manager Blueprint

Playtests

Throughout the Development of the game, I conducted multiple playtests with 30+ people

After the Playtests, the playtesters would answer a specific set of questions which I would note down, I would also write down some observations by watching them play the game.

I collated all of these into a big Feedback Document, noting down multiple possible solutions based on them, which would then be shared with the entire team for further discussion.

These Playtests Collated to Multiple additions to the game such as

Knockback Indicator

QuickShots

Dynamic Camera

My Role And Responsibilities as Scrummaster

I took over the role of Scrum Master from Week 3 to Week 8 of production.

During this period, I ran the Daily Standups, Sprint Reviews, and Retrospectives, and I was responsible for managing the KanbanFlow board.

I also met with each discipline to help streamline their workflow for the sprint, track progress with burndown charts, and ensure the team stayed aligned and on schedule.

Reflection

Overall, I'm very happy with how the project progressed. Although I originally joined as a Level Designer, I ended up taking on multiple roles across Systems, 3Cs, and General Game Design due to various needs within the team.

This was also my first time working closely with artists, understanding what they needed from the project, and creating documents and metrics to support their workflow so they could continue their work smoothly.

This project was a major boost to my skill set, especially in building scalable systems and managing scope for the entire team. It pushed me to learn quickly, adapt to new responsibilities, and contribute across several disciplines.

Home