Oh hi, I'm Kyle

Big Bosses

My favourite part of working on Ember Knights was designing the Boss encounters since they allowed for more elaborate encounters. 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.

Each boss would end up with a good mix of actions that required the player to pay attention and ones that were there to cool and impactful.

Playtesting and balance came down to making sure every attack was fair, that it had appropriate cues, anticipation, and collision, then tweaking values like damage, speed, duration, etc. When the values were adjusted and I could beat the boss without getting hit, I felt it was in a good spot.

Design Challenges

• All player progression was in a single system and was too constrictive for players and for design
• Our in-run progression from Relics didn't provide enough meaningful gameplay changes and weren't fun
• Level exploration was tedious, and combat rooms were cramped and very samey, and they didn't support 4 players very well

For player progression we broke it out into multiple systems. Permanent bonuses could be purchased/upgrades with a meta currency, divided into tiers where only 1 bonus would can be active at a time. New Relics -- in-run progression -- were automatically unlocked via defeating cumulative enemies. New abilities were unlocked by defeating MiniBosses and Bosses. New weapons were unlocked automatically by accumulating the meta currency, but didn't require it to be spent. These changes let us better control the pacing and order of unlocks, and also have the player multiple goals to work towards at one time.

Relics mostly gave passive stat boosts to the player, which didn't noticeably affect gameplay. I redesigned their functionality to be more of a 'trigger and effect' system, where whenever the trigger was met, the effect happened. An effect could also act as a trigger, meaning Relics could combo with each other and make longer chains of effects. This added more replayability to make different Relic builds and look for broken combos.

The level exporation we ended up scrapping entirely. Instead of a dungeon-crawling style map, we went with a linear room-to-room approach where the player would choose from 1 of 2 rewards for their next room and the game determines what the layout and enemies are. Every room would have a reward now, where previously some rooms didn't and were just paths on the map.

We remade nearly all of the combat rooms since they could now be whatever size and layout we wanted them to be. We could also now have different rooms sizes based on the number of players in the game (up to 4 players) since the rooms didn't need to fit into a grid anymore.

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
• To test out boss concepts quicker I made basic animated 3D models and converted them to sprites. We could get them hooked up, playable, and tested in game without taking up resources from the Art team
• Gave reference and feedback to the artists for level designs, character and enemy designs, animations, UI designs, icons, and more
• Took over handling the main narrative, wrote all the dialogue for the game, storyboarded all the in-game cutscenes
• Worked directly with our external sound designers and composers

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.