Oh hi, I'm Kyle

Big Bosses

My favourite part of working on Ember Knights was designing the Boss encounters. They allowed for more engaging and elaborate encounters, to test the player on various mechanics they’d seen in the level preceding the boss, to hit them with something new, and to give each Boss their own personality and identity.

I wanted each boss fight to have a balance of actions that fit their theme, that tested the player’s skills, and had a level of spectacle to them. I was okay with an action that was relatively easy to dodge if it looked cool, the same as if it were an action that required the player to really pay attention to cues.

I also wanted to make sure that the difficulty didn’t come from simply throwing more ‘stuff’ at the player and overwhelming them. Positioning, spacial awareness, reflexes, timing, all of it was important. Once I got a boss design in a spot I was happy with I would playtest for balance: making sure there was appropriate anticipation on every attack, that the zones where players took damage were fair, that visual cues and audio gave players the required information. If I could beat a boss without getting hit once, I felt it was in a good spot.

Design Challenges

The project started out as an action RPG focused on story and with gameplay closer to Diablo. We determined the scope was too big and scaled it way back, taking the combat from our working prototype and starting to mold it into what eventually became Ember Knights

The most challenging time for Ember Knights was after we had launched our first public demo. Our initial ideas for level design, meta progression, and in-run progression weren’t received as well as we’d hoped and ultimately weren’t very engaging.

• Levels were randomly generated, consisting of rooms that were the same size but with different layouts. The game felt cramped, the actual navigation of a level felt slow and tedious, and the rewards for completing rooms weren’t satisfying
• Meta progression consisted of a large ‘unlock web’ -- like an actual spider web -- where the player would unlock everything in the game: more items for during the run, passive stat bonuses, new weapons, new skills, etc. This system was clunky to use, the passive stat bonuses didn’t have a meaningful impact on gameplay, and actually unlocking acutally impactful items like new weapons or skills was needlessly convoluted.
• The in-run progression consisted of collected Relics that mostly gave passive stat bonuses and limited noticeable effects.

To address the level design issue we scrapped the dungeon-crawler aspect and adopted a linear approach where the player completes a room, chooses 1 of 2 rewards for the next room, then moves forward. We made sure that every reward type was useful to the player, and always pitted similarly tiered rewards against each other. This new flow addressed the tedium or exploring and backtracking on a map, allowed us to design individual rooms of any size or layout, and kept the pacing of the gameplay high

To address meta progression issues we split the single ‘upgrade web’ into several new individual systems:

• To permanently increase their power players would collect and spend meta currency. The passive stat bonuses were all replaced with ‘choose 1 of 3’ upgrades with more impactful effects, like dealing more damage when below an HP threshold or rerolling random rewards
• To unlock new in-run Relics they would need to defeat cumulatively larger numbers of enemies and return to the staging area
• To unlock new Skills they would need to defeat a level’s Miniboss or Boss and return to the staging area
• To unlock new weapons they only needed to collect (but not spend) more meta currency

To address the in-run Relic issue I wanted to focus on noticeable effects and gameplay changes, a ‘trigger and effect’ system where when the player did ‘trigger X’, ‘effect Y’ would always happen. The system would also allow for the ‘effect’ to also act as a ‘trigger’, creating chain effects depending on the items the player had. This updated system would give the player immediate satisfaction for triggering an effect, it would allow them to customize their builds to make extended or ‘broken’ combos, and it added more replayability to try and find the most broken combos

Responsibilities and Creative Freedom

On Ember Knights I was given more responsibilities and also was allowed to stretch my creative muscles in various disciplines outside of design:

• During the Early Access period I managed the content to be developed, worked with a Producer to manage timelines and milestones, had final sign off on completed items, delegated junior designers, provided feedback and direction for artists, programmers, and audio designers
• Bosses in Ember Knights took a lot of art resources to bring to life, so it was very important that we got to test out mechanics and ideas before they got to an art pass. To help with this I made very basic animated 3D models and converted them into sprites that we could get in game and hooked up so we could playtest them as soon as possible
• Giving reference and feedback to the artists for level designs, character and enemy designs, animations, UI designs, icons, and more
• I worked directly with our external sound designers and composers
• I took over handling the main narrative, wrote all the dialogue for the game, storyboarded all the in-game cutscenes

Design and Development

Kung Fu Z was a new challenge for me because the prototype consisted mostly of a simple combat system and an art style, and I was given the task of fleshing out what the actual game would be for the first time.

From that base we would refine the combat more, I would come up with the flow of the game, new mechanics like abilities, gear generation, powerups, and sidekicks, the various progression systems, the monetization strategy, and nearly every other aspect of the game design.

I did a lot of research on other popular mobile games at the time for reference on how they were keeping players’ attention, what monetization strategies were the most successful, what level of direct interaction players were interested in, and how to apply all that information to the game.

KFZ’s development had a lot of fun moments where it was just myself and the sole programmer on the team riffing ideas and secrets and putting them into the game.

Design and Development

Dash Quest 2 was a lot of work, but also a lot of fun. This was the first time that I got to pitch an idea, have it be approved, and see it through from beginning to end.

For most of the production the team was: a producer, a programmer, and me. This project taught me a lot about time management, organization, and the value of having a pre-production phase. We had very little time to hit all of our milestones once we got running, so using that time efficiently was paramount to our success.

Design and Development

Before starting on new content I reviewed the existing heroes, minions, and spells, to make sure that each of them served an identifiable mechanical purpose / had their own identity. In some instances we had units that were nearly identical, such as ranged units with simple (and similar) behaviour of moving to a position and shooting.

Major reworks were outside of scope, but relatively simple changes like having one unit throw a projectile that bounced to other nearby targets, changing another to have a slow moving projectile that damaged enemies on the way to its target, and another that had a shorter range but pushed enemies backwards, along with stat tweaks, gave the units more varied use cases in different decks

Design and Development

Dash Quest Heroes is an endless running RPG. The player runs forwards and can change between three lanes: left, middle, center. To change lanes they swiped left or right on the screen. To attack they tap the right-side of the screen. To block they tap the left-side of the screen. Bosses utilized mechanics that targeted specific lanes. Some attacks would have the boss choose which lane they were going to attack and the player had to dodge, and some other attacks would target where the player currently stood, meaning the player could want to stand in a specific spot to make sure attacks wouldn’t box them into a bad position.

Because DQH was a mobile game, bosses would also make use of tapping on the screen. In a Goblin Queen boss fight, servants would bring her food during the fight. The player would need to tap the servants before they reached the queen so they dropped the food. In a Dark Elf boss fight there were totems that activated and buffed the boss, and the player would need to tap them to deactivate them. Bosses also had attacks that couldn’t be dodged but could be blocked if the player timed their block correctly.

The player being able to swipe the screen to change their position let us experiment with various mechanics, like hazards on the ground that are restricted to certain lanes, buttons on the ground that needs to be pressed, dangerous sections of the ground that must be avoided. To take alternate paths the player had to swap to a certain lane. The branching paths of the level design and the Quest system were integrated together, where the player would need to take alternate paths to complete quests, or would need to complete quests to be able to take new paths.

Quests were fun to design because we had already established a lot of tools and mechanics to support some variety: there are multiple regions and paths in the world, we can place objects that the player won’t accidentally interact with, we had a ‘main town’ full of NPCs, etc. The tricky part of quest design was aligning them with the nature of the game itself, that being an endless runner where the player’s goal is to get as far as possible. If the player has a quest step that requires them to end their current run they might not be inclined to abandon to do so, especially if that quest step didn't give any tangible (or usable) rewards.

I ended up going with a solution where whenever there was a quest step that required the player to go back to town, they would always get an additional reward for that step, which would be gold or consumable items, to make it still rewarding for completing those progressive steps. Incentivizing players to progress a quest step, get a reward, and do another run was the best of both worlds for a mobile game.