Dine N’ Bash - Health System Study
Context:
Early Development of Dine N’ Bash used Unity Engine at the time as our custom engine was still being made, and we needed to test and iterate on features, UI, and player experience.
Project Specs
Type of Project: Academic Team
4 Designers
6 Engineers
Role: Game Designer
Length of Project: 8 Months
Overview
Dine N’ Bash is a top-down time management game where the player is tasked to deliver food to customers in a Tavern. The twist is that when customers don’t deliver their food on time, they throw things at the customer, making it a pseudo-bullet hell.
The Positives of the old Health System
A lot of visceral feedback and, therefore, feedback properly communicated taking damage.
Players took lots of extra precautions in traversal to ensure they didn’t take damage
The range of the player’s minimum and maximum capacity of health was well communicated, as was its current state.
The Negatives of the old Health System
The player’s temporary knockout on having no health took control from the player way too long.
The system did not communicate it was a temporary pause in play, players always assumed they were eliminated once knocked out.
Player observation showed that player engagement fell and never quite recovered once they respawned due to the lack of flow.
This system was too punishing for our target audience.
The system did not support one of two engagement types: Achievement and Mastery.
Mastery was well supported in this system, as not dying was the best way to get the best possible score in the game.
Achievement was not supported in two ways due to the health system:
Dying once simply felt way too punishing.
Dying would lead to the player not racking up score, which in turn meant their final score was a D or F which did not feel good at all.
The New Health System
After some Brainstorming as a team, we decided it would be best to move to a combo meter.
Features of new System:
Delivering orders would add to a multiplier, which multiplies player scores earned on delivery by 1X up to 2.5X.
Thermometer to provide real-time feedback on what score they will earn by the end of the round.
Getting hit would decrease the multiplier by 0.2X and slow the player.
Flames would come from the bottom to make the player feel like they were “On Fire” in terms of performance.
What went well
The system supported both our Engagement Types of Achievement and Mastery.
The Achievement engagement type was supported by having players not being prevented from gaining score when hit, they are simply slowed for a small amount of time.
The Mastery engagement type was supported by allowing players to gain more points by simply not being hit and subsequently having their multiplier score be reduced.
Players were never taken out of the game allowing player flow to be uninterrupted for each of the 2 minute rounds.
Key player data such as multiplier score and level score were clear and gave timely feedback.
What Didn’t Go Well
Our solution took away that sting of punishment from the first major health system but took it away too much.
There were no major reactions from players when they were hit; some of them didn’t realize they had been hit at all.
Because players were under such a heavy cognitive load, they never quite paid attention to the multiplier score or level score, as eye-tracking software proved.
This meant many players weren’t paying attention to their health or preventing damage, which is critical to a bullet hell experience.
The On-Fire feedback mechanism needed to be clearer to avoid confusion, as some players mistakenly believed the level was on fire and actively avoided moving towards the bottom.
A lot of confusion between the designers and the tech team about the new combo meter because we designers were not thorough enough in our design documentation.
What I Learned
Identify issues with core features early.
I knew the health system had problems but they didn’t seem as important as the core gameplay loop. As the months went on, it was left on the side making the amount of iterations to it significantly lower than compared to the rest of the other game features.
Clear documentation is really important for cross-disciplinary teams.
Explain every part of a feature in pain-staking detail. Ensuring that each part of the team, especially cross-disciplinary teammates, knows what we’re making and how it works means less confusion on differences in planning vs engine implementation.