HomeHomeDonut Duel is a roguelite deck builder game featuring donuts. The game is designed to have a humorous vibe, with an extensible system that allows for strategic depth adjustments, enhancing replayability through various build combinations.
The main development team consisted of two members, with additional music and sound support from a team at Berklee. My responsibilities included gameplay design, covering the cards and systems, as well as UI/UX design, shader and programming.
Its production spanned about five months, serving as a practice exercise for A Playful Production Process.
In-game Strategy：A Triple Strategy of Selection, Placement, and Cutting.
This is a turn-based game where, in each turn, players choose which donut(s) to play. These donuts are divided into four parts and may carry special effects such as "attack," "defense," and "healing", etc. The selected donut is placed on a 9x9 grid for cutting, and the cut-off parts activate automatically. Players have a fixed number of action points each turn, which are consumed by placing and cutting the donuts.
Players must devise strategies based on the enemy's actions for that turn, allocating action points wisely to effectively attack the enemy.
Out-of-Game Strategy: A Constructive Strategy of Card Enhancement, Card Synthesis, and Special Item Combination.
After each battle, players can choose from three types of items: toppings (which carry special effects and can be added to 1/4 of a donut for enhancement), items (which add special attributes directly to the player), or new donuts.
Additionally, in certain levels, players can choose to transform a donut into a topping, thus destroying useless donuts to extract valuable toppings and enhance other donuts.
Players focus on the interactions between different special effects to determine their combat strategy and deal higher damage.
At the initial stage of the project, we conducted two half-hour brainstorming sessions. Afterwards, we organized each idea, marked satisfaction levels and risks, and ultimately chose the current plan.
After determining the basic direction of the game following a brainstorming session, I quickly implemented the core mechanics in a 2D prototype: circular cards, placement, and effect activation.
We conducted a small-scale playtest to verify the potential of the gameplay and made adjustments to mitigate some potential risks. For instance, we found that the concept of "speed" (initiative) was uncommon in roguelike games thus had a high cognitive load, so we decided to remove this attribute.
The prototype helped us clarify our experience goals (Strategic Thinking, Tension, Humor), design goals (Replayability, Strategic Depth, Gradient Challenge), and target audience (strategy game enthusiasts).
While creating the vertical slice, we planned the design macro for the alpha version. It included all the necessary mechanics and provided a reference for the overall production pace and resources.
We use Notion for project management to track milestones and plan the completion of all features.
We conducted the most formal and large-scale playtest on the pre-release version to gather more data. We used two methods to collect data: metrics and surveys. One provides objective data, while the other captures players' subjective feedback, allowing us to test the game from multiple data perspectives.
The first aspect we tested was the gameplay. We wanted the game to be challenging, requiring strategic choices to defeat the final boss. We observed that our players acknowledged the game's difficulty, with 2 out of 5 players successfully completing the game using specific strategies. This is good news for us.
e also tested the game's audiovisual feedback and usability, identifying areas that need improvement.
Compared to experience-oriented design, using Professor Richard's production process feels more industrialized. Through this process, I have understood the reasons behind each design step and the practical methods, as well as the logical progression of each phase of production.
My takeaway is that calculating development workload and controlling development costs are crucial in any situation. Not only does this help us complete the game development within a limited timeframe, but it also feeds back into the design of gameplay. In this process, due to the concern of "not being able to complete the existing scope," we constantly reflect on which parts of our design best serve the core fun and continuously evaluate our systems.
I also realized that creating an original and feasible gameplay takes a long time to iterate. Previously, I always emphasized the development process over the creative process in game development, which was a misunderstanding.
