Beamdown
A case study on the Hack and Slash capstone game
2/3 min read
The game
Beamdown is a 3D Hack n’ Slash action adventure game.
As the senior class of 2025, we were tasked with making a game with a 30+ person team. In this case study, I hope to shed some light on the story of Beamdown, and how it got to where it is today.
Process
Wireframes, User Research, UX/UI Iteration based off playtest feedback, Team Leadership, Documentation, Production Pipelines, Marketing & Branding, Level Design, Game Design, Narrative Design
My Role
Design Lead
Tools
Figma, Unity, GitHub Desktop, Steam
Duration
7 Months
It all started with an idea
Beamdown started as a 2D Prototype. I led the 3 person design team in trying to find our core game loop. We collaborated. We hit the whiteboards hard. We iterated fast.
We got a working prototype, pitched the prototype to a board of industry stakeholders, and hoped for the best.
And then...
A quick scroll through of our design bible
We got greenlit!
We were greenlit by the board of stakeholders, and on we were to Pre-Production! We created documentation. We got a full team of SIX total designers.
What I did during Pre-Production
Wireframes, Documentation, Production Planning, Set up the google drive, Iterated FAST
Length
A month and a half
Pre-Production
We established three design pillars during Pre-Production
As part of our pre production documentation, we narrowed down our design focus to three key design focuses. Each of these focuses informed our decisions when deliberating over a certain system, mechanic, or simple interaction.
Fast, up-close combat
Combat should feel snappy, engaging and fun! On top of that, each planet should inherently lean into a specific combat mechanic we have set aside for ERO 4 (the player). Finally, Augments should improve gameplay and have the player feel powerful.
Each boss should be its own unique experience
Boss design is probably our most important design aspect. The overall UX of Beamdown should solely rely on the players experience with the boss.
Were they challenging? Interesting to fight and look at? Grunts also play an integral role in this experience. They shouldn’t be too challenging, in order to show the player they are powerful, but they shouldn’t be nothing necessarily.
Diverse and hazardous environments
Each environment should be telling some sort of story the player can choose to take part in. The story is completely optional, but adds another layer of depth and interest for the players willing to explore a bit. Using typical level design tropes, along with segmenting boss to grunt gameplay via separate rooms.
Some of our problems and solutions during Pre-Production
What type of game do we want?
Since we switched from 2D to 3D, we could have made any type of game we wanted! With this in mind though, we wanted to leave a lasting impression to those who would come check out our game. From then on, we focused on making the best 5-10 minute combat focused experience we could. The player was #1, with boss design in close second. Most of our design choices revolve around what the experience was playing as E.R.O. 4.
How would we organize our design choices?
First, we set up three main design pillars as I mentioned above. Fast, Up-Close Combat, Unique and Exciting Boss Experience, and Diverse/Hazardous environments. After that, we set up one main design document for most of the team to refer to regarding design decisions. Within that design bible though, for each discipline in our design team, we set up a separate bible for that discipline. I.E. Narrative Bible, Mechanics Bible, Enemy Bible…
How can we communicate these design decisions to each discipline in the team?
We have most all of our communication through a developer discord we set up in the beginning of the development process. Since just discord messages aren’t enough to truly communicate with someone, I developed the idea of Pod Meetings. Pods are small format teams that all focused on one specific part of the game. That could range from the Boss experience, to UI, to Narrative. Anyone who was responsible for those sections of the game, we met together once a week to discuss what our priority was for that sprint, what was blocking us from making progress, and throw around some ideas on how to improve parts of the game.
Clip from Boss 1 in Alpha
Alpha
After creating our systems and getting a good lay of the land, we went into our Alpha phase of production. We tested systems, figured out which ones worked, and which ones we’d need shelve for our next great idea. We got user feedback from other students and used that feedback to inform our decisions toward the game.
What I did during Alpha
Ensured documented systems made it into our game, created user feedback forms, iterated on our level and UX design based off user feedback from each playtest.
Length
A month and a half
Some of our problems and solutions during Alpha
Players weren’t making the platforming gaps.
We decided to cut platforming as a whole. Each playtest showed a majority of players failing the gaps, then voicing frustrations on why it was even in the game.
Players would get frustrated in Boss combat.
Players would go through all this work to get to the boss room, and didn’t have any outlet to heal, see what attack was coming, and overall, just win. After dying, they would get up and leave.
We started to implement more visual signifiers to the boss so that players could see what attack was coming, along with being able to take the actions necessary to live. Along with that, the enemies the boss spawns started to drop healing items so that the fight overall was more forgiving and enjoyable.
Players struggled to control ERO 4 in combat.
We slowly but surely started implementing an omni-movement system. This leaned more into our controller focused UX found in the game, and had players staying longer to explore, kill all the beasties in the grunt world, and get to the boss level.
Beta
After figuring out which systems worked, and which ones we need to cut, we made it to Beta. We focused on game feel, getting assets into the game, and really refining that solid 5-10 minute combat experience we wanted to bring via adding UI along with some narrative in the game.
What I did during Beta
Reviewed User Feedback from each playtest, created UI wireframes and screens, wrote a whole tutorial for the player, led narrative direction along with iteration on a second world with a second boss.
Length
A month and a half
Our second boss during Beta
Some of our problems and solutions during Beta
We made a new boss! What now?
We started production on a new boss! This instantly brought a huge concern to the front of the game though. How could we replicate our smooth, engaging, and fun experience from the first boss to the second one? CONSTANT ITERATION was the answer. We found what was fun about the boss and what totally sucked through playtesting, and quickly changed those aspects of the game daily. With this fast iteration, we found the fun of this new boss in record time.
How do we heighten our in-game UX?
Players were not taking advantage of the tools that were given to them!
Each playtest, we noticed players were not changing their kits and just going straight into combat. Kit preparation was a huge aspect of our game UX pillars. After creating many wireframes (see below) and consulting different games UI styles, we decided to add a kit selection screen to AFTER the player selects the planet they would like to beam-down to.
This change had players taking a step back, considering what type of playstyle they wanted to lean into, and have the player feel even more epic!
How do we find our community?
In order to fully launch on steam, we had to take Branding & Marketing UX into account as well! We had a rough idea what type of gamer would like our game, but we never did any documentation on fully researching that type of player. I took the helm along with my other lead on what type of player we wanted to attract for Beamdown!
We started production on a dev update video, with me writing the entire script along with directing the video. We created different noun and verb lists to fully realize what type of player we wanted to attract, how they would find our game, what tropes they typically liked in games, etc etc .It was a fun and eye opening experience to say the least.
Gold
We got all of our necessary systems into the game, released a demo along with a community discord and developer update to partner with the community before launching. We were able to receive some pretty integral feedback, and it helped us launch our game on steam in March!
What I did during Gold
Wrote and directed a dev update video for Beamdown, set up all socials and started posting to gain an audience. Community management for our Discord, along with QAing our game and giving feedback on what could be refined to become even better!
Length
A month and a half
OVERALL
Beamdown was a great experience in working with a team to build out an idea, together. We created some awesome experiences together, iterated, based decisions off feedback, and launched a game on Steam!
Click on the steam icon to check out the game, and check out our Discord as well!
