Space Smack!
Role: Producer
Team size: 10
Development time: 4 months
Engine: Unreal 4
Summary
Space Smack! is a 1 to 4 player party game exploding with chaos and sabotage. Enter into the vast expanse of space and clash in a variety of minigames. In this controller-only game, cooperate or undermine your friends to become victorious!
Responsibilities
Ran leads and scrum meetings every morning
Groomed backlog and managed Hansoft kanban
Facilitated communication between disciplines, leads and stakeholders
Managed calendar and deadlines
Settled interpersonal conflicts
Worked with external composers to create sound effects and music
Documentation Samples
1. Paper prototype of Bomb Barrage
2. Concept art of Bomb Barrage
3. Bomb barrage with proxy textures
4. Bomb Barrage
1. Prototype of Magma Mayhem
2. Magma Mayhem prototype playtesting
3. Magma Mayhem Concept Art
4. Magma Mayhem iteration
5. Magma Mayhem
1. First Bridge Blitz prototype
2. Bridge Blitz prototype with proxy textures
3. Bright Blitz concept art
4. Bridge Blitz
1. Mars Mania preproduction flash hack
2. Mars Mania prototype
3. Mars (Moon) Mania iteration
4. Mars Mania iteration
5. Mars Mania
1. Risky Rollers Prototype
2. Risky Rollers concept art
3. Risky Rollers iteration
4. Risky Rollers iteration
5. Risky Rollers
Post Mortem
What Went Right
Honest, direct feedback
Early on, the programmers and designers worked together to create a template that made it easier to implement key features for early prototyping and playtesting of minigames.
The game was demonstrably fun early on, leading to a deeper understanding of what made our game fun.
With the state of the world in 2020, we created new team norms and new ways to communicate to make sure everyone working remotely got the information they needed and still feel like they were part of the team.
Our team liked to have fun while working and our norms reflected that. We created a fun, non-competitive reward system where anyone on the team could give stickers as a thank you or for a job well done. We also kept a Polaroid wall where we documented our experiences through the development cycle.
What Went Wrong
With a small team size, our initial scope was too large. To combat this, we focused on refining and creating variations of them to increase asset reuse.
The team was uncomfortable with Hansoft bug tracking when it was first set up. We did a more thorough walkthrough of the software with the team and answered questions, they were able to pick it up easily.
One or two of the developers would sometimes neglect to look at their work in the game. To combat this, we started including time for everyone to see the game in action together.
About a day before the end of development, we got word from the lawyers that we couldn’t use our game’s name. Marketing assets had to be remade, many files had to be renamed, and all the information on Steam had to be changed. The team was organized quickly and was able to complete the work in time.
What We learned
Quality is better than quantity.
If introducing new software to the team, spend more time explaining and answering questions to cut down on future issues.
Make sure all the developers have time to playtest the game. They can provide important feedback that other playtesters just can’t.
Always have a backup plan, a backup plan, and be prepared to execute it at a moments notice
Space Smack! Trailer
Playtesting
Providing feedback
Playtesting
C30 Playtest
Team meeting
Magma Mayhem
Mars Mania
Bomb Brawl
Risky Rollers
Bridge Blitz