General Information
Game Summary
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.
Key Features
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.
Development Information
Team size: 23
Project Duration: 24 weeks
Engine: Unreal Engine 4
Platform: PC
Store: Itch.io
Project Role and Responsibilities
Main Role : Producer
- Monitoring and managing project risks by maintaining a Risk Log.
- Being the key point of communication within the team, pro-actively helping team members that are blocked or are experiencing issues.
- In collaboration with leads set deadlines and key deliverables and monitor velocity towards these.
- Create and support a remote working environment due to the pandemic. Scheduling weekly meetings and show and tells to ensure team engagement, regularly checking in with people informally to check on their wellbeing.
- Teaching and onboarding the team to use JIRA effectively so that we could employ it to the benefit of the team supporting our agile structure.
- Identifying the strengths, weaknesses, opportunities, and threats to our project by doing a S.W.O.T. analysis on a regular basis. This helped make decisions regarding cutting content and managing project scope.
- Structuring the QA process of the team and Bugfixing by supplying the team with a document structure for that and a schedule for regular QA.
- Communicating with and being the contact point for stakeholders, writing Build Reports on a regular basis to keep them informed.
- Responsible for handling the Agile processes such as sprint plannings and retrospectives to ensure consistent improvement within the team learning from our mistakes.
- Managing project scope and feasibility, cutting content where needed to ensure that we can deliver the intended quality.
- Create an overarching planning for the team so we have a clear view of dependencies and key deliverables.
- Managing the project backlog.
Secondary Role : Level Designer
- Creating the HUB Level which functioned as an interactive menu.
- Collaborating with other designers to make a playspace that would allow for the onboarding sequence, additionally creating a small target practice area to allow people to try weapons out before getting into the game.
- Making an obstacle course with targets allowing the player to get used to and practice the game’s movement and combat. Working together with artists to make assets that supported the level design and made the space visually appealing.
- Iterating on the initial designs based on playtesting, drawing conclusions from analyzed player behavior as well as data.
Analysis and Process
Production Process
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.
Challenges Encountered
- The biggest challenge by far on this project was to deal with the fact that the variations were quite isolated and they weren’t communicating interdisciplinary. Identifying this early on when I joined the team I fixed this issue by having feature teams that were always cross-disciplinary as well as creating internal feedback channels which gave different perspectives on work. This created a natural environment where even though people are working remotely they would regularly involve others in their workflow.
- Another challenge worth mentioning is trying to onboard the team on the value of properly structured QA. As content was getting pushed into builds I noticed an increase in bug reports, after investigating I concluded that a lot of individuals weren’t running their personal QA, and thus untested content was going into the build. I countered this becoming a bigger issue by appointing someone within the team to lead the quality control, filtering out untested content, and not including it into builds until it was tested. This improved our player experience massively as they were encountering a lot fewer bugs.
1st iteration on the Main Room of the Hub Level
End result of the Main Room of the Hub Level
End result of the Obstacle Course
Practice Range to facilitate weapon onboarding
Production Documents
Sprint Retrospectives
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
Risk Log
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
Bug List and QA Plan
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