GAME PROJECTS / PROTOTYPES
ROGUE CRUSH
Genre: Match-3 RPG Hybrid
Engine: Godot 4.5 (GDScript)
Platform: Desktop / Mobile
Overview
Rogue Crush is a hybrid between a casual match-3 puzzle game and a turn-based RPG. The player swaps and matches colored tiles on a 7x7 grid, just like a traditional match-3 game, but each tile color represents a different combat resource. Matching red tiles deals damage to an enemy, matching green tiles heals the player, matching blue tiles generates mana for spellcasting, matching yellow tiles builds up a damage-absorbing shield, and matching purple tiles multiplies the effects of everything else matched in the same turn.
The game combines the instantly familiar core of a casual puzzle game with the strategic depth, progression systems, and replayability of an RPG.
Background
I'm a gamer. My wife is not. But she is around level 12,000 on Candy Crush, which is honestly hard to believe.
Since she doesn't play the kinds of games I enjoy, I started wondering what a game would look like that we could both enjoy.
That question led me to think about combining the core gameplay of a match-3 game with the progression and theming of an RPG. What if the simple, satisfying act of matching tiles could feed into something deeper like combat, spellcasting, and character growth? That idea became Rogue Crush.
My goal was to create something simple enough for casual mobile players who have no connection to RPGs, while still being engaging enough for RPG fans who would normally never touch a match-3 game. Since I was going to play this game too, the most important challenge was finding the right balance between these two very different genres and delivering both in a way that feels natural and fun.
Design Approach
The core design philosophy behind Rogue Crush is making every match meaningful.
In a traditional match-3 game, tiles are cleared for score. In Rogue Crush, every tile the player clears directly impacts the battlefield. This is built on a five-color resource system where each color maps to a gameplay function:
Red (Attack) deals direct damage to the current enemy
Blue (Mana) fills the mana bar for spellcasting
Yellow (Shield) grants a damage-absorbing barrier
Green (Health) restores the player's HP
Purple (Multiplier) amplifies the effect of other tiles matched in the same turn
This creates a natural layer of strategy on top of the familiar match-3 gameplay. Players aren't just looking for any match. They're deciding whether they need to deal damage, heal, build up shield before a heavy incoming attack, or save mana for a powerful spell.
The purple multiplier tiles add another dimension. When 3 or more purple tiles are matched alongside other colors in the same turn, they amplify those effects. So matching 3 red attack tiles alongside 3 purple tiles turns 30 base damage into 48. This encourages players to think about tile combinations and positioning rather than just clearing as many tiles as possible.
Gameplay Systems
During development, I designed and implemented several interconnected gameplay systems, including:
A turn-based combat system where each match triggers an enemy counterattack, with a strict phase structure (Player Input → Match Resolution → Resource Application → Enemy Response → Progress Check)
A match-3 engine with swipe-to-swap input, cascade chains up to 50 levels deep, gravity and block respawning, L-shape and T-shape detection, automatic board reshuffling when no valid moves remain, and combo intensity scaling on animations
A shield mechanic with 50% partial damage absorption, designed to make defense useful without removing combat tension
A spell system with 14 spells across four categories (Offensive, Defensive, Utility, Board Manipulation), each with unique mana costs, cooldowns, targeting modes, visual effects, and audio
A 4-slot spell loadout with a 20-point cost limit, forcing players to choose between a few powerful spells or several weaker ones
A spell shop where players purchase spells using gold, gated by account level requirements
A spell targeting overlay with real-time area previews for spells like Meteor Strike (3x3), Row Breaker (full row), and Color Explosion (all tiles of one color)
A status effect system supporting damage-over-time, heal-over-time, damage reduction, crit bonuses, and gold bonuses, with visual and audio feedback on each tick
A world and stage system with four worlds, each with unique biomes and enemy types, and an overflow scaling system that progressively increases enemy HP, damage, and gold rewards beyond configured stages
A dual progression system with session XP (fast leveling during a run, resets on death) and account XP (slow meta-progression, persists forever)
A level-up card system with 17 cards across three tiers (Common, Uncommon, Rare), offering session buffs and instant rewards through weighted random selection
An account-wide upgrade system with permanent stat improvements across four categories (Vital, Arcane, Mastery, Utility), with escalating costs per rank
A gold economy that connects all systems together, where tiles, cascades, enemy kills, and cards all generate gold that feeds into the spell shop during runs and converts to persistent currency on death for permanent upgrades
A 3-stage audio system for spells (cast → effect → impact) with polyphonic sound effects, music crossfading, and match sound debouncing
Floating damage numbers with text labels, per-type outline colors, fade delays, and screen shake on damage for tactile combat feedback
Platform-aware features including touch input, adaptive UI, and automatic debug/release mode detection for desktop and mobile support
TURN BASED COMBAT
When I first started designing the game, I gave the board itself an HP bar. The player's goal was simply to deplete it. But at some point, it became clear that having an actual enemy on screen that fights back would make the experience far more engaging.
This naturally required a turn-based system. After the player makes a match and all cascades resolve, the enemy counterattacks with damage that scales based on the current stage. While fast-paced gameplay is important for match-3 games, this was a necessary trade-off to create the RPG feel I was aiming for. The result is a game where each move carries weight. A bad match might leave you vulnerable, and a good one might save your life.
MATCH-3 ENGINE
When I first started designing the game, I gave the board itself an HP bar. The player's goal was simply to deplete it. But at some point, it became clear that having an actual enemy on screen that fights back would make the experience far more engaging.
This naturally required a turn-based system. After the player makes a match and all cascades resolve, the enemy counterattacks with damage that scales based on the current stage. While fast-paced gameplay is important for match-3 games, this was a necessary trade-off to create the RPG feel I was aiming for. The result is a game where each move carries weight. A bad match might leave you vulnerable, and a good one might save your life.
Shield Mechanic
When the player matches yellow tiles, they gain shield points. When the enemy attacks, the shield absorbs 50% of the incoming damage while the remaining 50% goes directly to HP. If the player has no shield, they take the full hit.
This partial absorption design was intentional. A shield that blocked 100% of damage made yellow tiles feel overpowered and removed the tension from combat. The 50% model means building shield is always useful but never a complete solution, keeping the player engaged in balancing offense and defense every turn.
Spell System
Since mana exists as a resource on the board, it made sense to give players something meaningful to spend it on. I designed a spell system with 14 spells across four categories:
Offensive (4 spells): Direct damage, chain lightning that bounces between targets, damage-over-time burns, and a meteor strike that deals massive damage while clearing a 3x3 area of tiles
Defensive (4 spells): Instant healing, shield generation, heal-over-time regeneration, and divine protection that reduces incoming damage by 75% for multiple turns
Utility (3 spells): Mana restoration, a luck buff that increases crit chance and gold drops, and tile alchemy that transforms a tile into any color
Board Manipulation (3 spells): Full board shuffle, row clearing, and color explosion that detonates every tile of one chosen color
Spells are equipped in a 4-slot loadout with a 20-point cost limit. More powerful spells cost more loadout points, so the player has to choose between a few strong spells or several weaker ones. Each spell also has an individual cooldown measured in turns, which prevents spam and adds another layer of tactical decision-making.
Players start with Fireball and Heal as free starter spells and unlock the rest through a shop using gold earned during gameplay. Each spell also has an account level requirement, which ties the shop into the broader progression system and gives players specific goals to work toward.
The entire spell system is data-driven. Every spell is defined as a resource file with its stats, effects, visuals, and audio configured through the Godot Inspector. Adding a new spell requires creating a resource file and adding it to the spell list, with no code changes needed for basic spells.
World and Enemy System
The game features a world system with four distinct worlds, each with its own biome and enemy types. Currently four enemies are defined: Goblin Warrior (80 HP), Goblin Archer (120 HP), Goblin Spearman (150 HP), and Goblin Shaman (200 HP). Each has increasing counterattack damage and gold rewards.
For the first 4 stages, enemies use their exact designed stats. Beyond that, an overflow scaling system kicks in where the last enemy repeats with progressively higher HP, damage, and gold rewards per additional stage. This creates an endlessly escalating challenge without requiring manual definition of hundreds of stages.
A boss system is planned where each world's final enemy would have unique abilities that directly interfere with the board, such as locking tiles or converting tile types. This is designed to push the RPG feel further and test strategic thinking beyond standard combat.
Level-Up Card System
During a run, players earn session XP from matches, cascades, and stage clears. When they level up, they're presented with 3 randomly selected cards and choose one.
There are 17 cards across three tiers. Common cards are available from level 1 and offer smaller bonuses like +10 Max HP, +5% Damage, or +50 Gold. Uncommon cards unlock at session level 3 with stronger effects like cooldown resets, +10% Damage, or mana cost reduction. Rare cards appear at session level 6 with significant boosts like +50 Max HP or +20% Damage.
Some cards are instant one-time effects like healing or gold, while others are session-persistent buffs that last until the player dies. This system is what makes each run feel different. Depending on which cards appear and which the player chooses, two runs can play out very differently even against the same enemies.
Account-Wide Upgrade System
Beyond session-based gameplay, I built a permanent upgrade system that gives players long-term progression goals. Upgrades are split across four categories:
Vital: Max HP, max shield, recovery, revival
Arcane: Max mana, spell cost reduction, mana regeneration, spellbar capacity
Mastery: Attack damage, crit chance, crit damage
Utility: Gold gain, XP gain
Each upgrade becomes progressively more expensive at higher ranks, creating a natural pacing curve. This system serves two purposes. It gives players a reason to keep playing over the long term, and it provides a way to overcome difficult enemies they're stuck on. Not through luck, but through meaningful investment in permanent power.
Gold Economy
Gold flows through the entire game and connects multiple systems together. Players earn gold from every tile match, from cascade chain bonuses, from defeating enemies (with rewards scaling by stage), and from level-up cards. Gold multiplier bonuses from cards and spells amplify all sources.
During a run, gold is used to purchase spells from the shop. On death, all session gold converts to persistent gold, which funds the account-wide upgrade system. This creates a satisfying loop where even a failed run contributes to the player's long-term power.
Technical Structure
Rogue Crush is built in Godot 4.5 using GDScript with approximately 12,000 lines of code across 134 files (48 scripts, 40 scenes, 66 resources, 3 shaders).
The architecture is built around 8 autoload singletons coordinating through a centralized EventBus with 81 signals. All systems communicate via signals rather than direct references, keeping them decoupled. Game state is managed through a module ownership pattern where a single Game autoload owns specialized modules (PlayerState, SpellCaster, StageState, CardPool, and others) as child nodes, providing a clean lifecycle and a unified access point.
Game content like spells, enemies, cards, world configurations, and upgrades is defined entirely using Godot's resource system, making it possible to add, tweak, and balance content through the Inspector without modifying code. This data-driven approach was critical for rapid iteration on game balance.
What I Learned
Rogue Crush has been the most ambitious project I've worked on, and the one where I've learned the most about game design as a discipline rather than just implementation.
The biggest lesson was about genre balance. Combining match-3 and RPG mechanics sounds straightforward on paper, but finding the right balance where neither genre overwhelms the other required constant iteration. Every system I added had to be evaluated not just on its own, but in terms of how it affected the overall feel of the game for both casual and core players. The turn-based combat was a deliberate sacrifice of match-3 speed for RPG depth, and the shield mechanic went through a full redesign from 100% to 50% absorption because the original version eliminated too much tension.
I also gained significant experience designing interconnected systems. The resource tiles, combat, spells, progression, card rewards, and gold economy all feed into each other, and changing one value often had ripple effects across the entire game. This taught me to think about game design holistically. Not just what a system does in isolation, but how it interacts with everything around it.
Designing a dual progression system was another key learning. The session and account split required careful tuning. Session progression needed to feel fast and rewarding to maintain the match-3 pacing, while account progression needed to be slow enough to provide long-term goals without feeling grindy. Getting this balance right meant the same game could feel satisfying in a 5-minute session and still have depth for hundreds of hours.
Building a fully data-driven architecture from the ground up was a major takeaway. By defining all game content through resource files rather than hardcoding values, I was able to iterate quickly and keep the project flexible enough to accommodate new ideas, like adding the entire account upgrade system, without rewriting existing code.
Finally, this project reinforced the value of designing with a clear audience in mind. Having a concrete goal of making something my wife and I would both enjoy gave every design decision a filter to pass through. It kept the scope focused and the priorities clear throughout the entire development process.
FOXPITAL
Genre: Top-Down Time Management
Engine: Unreal Engine 5.4 (Blueprints)
Overview
Foxpital is a stylized top-down prototype where the player takes the role of a doctor (fox) treating incoming patients under time pressure. Each patient arrives with different medical needs, and the player must quickly identify and apply the correct treatment before their condition worsens.
Rather than relying on scripted scenarios, the project focuses on building system-driven gameplay, where patient conditions and treatment outcomes are generated dynamically.
The project was partly inspired by the chaotic coordination and fast-paced decision making found in Overcooked, but reimagined in a single-player medical setting.
Background
Since I did not have a traditional programming background, I chose Unreal Engine as my development environment because of its visual scripting system and its widespread use as an industry-standard engine.
I initially started by following tutorials to understand the basics of the engine and Blueprint workflow. However, I quickly realized that the most effective way for me to learn was to build a project around an idea I genuinely wanted to explore.
With that mindset, I started working on Foxpital as a way to experiment with gameplay systems while learning Unreal Engine in a practical context.
Design Approach
One of the main goals of the project was to explore how gameplay systems can be structured in a flexible and data-driven way.
Instead of hardcoding patient behavior or treatment logic, I experimented with creating systems that could be configured through structured data. This made it possible to control gameplay variables such as patient needs, treatment outcomes, scoring rules, and level objectives without modifying the core logic of the game.
Gameplay Systems
During development, I implemented and experimented with several interconnected gameplay systems, including:
A dynamic patient need system where patients spawn with different combinations of medical needs
Level-based configurations controlling allowed needs, difficulty, and patient behavior
A treatment validation system comparing the expected patient need with the applied treatment
A data-driven inventory system where items are represented through structured data rather than actor references
A flexible interaction system supporting Press, Hold, and Tap input types
A patient health system reacting to correct and incorrect treatments
A scoring and level progression system with win/lose conditions and star ratings based on player performance
A floating feedback system displaying healing or damage values directly above patients
A modular HUD system displaying timer, score, and patient statistics
A randomized patient spawning system
Technical Structure
The project was built using a modular Blueprint architecture in Unreal Engine 5.4.
Gameplay data such as patient needs, treatment effects, and level objectives were managed using DataTables and Structs. Communication between gameplay systems relied heavily on Blueprint Interfaces, helping reduce direct dependencies between systems and making the overall structure easier to expand.
What I Learned
Foxpital became an important learning project for understanding how gameplay systems interact within a larger structure.
While developing this prototype, I gained practical experience designing data-driven gameplay mechanics, structuring modular Blueprint systems, and thinking about gameplay problems from a systems design perspective rather than implementing isolated features.
SKULLY RELOADED
Genre: Top-Down Shooter
Engine: GameMaker (GML)
Overview
Skully Reloaded is a Top-Down Shooter Prototype inspired heavily by “Nuclear Throne”, which was one of my favorite games at the time. My goal was to create a fast-paced, chaotic, and satisfying gameplay experience similar to the adrenaline-driven combat of that game.
Background
Before the pandemic, a friend introduced me to GameMaker. At the time I had no prior programming experience, so I began learning GML (GameMaker Language) through tutorials by Shaun Spalding and Heartbeast.
After completing several tutorials, I felt ready to start building something on my own. Through a combination of forum posts, documentation, and many YouTube videos, I gradually developed my first playable prototype.
Gameplay Systems
While developing this prototype, I implemented and experimented with a variety of core gameplay systems and mechanics, including:
Top-down character movement
Mouse-based directional shooting
A dynamic camera system that smoothly lerps toward the cursor within a limited radius around the player, creating a subtle look-ahead effect
Multiple weapon types with different firing behaviors
Enemy AI with patrol, alert, chase, and attack states
Collision and hit detection systems
A* pathfinding for enemy navigation
Random enemy spawning within the play area
Health and stamina resource systems
A power-up system
A score system
A top-down dash ability for player mobility
Although the project remained a prototype without multiple levels or progression systems, it was an important learning experience and helped me understand how many fundamental gameplay systems come together to create a responsive and engaging action game.
Game Assets:
Most art assets used in the prototype were placeholder assets sourced from publicly available asset packs.
The main character sprite was created by me specifically for this prototype.
I also have a small youtube channel where I make gaming videos.
>> Madorca Gaming
Here are some of the clips from the games I worked on through my journey. (Some are just from the tutorials)
