Project Overview

• Role: Solo Game Designer & Developer — responsible for gameplay, systems design, programming, UI/UX, balancing, testing, and release.
• Timeline: MVP completed in approximately 1–1.5 weeks; continued development through early access.
• Tools: Unity, C#, A* pathfinding, Blender, Google Play Store.
• Objective: Expand my game design range while improving my UI/UX skills and building modular systems that would make it easy to create new towers, enemies, upgrades, and levels.

What Went Well

• Rapid Prototyping: The initial MVP came together within the first 1–1.5 weeks, significantly faster than expected. This gave me enough room to experiment with the game’s core loop rather than becoming locked into the initial concept.
• Successful Pivot: The project originally began as “Drainage,” an incremental game about draining water from asteroid tunnels and discovering treasure. After building the core system, I realized the gameplay wasn’t compelling enough to sustain the experience. I pivoted toward tower defense, which fit naturally with the environment and lore I had begun developing.
• Modular Systems: A major design goal was making the game’s systems easy to extend without rewriting existing code. Towers were built around modular aiming, shooting, projectile, damage, and upgrade behaviors, allowing new combinations to be created quickly.
• UI/UX Development: I built a drag-and-drop tower placement system directly into the UI, giving me an opportunity to practice designing interfaces around player actions rather than simply presenting information. I also made a Gacha cutscene system using 2 cutscenes to smoothly transition between anticipation and reward.
• Playtesting: Small external testing groups provided valuable feedback on onboarding and upgrade balance. This feedback directly influenced changes made before the early-access release.
• Player-Driven Discovery: Testing revealed that some of the most enjoyable moments came from the gacha-style tower unlocking sequence and the depth of tower customization. Players also discovered unusual and unexpected tower builds, reinforcing the value of giving players room to experiment.

What Went Wrong

• The Initial Core Loop Didn’t Work: The original incremental gameplay loop was functional but failed to create a compelling reason to continue playing. Recognizing this early allowed me to pivot before investing too heavily in the wrong direction.
• Upgrade Balancing: An example of one of the multiple is the “Doubleshot” and “Tripleshot” upgrades, which introduced several unexpected problems. My initial approach nearly halved the tower’s damage for every additional projectile, which eventually caused integer rounding to reduce damage to zero.
• Projectile Spread: The first implementation also offset each additional projectile from the original direction. Visually, this caused the projectiles to spread too far to the sides rather than creating a useful spread around the target. My fix was to introduce a limit to prevent any 0 damage and to change the angle of the initial shot to 1/2 the offset that the last additional bullet would gain to compensate.
• Upgrade Complexity: I wanted upgrades to remain data-driven rather than hard-coded, but I had not previously built a system this robust. This led me to develop a custom Snapshot system to manage upgraded per-instance tower variables without directly modifying the underlying base values.
• Onboarding & Balance: Playtesting exposed areas where players needed clearer onboarding and where upgrade balance needed refinement. These issues became priorities before the early-access release.

Results and Impact

• MVP: A functional MVP was completed within approximately 1–1.5 weeks.
• Playtesting: Feedback from small testing groups identified meaningful improvements to onboarding and upgrade balancing before release.
• Early Access: The game was published to Google Play in early access, with plans for continued updates and additional content.
• Technical Foundation: The project established a modular foundation for rapidly creating new towers, enemies, levels, projectiles, and upgrade combinations.
• Player Response: Testing showed particularly strong engagement with the tower-unlocking sequence, tower customization, and the unexpected builds players were able to create.

Key Takeaways

• Prototype the Fun First: Building the original incremental system taught me that having a functional gameplay loop isn’t enough. The loop needs to provide a compelling reason for the player to continue engaging with it.
• Pivot Early: Because the MVP was completed quickly, I was able to recognize the weakness in the original concept and pivot toward tower defense without losing months of development.
• Modularity Pays Off: Designing systems around reusable and configurable components made it substantially easier to experiment with new tower behaviors and upgrades.
• Test Earlier: External playtesting exposed onboarding and balancing problems that I would not have identified as quickly through solo development.
• Build for Experimentation: Some of the most enjoyable player discoveries came from unexpected tower combinations. Designing systems that allow players to find interactions I didn’t explicitly design for can create depth without requiring every interaction to be authored manually.

Next Time

For future projects, I would establish external playtesting earlier, prototype the player-facing experience alongside the underlying systems, and build balancing tools earlier in development. I would also continue using modular architecture while being more deliberate about which systems actually need to be generalized.

Below: YouTube playlist of short-form dev logs for the first section of the project’s development.