Project Type
Full Game
Skills/Tools
- Unity
- Custom Engine
- Game System Design
- Playtesting/Iteration
Project Overview
Dine n' Bash is an academic game project that I made with an interdisciplinary team during my sophomore year at DigiPen. It is a Diner Dash-style food-delivery game, with bullet-hell elements. The Player assumes the role of the owner of a fantasy tavern, and must deliver different dishes to a continuous flow of customers while avoiding the axes, knives, and fireballs that their patrons impatiently send their way.
Nine students worked on the project, five of them programmers, and four of them designers. I was the Narrative Designer and Producer on this project, as well as one of the System Designers.
This page details the System Design work that I did for the project. This includes prototyping, game mechanic design, system mapping, and a LOT of testing and iteration. A page detailing the Narrative Design work I did for this project can be found here.
Duration
September 2023 - August 2024
Project Details
Constraints
The course that Dine n' Bash was made for required that the game be made in a custom engine, created by the programmers on the team DURING production. It was also a requirement that the game be no longer than 10 minutes from start to finish.
This meant that our game needed to be very simple and easy to implement; no complicated mechanics or anything that involved long-term planning. These constraints actually came to be extremely helpful; they helped me and my fellow designers keep our gameplay tight, simple, and fun.
​
Goals
​• A 5-10 minute experience with a beginning, middle, and end
• A game that can be fully understood in under 30 seconds
• A core gameplay loop that was engaging and tense
​
​
Target Audience
We decided that we would like to make a game that would appeal to kids around middle school age (12-15). We sought to target this audience by making a game with low buy-in and cost of learning, but a high skill ceiling for mastery. We also tried to make a gameplay space that looked fun and silly, with nonsensical events and characters.
Personas done by Sirena Cober
Pre-Production
We started pre-production with a brainstorming session, where we threw around ideas for games that would fit our goals, while also being enjoyable to work on. We settled on a Diner Dash-style game, as this type of game fit our scope, and was something we all had experience with. Then, as a team, we settled on the following Design Pillars:
1. Quick to learn, difficult to master
a. With such limited development time, we needed a game with simple mechanics that were easy to pick up. However, in order to keep the experience fresh for 10 minutes, the game also needed to have a degree of depth to it so that members of our target audience would not get bored or distracted.
2. Fast-paced tactical decision-making
a. We knew that we wanted a game that would be chaotic and busy, but we didn’t want it to be mindless. Our target audience needs something more stimulating than a game that requires no thinking or decision-making.
3. The Player cannot “lose”
a. We wanted the Player to feel a sense of achievement when they played, regardless of the quality of their performance. When done right, this reduces the negative experience of failure, while maintaining a desire to try again.
Prototyping and the Core Mechanic
Early Prototyping
With our concept, goals, and design pillars set, we began prototyping in Unity. We started with our own version of Diner Dash-style dish delivery.
Our first decision was about movement. Because we knew that bullet-dodging may be a mechanic down the line, we settled on free top-down movement. It would be easy to implement in the custom engine, and allowed room for bullet mechanics.
Then, we got to work on dish pickup and delivery. The first version was simple: 3 types of food that could be picked up from 3 different stations throughout the tavern. Customers would enter, request a type of food (displayed in an icon above their head), and the Player would need to pick up that kind of food and deliver it to them.
Once we had that working in Unity, we put it in front of testers to validate understanding. We were pleased to see that Players understood what was being asked of them almost immediately.
Stack Functionality
While implementing functionality for carrying multiple dishes at once, we stumbled into a question: should the order of items in your inventory matter? Should you be able to deliver any plate in your inventory, or should you only be able to deliver the plate that you most recently picked up? Should customers ask for their food in a specific order, or not?
We weren’t sure, so we prototyped and tested both. We found that an order-less inventory was easier for Players to understand, but it also got very boring very quickly. There was little optimization to be done, and the game could be mastered too quickly.
On the other hand, a stack-ordered inventory was harder for Players to understand. However, once a Player got the hang of it, they became far more engaged in the moment-to-moment tactics of moving around the restaurant. The problem-solving process of how best to optimize a path through the restaurant became more interesting with a stack-ordered inventory.
​
While both types of inventories had their virtues, we decided to go with the stack-ordered inventory, as it aligned with our design pillars more: it would make the game harder to master, and increase the depth of tactical decision-making.
Bullet-Hell Elements
After spending a lot of time refining our core gameplay loop, we set to work designing the bullet-hell elements. The idea was, once again, simple. Customers that waited too long would periodically fire projectiles at the Player that needed to be avoided. This would fulfill our goal for the mechanic: further deepen the level-navigation and plate-delivery mechanics by presenting moving obstacles.
We tested the mechanic by introducing Orc customers into the prototype. These customers, after waiting X seconds without receiving their food, would fire an axe at the Player in a straight line every Y seconds. If the Player was hit, they would lose a heart, and if they lost 3 hearts, they would be temporarily stunned, unable to move or interact.
After some testing and tweaks to fire rates, projectile speeds, projectile size, etc., we managed to land on a mechanic that fulfilled our goal of deepening the core gameplay loop. Bullets presented a new and interesting navigational challenge, and even introduced customer prioritization: Players would tend to prioritize serving Orcs over other customers in order to avoid axes being thrown at them.
Problems and Solutions
We ran into a lot of problems with our design throughout production. Here are some of the most notable ones, as well as explanations of how we approached them and ultimately solved them.
Stack-Inventory Tutorialization
Health Mechanic
As stated earlier, the stack-ordered inventory was confusing to new Players. They had to learn to pick up food in the reverse order of the customer’s order, which was not intuitive on its own. Most Players assumed that there were no constraints on the order of pickup and delivery, and were therefore confused when they couldn’t deliver the food that they had.
Seeing this, we started exploring solutions. We wanted to fix this problem in a way that conserved the nature of the mechanic; we knew that it produced a lot of engagement once it was fully understood. So, we instead worked on improving our visual feedback.
We changed the way that the Player’s inventory and customer orders were displayed on the screen, so that they better communicated the nature of the game’s rules (top items visually layered on top of lower ones, lower items having reduced opacity, etc.).
When testing, we found that these visual changes did wonders for Player understanding. They picked up on the more minute details of pickup and delivery with almost no explicit explanation.
Throughout the first half of development, we maintained the same 3-heart system we had started with. However, when running a focus group playtest for different features, we found that Players had an overwhelming dislike for the way Health and damage work in the game. Getting hit by a projectile felt like it did nothing until the last hit, when it fully removed your agency in the game for several seconds. Players hated not being able to act after a moment of high tension, and many of them would even remove their hands from the keyboard, assuming that they had “died”.
In our attempt to make a game without a “loss” state, we had inadvertently done just that. So, we brainstormed solutions. We settled on the idea of a “Score Streak”, a multiplier to all points gained. This multiplier would increase with successful deliveries, but would plummet if the Player got hit by a projectile. This punishment would exist in place of the Health system.
The purpose was to create a variable success-state, as opposed to a loss-state. The Player couldn’t “lose”, they could only have their Score Streak taken away.
I prototyped the mechanic in Unity, and put it in front of Players. While it had kinks to be ironed out (mostly with regard to how to display Score Streak information on the screen), Players enjoyed it much more than the Health system. We ended up replacing the Health system with the Score Streak system altogether, and it made for a far better, smoother gameplay experience.
​
Conclusion
Dine n' Bash was a wonderful project to work on. I got experience collaborating with programmers and working in a custom engine, and managed to create a simple, yet fun core gameplay loop that kept Players engaged from start to finish. I prototyped mechanics in Unity, did extensive playtesting, wrote design documents for programmers and fellow designers, and refined gameplay to consistently produce a fun and interactive experience.