top of page
Fallen Guardians Poster.png

Fallen Guardians

A 2.5D Hack n' Slash RPG developed for Sheridan's 2016 GameMaker contest

Gameplay showcase

ROLES: Game Designer | Lead Programmer | Secondary Artist
TOOLS: GameMaker Studio | Aseprite
 November - December 2016 (2 Months)


Fallen Guardians is a single-player 2.5D hack and slash RPG where players strengthen the abilities of their character to ultimately defeat the Guardians that roam the land.

This project was developed by a team of 5 in just under two months for Sheridan College's annual GameMaker contest, achieving 1st place. I was primarily responsible for the game's design, most of the programming (excluding the inventory and NPC interaction systems), and a portion of the art (UI, enemies, VFX), however I extended my roles to include level design and overall polish.

After the contest, I continued to work on the project for another month to add new features, content, and revamp important systems of the game such as armor formulas, stat attributes, and a tutorial. These additional changes will be reflected on a separate page (still WIP!), explaining the design process and feedback response behind them.


After the theme of "fantasy" was announced for the contest, we immediately knew I wanted to create a high-fantasy role playing game. Inspired by the fast paced combat of games such as Dungeon Fighter Online and Black Desert Online, I quickly came up with 3 core pillars I wanted to implement into the game with my team:

  1. Abilities - Similar to MOBA's such as DOTA 2, Fallen Guardians looked to create a system where every unique character had their own set of abilities -- a passive, two regular, and one ultimate.

  2. Combos - This would be the primary focus of the gameplay loop. Along with their unique set of abilities, characters could also weave them in tandem with two types of basic attacks: a light attack sequence and a heavy attack sequence.

  3. Progression - As the world opened up for the player, I wanted to create systems that would emphasize their character growing with the experience they've learned.


Dungeon Fighter Online, where I got most of my inspiration from for this project


Combos and Abilities

My team and I knew we wanted to design a game with different, unique characters that had different playstyles while still keeping the scope small enough to accommodate the time frame. We wanted each character to have a skillset that was easy to pick up, but took some skill and understanding to master. Our team decided on three unique characters, each with a different difficulty curve to learn, however due to time constraints we decided midway to remove the 3rd character.


Elron's portrait in-game

Character A - "Elron"

We wanted our first character to be the "generic and simplest to learn" out of the two. To compliment this goal, we narrowed down a few ideas to complete them:

  • Thematically an allrounder, capable of both swordplay and magic

  • Very simple abilities with short cooldowns

  • Few attack combinations

Character B - "Quin"

Meanwhile, our second character would have the "intermediate level" learning curve. As such, we based her around these ideas:

  • Thematically an explosive specialist, leaning into an offensive specialization

  • Slightly longer cooldowns with bigger effects

  • More attack combination possibilities

  • Introduce secondary resource management


Quin's portrait in-game

FG - Combo Chart Legend v2.png
FG - Combo Charts Elron.png

As a result of our design decision, Elron's possible Combo sequences that the player can learn and master are very limited -- most of his core gameplay revolves around mashing the Light Attack button. We incentivize this style of gameplay even further by revolving Elron's stronger Heavy Attacks as a finisher to a Light Attack combo. Additionally, since Elron's Ability B can be casted at the same time as any of his attacks, the player does not need to worry about weaving it into their combo as it happens simultaneously.


On the other hand, we designed Quin to have many combinations that reward player creativity. Unlike Elron, Quin has a lot more ways to bypass her animation times. This is balanced out by the fact that her animations take longer to execute, so players who simply spam a single type of attack like Elron will see less success during their playthrough.

FG - Combo Charts Quin v2.png

Finally, both Elron and Quin's passives cement their respective playstyles by adding an additional layer of strategy that players will need to think about when engaging enemies:

  • ElronHitting at least one enemy with a Light or Heavy attack reduces the cooldown of all your abilities by 0.5 seconds. 

    • Players are rewarded for attacking as fast as possible, meaning that mashing Light attacks is the best strategy to generate the most value out of his passive.

  • Quin: Hitting at least one enemy with a Light (5%) or Heavy (10%) attack generates Heat. Whenever the character uses an Ability, spend all of your Heat to increase its damage by 1% for every point spent.

    • Instead, players are rewarded for mixing their combo up to maximize generating and spending their Heat resource to deal maximum damage.


My team and I originally designed this game idea to give each player a different experience based on their preferred playstyle. However, with the original design philosophy we had for the Ability and Combo systems, it meant that differing playstyles was only determined by the unique character you played. In the case of our contest submission, that would mean only two playstyles. That's where the "Progression system" comes in.

Originally, our game had very few stats shared amongst each character: Health, Armor, and Experience. The former two could only be improved by leveling.


Inspired by DOTA 2's attributes, I decided to add Strength, Dexterity, Intelligence, and Vitality to each character. These new stats could be influenced by leveling up (allowing the Player to allocate a point to a stat of their choice) or by equipping items.

These attributes serve two purposes that greatly improve playstyle variety:

  1. Each attribute raises other certain character stats. For example, each point of Strength increases the character's Attack by 3 and Health by 2, while Dexterity raises the character's Attack by 2 and Attack Speed by 3%.

  2. Abilities can improve based on their attributes' scaling, seen in the tooltip examples below. Generally, each attribute has an average efficiency per point at which they affect an Ability's values. This meant that our designers could quickly reference them so that our values were more balanced in the first iteration.


This Ability uses only a single attribute to scale its damage: for every 1 point of Intelligence the character has, increase the damage of this Ability by 8.


But Abilities can scale with any attribute that the designers can tweak easily, as seen in this second example.

Now, Players can have more deliberate choices over the way they play the game that extends past just which character they've chosen -- Even though Elron is great with Dexterity, the Player could put their points into Intelligence to greatly increase the damage of his Abilities or Strength for a more rounded build. Despite the added complexity (for both player onboarding and programming work load), it was actually a very quick and efficient implementation that was well received from our play testers!

These two components together meant that players could play the game without being completely limited to the designers' decisions, and at the same time allow for endless creativity for the designers to shape the personality of our game through the unique characters.


This project was my second chance at creating a month long game with a small team. In all honesty, it was definitely over our scope to design such a complicated game in a short amount of time with the little experience we had with game development and was filled with long crunch periods. However, I was glad I stuck through with the work load because I learned a lot. From better programming patterns and efficient animation workflow to general game design, this was my first experience pouring countless hours into a game I was genuinely excited to learn how to create.

It also taught me just how many features that we had to push aside to maintain an unreasonable scope -- unfinished menus, no sound effects, visual bugs, etc. were all present during the contest. Lack of player onboarding and unfair difficulty was also a big issue when getting fellow game developers at the contest to try out our game.

Another important factor that I learned was understanding which audience that matters the most. Even though we got mostly positive feedback during regular playtests (where play testers could play as long as they wanted), the judges during the contest had less than 5 minutes to try out our game. This meant that they couldn't get into the main gameplay loop due to the difficulty floor, which definitely affected our score.

Despite the many negatives with this project, my team and I managed to win 1st place amongst 20+ other groups which felt incredibly gratifying.


My team and I (on the right) claiming victory


The competition floor, where judges and contestants could try out other teams' games

Anchor About
Anchor Conception
Anchor Abilities
Anchor Progression
Anchor Takeaways
Fallen Guardians Poster.png
bottom of page