Daquan Griffith
Project Dreamscape
Project Type : Studio ASPEN
Date : September 2024 - April 2025
Role : Studio Executive Producer
Team Size : 100+
What is Dreamscape?
At its core, Dreamscape is a 3D roguelike dungeon crawler with a unique twist: instead of exploring pre-designed dungeons, the player builds the world as they progress—one square at a time. Designed to encourage adaptability and skill-based gameplay, Dreamscape merges fast-paced combat with unique construction, forcing players to make strategic decisions about how their environment unfolds.
There will be sections at the bottom of the page with Monthly Breakdowns and Detailed Specific Changes These main sections will be personally led pivotal points
While I am an Executive Producer I like to closely work with the departments that align with my disciplines compared to the others. To clarify it is not that I neglect and seclude other departments but I am more active in my specializations. It is not my job nor my intention to take control of my department leads but I often help guide and drive them in better directions
Section 1: Early Groundwork
Section 2: Design and Programming Rework
Section 3: Finalization
Section 1: Early Groundwork
Video Coming Soon
The initial Vision
At the core of Dreamscape was a foundational question: What if the player created the challenge themselves—one decision at a time?
I designed Dreamscape as a modular roguelike, where the player constructs the dungeon dynamically, adding "squares" after each completed wave. Each square introduces a new set of enemies, modifiers, or mechanics directly tying level expansion to player agency and pacing.
Rather than relying on static or procedurally generated maps, we created a player-driven, adaptive worldbuilding system, where each run became uniquely personal. This gave players control over tempo, difficulty escalation, and spatial navigation, transforming every decision into a meaningful risk/reward tradeoff.
Combat and Interactive Complexity
Combat was architected around a 2-button core input system. Intentionally, it was minimalistic to ensure accessibility, while supporting deep skill expression through progression:
-
Combo Evolution: One weapon at start, but through leveling and unlocks, players gain access to branching combo trees, transformation moves, and reactive augment effects.
-
Augment Architecture: Augments are modular enhancements layered on top of base weapon logic—stackable buffs, charge modifiers, explosive reactions, or status transfers.
-
Design Intent: This structure allowed players to craft and discover emergent playstyles, giving each run a sense of tactical identity without overwhelming mechanical complexity
We designed combat progression using the "Teach, Test, Twist" loop:
-
Teach base combo in early waves.
-
Test through augment-enabled enemies.
-
Twist via synergistic stack interactions, forcing adaptation.
This ensured mechanical clarity while building toward high-end mastery.
Programming Logistics & Systems Planning
Early development faced challenges in scalability and system isolation, especially around dungeon state tracking and combat interactions. I helped lay the foundation for several key technical systems:
Modular Dungeon Construction System
-
Each tile (square) was a self-contained node holding its wave logic, spawn data, and placement constraints.
-
On wave completion, the system would dynamically query for valid adjacent tiles, then instantiate the selected node prefab with event listeners tied to a centralized dungeon manager.
-
Designed as a data-driven system using ScriptableObjects (Unity) to allow non-programmers to prototype tile behaviors independently.
Combat Engine Architecture
-
Built a state machine-based input interpreter, allowing us to hook combo sequences into a central resolver that returned context-based results (e.g., "if last input = heavy + charged + near wall → trigger AOE edge combo").
-
Augments were implemented as decorator-style components that subscribed to weapon events—keeping them modular, hot-swappable, and futureproof for content scaling.
Enemy Wave Controller
-
Created a reusable Wave Manager that handles enemy spawn queues, pacing delays, and death conditions across all dungeon tiles.
-
Supported wave chaining and mini-boss injection logic, enabling seamless ramp-up in encounter complexity.
This early work set the foundation for later polish phases and significantly reduced integration bugs.
Insights from Early Playtesting
External Strengths:
-Players were immediately engaged by the "build your dungeon" mechanic
-The combat was understood by players of all skill levels in action games
-The IDEA of augments was easily understood
Internal Strengths:
-The Design team was easily able to tweak the dungeon-building aspect and played around with the size of squares
-The Programming team had a reliable pipeline for logistics in the game for when things happen, so it's easier to catch when things go wrong
External Weaknesses:
-Clarity was a recurring pain point
-Players weren’t sure how augments stacked, what wave patterns meant long-term, or how to anticipate difficulty spikes
-Players didn't feel that placing the squares gave them enough choice
-Players got bored with killing all monsters/surviving being the end of the wave each time
-Players were unsure how Audments and the combat differed from each other
Internal Weaknesses:
-The design team would make combos but then be confused if that was going into augment territory and vice versa; in other words,t he combat was not clear in terms of what the player could do with two layering systems
-The Programming team also began to see the confusion caused by the combat system not just the idea, but functionality, also the looming idea of the game constantly spawning enemies everywhere,e all at once, would be a taxing idea to deal with
Key Finding: Our systems were deep but opaque. The player needed better visual feedback, onboarding, and moment-to-moment clarity to fully engage.
The game failed to hit the fantasy of unique runs and left the player with little variety or meaningful choices. The game also failed to have a cohesive combat system for both the players and designers, in which the original system sounds good on paper but is horrible in practice
Keeping this in mind, I began to work on and deliver our most effective overhaul yet for production cycles, player clarity, and satisfaction
Section 2: Design and Programming Rework
Video Coming Soon
Recognizing the Breaking Point
After extensive playtesting and internal review, it became clear that Dreamscape was suffering from systemic opacity. Players didn’t understand the combat layers, couldn’t anticipate wave difficulty, and didn’t feel empowered by their land placement choices. Internally, the design team was overlapping augment and combo responsibilities, while the programming team flagged unscalable enemy spawning logic and redundant input processing.
The fantasy of creating your own run with evolving mechanics and personal playstyle wasn’t just unclear—it was functionally unachievable in the current structure.
Programming Refactor: Enemy Systems & Wave Flow
One of the most urgent technical issues was how enemy waves scaled across lands. Originally, each “land” (or tile) spawned its own enemies with no prioritization or pacing control. As maps grew, the system indiscriminately spawned enemies across all lands, resulting in performance issues and bloated gameplay loops.
What I Led:
-
Modularized the Enemy Manager (EM) per land, introducing a currency-based spawn system that governed how many and which enemies could appear.
-
Implemented a spawn economy: each enemy had a cost, and the EM rolled until its budget was exhausted, avoiding overpopulation and allowing predictable scaling.
-
Centralized all EM coordination into a Master Level Controller that tracked wave states, ensuring a clean trigger for progression and UI feedback.
Result: Reduced runtime spikes, increased design control over enemy escalation, and clearer player expectations per wave.
Design Rebuild: Core Progression Overhaul
The original win condition—defeat all enemies, place next tile—became repetitive and uninspired, failing to offer meaningful choices. To fix this, I proposed and implemented the Empower & Weaken System combined with an Event-Driven Progression Model.
Empower & Weaken System:
-
After each wave, players received Empower/Weaken tokens to modify land levels manually.
-
Higher-level lands meant stronger enemies but better rewards, while negative levels could eliminate waves entirely.
-
This introduced risk-reward agency and gave real meaning to player pathing decisions.
Event Select System:
-
Removed “kill all enemies” as the default win condition.
-
Introduced randomized, rule-based event types (e.g., Escort, Defend, Zone Control, Survive Timer) with specific triggers for wave completion.
-
Events changed not just enemy flow, but how and where players needed to engage.
Result: Meaningful, contextual player choices with procedural variation in wave goals. Significantly increased playtime retention in internal testing.
Unified Combat Design: The Aspect System
Identifying the Core Issue
One of the most persistent problems in Dreamscape’s early development was the segmented combat experience. We had two overlapping systems—Combo Trees and Augments—that were intended to interact, but in practice created confusion for both players and developers.
-
Designers were unsure whether a move should be a new input (combo) or a passive effect (augment).
-
Players couldn’t tell if their character was evolving because of skill, items, or leveling.
-
Programmers found that maintaining both systems introduced unnecessary coupling and excessive branching logic in combat evaluation.
It became clear that the separation of input-based and passive progression was hurting clarity, cohesion, and scalability.
Reimagining Combat Progression
To solve this, I proposed and led the design and implementation of the Aspect System—a new, unified framework that merges the strengths of both Augments and Combo unlocks into a single, modular structure.
What Are Aspects?
Aspects are core archetypes that define a player's combat identity across both active and passive dimensions. Each Aspect introduces:
-
New combo routes tied to progression level.
-
Thematic effects (burns, dashes, explosions, etc.) that scale with usage.
-
Traits that passively reinforce certain playstyles (e.g., aggressive chaining, evasive speed, control, etc.).
Systems Integration
-
Refactored both old systems (combo tree handler & augment controller) into an event-driven Aspect Module, allowing for clean decoupling of core inputs and effects.
-
Aspects hook into weapon actions, hit confirms, and enemy states, using a modular trait system for conditionally triggered bonuses.
-
Each Aspect is leveled via XP or pickups, enabling RPG-style growth without introducing new inventory or shop systems.
Design Principles
-
Cohesion: No more parallel systems. Designers now work within a single framework that supports both mechanical and aesthetic growth.
-
Clarity: Players are introduced to one core identity, not two disjointed systems.
-
Scalability: Easy to add new Aspects without rewriting underlying mechanics or bloating the UI.
"We stopped asking ‘Is this an augment or a combo?’ and started asking ‘How does this Aspect evolve the player's style?’”
Outcome & Results
-
Greatly reduced system complexity for both designers and programmers.
-
Improved player comprehension and skill expression, as feedback loops became tighter and thematic.
-
Allowed for quick thematic prototyping—we could spin up a new Aspect in a matter of hours using the modular backbone and event-based triggers.
-
Combined with other combat and progression improvements, internal playtest satisfaction increased over 70%.
The Aspect System is more than a mechanic—it represents a unified design philosophy. It turned Dreamscape’s fragmented combat into a flexible, player-driven framework that supports depth, identity, and readability at every level of play.
Section 3: Finalization
Video Coming Soon
Executive Design
September – Establishing the Foundation
At the beginning of development, Dreamscape was in its most conceptual stage. The core idea was a 3D roguelike where players would construct their own dungeon, one land at a time. At this point, the land system was very basic, simply allowing the player to place tiles that spawned enemies. The assumption was that the player’s goal would always be to defeat all enemies, and there wasn’t much thought about how to create variety in player objectives or a sense of long-term progression.
One of the earliest design pillars we explored was combat depth through customization. The initial approach was to separate Combos and Augments into two distinct systems:
-
Combos were execution-based, meaning players had to learn and master specific inputs to string together attacks.
-
Augments were passive modifiers that affected the player’s abilities over time, encouraging different playstyles.
Theoretically, this sounded great—players could craft builds tailored to their preferences by mixing and matching augments with combos. However, at this stage, we didn’t realize that the complexity of balancing two distinct progression systems would quickly become a huge problem.
October – Refining Systems & Recognizing Flaws
By October, we began exploring ways to expand the land system. We introduced the idea that each land would have a specific theme, affecting the types of enemies and challenges the player would encounter. Additionally, we considered a land formation mechanic—if players placed tiles in certain patterns, they would merge to form larger, more difficult encounters with refined obstacles and enemies.
On the combat side, we started developing combo routes, where players could unlock new attacks based on their progression. Alongside this, we built out augments that passively affected the player, such as increasing attack speed, modifying how damage was dealt, or adding elemental effects. However, we quickly ran into a fundamental problem:
-
Lands still lacked incentive – There was little reason for the player to choose one land over another beyond randomness. Players weren’t making meaningful choices; they were just placing tiles without thought.
-
The separation of combos and augments was overwhelming – While players could technically customize their builds, the system was too complex to understand at a glance. The depth was there, but it wasn’t intuitive, leading to slow and hesitant decision-making.
At this point, it became clear that the systems we had built were too theoretical—they made sense on paper, but in practice, they weren’t engaging or approachable. As Executive Producer, I had to step in and push for major reworks. One of the hardest parts of game development is recognizing when a system, despite being well thought out, just doesn’t work. Many on the team were hesitant to throw out weeks of design and programming work, but I knew that clinging to a flawed system would hurt the game in the long run.
This was a critical moment in development. Ideas that seemed solid in concept were failing in execution, and we had to make a choice: double down on systems that didn’t feel right or tear them down to build something stronger. I made the call to scrap both the combo/augment system and the land system in their current forms, pushing for a more unified, player-driven approach.
November – The Big Rework
In November, I halted both design and programming to force a full rework of two key systems:
-
Lands & Progression → Introduced the Empower & Weaken System
-
Combat Customization → Unified Combos & Augments into the Aspect System
Empower & Weaken System – Fixing the Land System
Instead of lands being random, passive tiles, we introduced Empower & Weaken tokens, allowing players to manually control their difficulty.
-
Empowering a land made it more dangerous but increased the rewards.
-
Weakening a land made it safer but reduced resource gain.
-
Lands that were left alone remained neutral, ensuring players had a mix of challenges.
This completely changed how players interacted with the world. Instead of placing tiles randomly, they were now making real strategic decisions about their difficulty curve and risk-reward balance.
Aspect System – Unifying Combos & Augments
To simplify player customization, we merged combos and augments into a singular progression tree called the Aspect System. Instead of treating them as separate mechanics, the Aspect System allowed players to:
-
Unlock new attacks and passive abilities within the same tree.
-
Make meaningful choices about how their build evolved, without juggling two disconnected systems.
-
Understand progression more easily, since everything was centralized in one UI.
This dramatically improved clarity, making combat progression easier to balance and more satisfying to engage with. However, the design team struggled with letting go of their original augment and combo ideas, leading to slow production. Many still felt that augments should be completely passive, while others believed combos should remain execution-heavy. My role as Executive Producer here was to push for compromise—finding a middle ground that preserved the best parts of both systems while eliminating unnecessary complexity.
The Event System – Solving the Player Goal Issue
Another problem we still faced was player motivation—what exactly should they be doing wave to wave? Previously, the only goal was "kill all enemies", which felt stale and predictable. I introduced the Event System, which randomly assigned different goals per wave, such as:
-
Survival Events – Last X seconds instead of killing enemies.
-
Escort Missions – Protect an NPC while enemies spawn.
-
Zone Control – Capture specific areas of the map.
This diversified player objectives and made each wave feel more dynamic and engaging.
At this point, we had solved three major problems:
✔ Lands had purpose & strategy through Empower & Weaken.
✔ Combat progression was simplified & unified through Aspects.
✔ Players had clear objectives through the Event System.
However, something still felt missing—the game lacked a final layer of active player engagement.
December – The Final Layer
With most systems now in place, we shifted our focus to content development:
-
Creating Aspects & Land Themes – Defining the actual abilities and environmental hazards that would appear in the game.
-
Refining Progression Systems – Ensuring that choices felt impactful from start to finish.
However, due to time and resource constraints, we had to scrap the land formation mechanic (where specific tile placements would combine into new structures). While it was an interesting idea, it ultimately didn’t fit within our development scope.
Memory & Flow System – The Final Piece
At this point, I led the team to introduce one last mechanic: the Memory & Flow System, which rewarded players for maintaining momentum:
-
Memory System – Killing enemies of specific types would build up a bar, unlocking temporary abilities based on the most frequent enemy type killed.
-
Combo & Flow System – A system that tracked player momentum, rewarding fluent, uninterrupted gameplay and punishing hesitation.
This system added the final layer of depth we were missing, ensuring the player was always engaged and thinking about their actions.
Conclusion & Next Steps
By the end of December, all major mechanics were in place. With winter break approaching, we planned to pause production until February, allowing time to reflect and prepare for polishing and content expansion.
At this point, Dreamscape had transformed into a fully realized, player-driven roguelike, balancing strategy, customization, and moment-to-moment action. The journey wasn’t easy, but by recognizing when to scrap ideas and prioritize clarity over complexity, we built a stronger, more cohesive game
.