Sugar blast is a third-person wave-based shooter set in an overrun candy factory! Allowing the player to use multiple dangerously delicious weapons as they fend off wave after wave of enemies. So pick up your boots and soda-jetpack as the monkey-mechanic and shoot your way through the waves of robots as you try to rack up as much score as possible.
Arsenal of Delicious Weapons
Experiment blowing up the Waffle Irons and Baker Bots with an armory full of explosively sweet weapons ranging from bazooka’s to assault rifles. Find a weapon that suits your situation best and blast yourself to glory!
The Flying Monkey
Being the ingenious Monkey Mechanic that you are you have access to your self constructed Soda-Jetpack, allowing you to lift off to get out of tight situations and maneuver your way around the arenas.
The Onslaught of Sweet Danger
As you make your way from one part of the candy factory to the other be ready to fight your way through waves of malfunctioning factory robots.
Joining this project in the production phase there was a lot in the transition from pre-production, with a proof of concept done but some parts of the game loop had not been implemented yet. Identifying this in my first few days I set out to create a planning for the team to get those critical parts of the game loop implemented as soon as possible.
To make this more visible and easier for the variations to communicate what they needed from each other I facilitated them with asset lists for each variation in need of one. This showed the importance of assets and allowed us to prioritize. This also created more understanding between variations and would lessen the number of future blocks people would encounter.
As I prepared the first sprint with the team in JIRA, onboarding them on how we would use the tool we filled up the backlog with the content that was being worked on and what we had planned out to be delivered for the final version of the game. This gave us a good overview and allowed me to start planning out future sprints in a high-level planning fashion, giving us a roadmap to follow. Alongside this I created a Build Release schedule, giving the team visible deadlines on when we had to push a build to our audience and thus had to be in a playable state of quality.
After the first sprint, we caught up on most of the content creation from pre-production whilst still having substantial progress in the areas that had already progressed into working on production content. The monitoring of the team’s velocity showed exactly this although there were a few outliers. I instantly scheduled 1-on-1 talks with them and from an arrangement of issues ranging from personal and professional ones I managed to resolve their issues and improve their effectiveness to the team once again.
During the other sprints, productivity improved gradually which allowed us to get all of our intended content into the game aside from an additional optional enemy in our planning which was scrapped. I managed to keep a close eye on the risks and dependencies and plan countermeasures proactively to keep dangers to productivity from impacting the team. This in turn led to us being able to do a lot of playtesting which improved the overall quality of the game massively.
Level Design Process
Aside from being a producer on this project I also took on the mantle of Level Designer, having responsibility over the HUB Level and the onboarding it should facilitate. Having a base laid down by another level designer in pre-production I started to rapidly iterate on it especially when we got to the playtesting phase, causing massive improvements in the level layout as well as onboarding experience to the player.
The process that I use to do sprint retrospectives is based on Gibbs’ reflective cycle. Going quite in-depth on how the sprint went, both positives and negatives, and how we can improve from there on out. This structure always allows me and the team to generate feasible action points which lead to steady improvement.
Download Link: Sprint Retrospectives
As with all my projects I used a Risk Log to help identify risks to the team’s functionality as well as the project’s feasibility. Having used it successfully on Night Shift I improved on it this project by involving the team to make more entries into it which led to broader risk identification.
Download Link: Sugar Blast Risk Log
The Bug List and QA Plan template that I onboarded the team on allowed us to have a clear overview of all the bugs in our game. With the QA plan being executed better and better as we got closer to release we managed to fix more than 100 bugs within 8 weeks.
Download Link: Sugar Blast Bug List and QA