top of page
BOUNDLESS SKIES is an endless twin stick ARPG game, similar in control to games like V Rising. Players are tasked with obtaining materials and keeping order to save Haven, the last bastion of humanity in the shattered skies. By utilizing 12 skills, with 9 perk lines each, 6 movement skills, with 7 perk lines each, 45 different passives, 2 classes complete with skills and passives, and customizable consumables, combat and gameplay is how the player envisions their Island Hopper.
GROUP GAME
Lead Designer
Lead System Designer
Lead Game Balance
Lead VFX
Winner of SCAD Entellechy 2025 - Best 3D Team Game
SYSTEM FEATURES
With 10 combat skills, complete with a perk tree, vfx, and sound, 5 movement skills, 40 accessories, able to change gameplay entirely, custom consumables, and 2 character classes, there are over 15 equipment combinations.
Exploring 2 full islands with one being a NPC town and quest hub and the other a combat island. The combat island features 7 enemy types, a multi-phase boss fight, and variants of those spread over 4 unique biomes.
Player creativity comes first with their own gameplay style. Each combination results in nearly endless emergent gameplay and combos that could never have been planned.
​
Players engage with a full main story quest, assorted side quests that unlock as the player explores or completes the story, and randomly generated quest boards.
​
Nearly endless gameplay is available through the end-game content, a random gauntlet. Players are trapped on the island during a storm and need to make quick decisions to stay, leave, or go for glory and high tier loot
COMBAT SYSTEM
COMBAT SYSTEM
The combat system, and by extension the equipment system, was the most important system of the game, as it was an ARPG game. I was the core lead and designer for the entire combat system, including formulas, developing new content, and ultimately implementing these systems. The crux of the combat system was the equipment setup and the multitude of different combinations that the player could create.
The goal of the system was to create something extremely intricate for players that wanted it, but something that ultimately allowed every single player to find, or make, a playstyle that they loved. This resulted in each combination relying pretty heavily on emergent gameplay. Despite this, there were some gameplay mechanics that were designed to be paired with one another but it always was designed to take the place of two out of 6 equipment options. This allowed the pairs to be designed, but not dictate the entire gameplay to them. This was put into the classes, kits, skills, accessories, and even the enemy types.
These skills were made intentionally to be paired together, as they both generate a resource, or consume a resource, called “Geomancy”
The equipment and how skills can be combined is how the player makes their decisions on their gameplay style. The player has access to the following:
Two main combat skills. The combat skills are how the player primarily, apart from their class skills, would engage with combat. There are 10 combat skills that were designed to be unique from one another and in a vacuum, meaning I did not try to pull values or info from another skill to create a new one.
Up to 4 accessories. Each accessory could fundamentally change the way that a player approached an encounter. An example of this is the item “Delade’s Blade” which converts physical damage into a bleed. It reduces the immediate output, but increases the slow burn of an effect. These accessories were designed to be a unique modifier to each gameplay piece and had different niches to fill.
One moment skill. These are primarily abilities used to traverse the map. This was decided due to early play tests that the players would always pick a movement skill as one of their combat skills. It significantly reduced the amount of depth that a player could design for their own play style. There were 5 movement skills to fill this slot. In the definition of this system, a movement skill was something that provided the ability to move around, so dashes, movement buffs, or even ghosting (walk through any unit) were part of this
Up to 2 custom consumables. Each consumable was able to be custom crafted using different ingredients. Each ingredient contributed a different effect to the consumable when it was finished. This added to the goal mentioned earlier that unique playstyles per player was the focus of the combat system.
The damage formula and calculation is very specific and has different parts associated with it. Since there are different damage types, bonuses, and resistances, each one is calculated against the respective resistance and the overall defense of the target. This allows certain enemies to be resistant, such as golems to geomantic damage. The large part of the design of a damage formula was devising where the calculations of different sections needed to take place. As there were accessories that added flat damage, multiplied damage, or were even an additional instance, the location of each calculation in the formula was very specific
The damage formula essentially breaks down to the incoming damage, based on scaling, and the defense/resistance of the target. Those values are then calculated to output a final number. This formula works well for simple calculations but was not able to keep up with the different additions to combat, such as the accessories
Some accessories or skill effects are multiplicative which are treated at the very beginning of the skill damage calculation. An example is the “Twin Fang” accessory which provides a damage multiplier. These are done at the beginning of the formula to prevent any bonuses from being multiplied.
Accessories that are additional damage based, such as the “Spirit’s Amulet” are considered bonus damage. This damage is not multiplied by damage bonuses. On accessories, for player feedback, this style of damage is called “Bonus” damage and bolded.
When defense is calculated, there are also different sections that are needed to take into account, such as the accessory “Telarin’s Rod” which ignores defense. This is also where true damage is added. Ultimately with this change it added a different intro into the damage formula, multiple instances.
After damage is applied checks occur to make sure that there aren’t accessories or skills that require it. This is to check for things like on-hit effects or buffs. Putting it at the end ensure that the damage has been dealt and is not being checked against invalid targets or being added too early
SKILL DESIGN
SKILL DESIGN
Skills are the bread and butter for any ARPG and I designed Boundless Skies to take that and push it as far as possible. Each skill has 9 different perks which complement a different playstyle. This allows a skill, which may have no connection to a player's gameplay build, to be potent towards the end of their skill tree. These can be upgraded and changed at any outpost, a safe point, or the safe island. It makes each player have a proper decision since they will be stuck with it while they are out on the map. The visuals of each skill were also hand made and the colour/theming of the skills matched the general niche they were designed for as well. An example is the “Malignance” and “Gravity Well” both being “Control”, so similar colours or themes are shared.
Gravity Well
Malignance
Despite them being different, each skill had a few different pieces that were shared universally, such as cooldown and cast speed. Originally, there was only a cooldown, but cast speed was implemented to be able to benefit player builds that wanted to be able to cast skills as a reactionary action instead. The skills were also balanced around these and had different ways of starting their cooldown. I added the “Gravity Well” into the Delayed Cooldown category, as it was something that spawned an object with a lifetime. Delayed cooldown requires the object to have ceased life before starting. Different skills had variations on when they started their cooldown in order to keep them balanced.
Each skill went through different iterations that I developed. The skills were initially designed with a single goal, so the image to the right shows the skill “Whirlwind Blade”. That was designed to be a fast paced attacking skill with many small hits. That was the overall vision for the skill. This meant that every single part of the design process needed to uphold that goal, from the initial writing down to each perk in the tree. Every single skill went through this similar design process to make sure each one was designed to be unique.
The skill perks are designed to allow the player to make fundamental changes to how it functioned or was used in combat. A core example that describes this is the “Flare” spell. It starts as a melee cone yet a perk allows it to become ranged. It lets a single skill fit into different builds in an easy way. The perks also had to still uphold the goal, or theme, or the skill in the first place. Each tier of skill perk had a different use, such as the 2nd tier of every skill always having three options and each was a bonus to a base factor of the skill. An example of a 2nd tier is increasing stun duration or scaling.
To upgrade skills, a different type of currency was needed for each rarity of the skill. Once a perk tier was unlocked, it was free to switch to any perk in that tier. The currency could be unlocked by selling things, killing enemies, or completing quests. A “Forge up” system was also implemented to take 3 of a lower rarity and forge it into a higher rarity upgrade material. This was added after testing to prevent high rank skills from being un-upgradable
Each skill had a rarity assigned to it based on the complexity, ease of use, and efficacy. The rarity affects how easy it is to upgrade, how much they are to sell, and how rare they are from enemy or chest drops. I assigned these rarities to each skill as they were implemented into the game. The two examples below show how skills were assigned their ranks.
“Flashbolt” became common because it was a simple to use skill. It had a low cast time, low cooldown time, and was easy to build around. While it may not have been ultimately as powerful as some of the others, it was a skill which is easy to modify. The additional reason it is common is because of how many builds it is able to slot into. As a perk is able to change its damage type, it is able to be a simple addition to a new player's build, resulting in something more useful early game than late. This is something that a common rarity can do instead of something higher.
Whirlwind blade is a legendary not because of the damage output, which on paper is less than that of “Flashbolt” a common. I ranked this legendary due to the perk options and potential damage ceiling. The perks added a large layer of complexity and late game became monsters of damage output. This puts it into a legendary. The other reason is because players view rarity as a direct example of strength. When this skill was not legendary, it was never leveled by a player, thus not being used to its full extent. When it became legendary, it was used heavily and often had max levels because of a playerbases perceived power level.
CLASS DESIGN
CLASS DESIGN
The two different character classes both had a unique normal attack, passive, resource bar, skill, and an ultimate ability. Each character was originally designed, like the skills, with a goal in mind. The goal for the classes was condensed into their unique resource bars. The two character classes were built with full animations (some custom), full VFX, and designed to be well rounded. In-game, players can swap these at the home base freely when they want to. It builds on the sense that they can’t change certain things when exploring the islands with enemies on them, as mentioned in swapping skill perks. As there were two classes, making one a melee focused and one a ranged focused class provides players with different approaches to any encounter.
The design decision to give each class a resource bar was, in part, for players that wanted a more complex or mechanical interaction with the game. The classes were designed to be feature complete without relying on the resource bar for players that didn’t want to rely on being heavily mechanic based. Each class resource was generated differently in a way that related back to the overarching goal of the class
This character class was designed to be the long ranged character class. Because of this, a few considerations were taken into account when designing the character kit. Their resource helped to generate extra damage and rewards consecutive, and accurate, hits. This plays into the fantasy of being a ranged archer that uses the wind to their advantage. It is primarily used to keep at a distance.
Its normal attack is a chargeable arrow that grows in both speed and damage the longer it is held down. It provides different playstyles based on attack speed or raw damage output. Through feedback and playtesting, the normal attacks are now able to be used while moving. This gives the players more options, keeps the game speed akin to that of the other skills, and provides higher level gameplay through kiting.
The first skill is a trap with a minor stun and pull to enemies hit. This was designed to play into the “Control mage” playstyle that is common in other ARPG games. It provides a way for the long range class to control the battlefield to maintain distance. After testing and player feedback, an additional mechanic was added. This allows players to detonate the trap with an arrow. It was added to give a faster paced gameplay to a slower class as an option.
The ultimate of this character class is a thin projectile that reaches the edge of the map, while paralyzing enemies it hits, then returns as a wide line to hit enemies and cause them to walk in a random direction. This skill went through different iterations to match the theme of the archer class. Ultimately, this was decided because it gives a sense of power to the player alongside being able to control the game's flow or enemy patterns.
The visuals were wind based to pair with both the design choice of an archer and the wind that is present on the floating islands. The choice to make the wind green and teal was to separate it from the ambient wind and have it stand out against the many different biomes. I worked on designing the character visuals alongside their unique VFX.
The melee character class, scythe class, took inspiration from the many different ARPG games with the ability to gain bonuses from slaying enemies. Their unique resource fills based on killing enemies and can be consumed to modify any attack on their kit. As a melee character, they are naturally in a combat rich environment. Since the classes are just a kit and stat bonuses are not assigned to them, mobility was the direction this class took. The theme of the class is to feel like a quick moving, and dangerous, executor to enemies. Adding to the feel of the executor, consuming resources deals damage based on the enemies max health, allowing faster dispatch of bosses.
The normal attacks are simple left to right slashes that are quick to utilize the speed that the class aspired to me. Instead of a combo that requires multiple inputs without moving, these are the same damage regardless. It’s resource bar attack pulls enemies nearby, allowing for enemy mobility and not just player mobility
The skill of the melee class is split into two sections, a fast dash that damages enemies hit and a large area of effect. The dash went through several iterations. The first version being a dash that launched a delayed projectile forward. This felt disjoined from the rest of the character. The final version resulted in a dash which had 2 charges if an enemy was hit. This played into the gameplay fantasy of the fast moving and mobile executor. Consuming resources resulted in an area of effect blast that dealt damage to enemies. This combines with the dash to be able to get into a group and then deal massive instant damage.
The ultimate skill has 2 variations designed for different purposes. The first, non-resource version, is a spinning attack that hits enemies nearby multiple times. The purpose is to clear a group out nearby. The resource version is the only ranged attack the class has, dealing massive damage in a line. This was on purpose. An ultimate feels stronger because it does something the other skills can’t do, hit at range.
The colour combination of purple, black, and dark blue was used to match the theme of utilizing the slain enemies. It was also chosen as it stands out heavily against the target backgrounds and has a sense of power to it that any other skill does not have. Inspirations such as Destiny or other games added to the colours.
ACCESSORY DESIGN
ACCESSORY DESIGN
Accessories add additional depth to the gameplay available to the player. They were added to promote creativity in play style. These are fundamental changes to playstyle and are effectively passives that do not require dedication to the playstyle to activate, as they are passive and not active. The player is able to equip up to 4 different accessories at any time. This number was picked due to prototype testing, more below, that found the stat bonuses were too easy to hit soft or hard caps with more than 4 accessories. The play tests also confirmed that 4 accessories was the ideal situation to develop a character’s playstyle. Accessories had stat lines attached to them which modified assorted statistics on the player, such as health, attack, cooldown, or movement speed. These values were changed and balanced multiple times based on the rarity and overall strength of the stat line. This converted accessories into the primary way that power is gained throughout the game, as there were no level stats, just stats gained through an accessory.
This accessory is an example of filling a niche or gameplay feature. Building on the unique resource geomancy, it provides alternative passives to the resource instead of just spending it on a skill or effect. By providing these, it is designed to give more options to a player build by splitting a sub-class into several different sub-types of it.
Some of the accessory testing checked the hard and soft caps for different stats and how well that allowed them to scale. For example, the maximum defense available, without any buffs, is X. That allows certain skills to deal Y damage. When comparing that to other builds, it became clear that the defense values were too high or the scaling on the skill was too high. This testing was done on each accessory to ensure that they were balanced and didn’t result in an instant power spike or over-defined meta game.
Each accessory, like the skills and class kits, were designed with a theme in mind. These themes took inspiration from other games but also were built to fill a hole in game styles. Since Boundless Skies wanted to focus on promoting player creativity, adding accessories to facilitate that is the prime focus for their creation. The passives were things such as being able to burn an enemy every few seconds, freeze an enemy every few seconds, convert damage to a shield, or even reset certain cooldowns. Those are some examples of the different passives available in the form of the accessories.
These accessories are upgraded to different ranks just like skills are. They use similar materials and currency to do so, keeping the currency bloat of the game as low as possible. Ranking up an accessory improved not only the stats added, but also the passive effect. This could be something like stack count being lowered, scaling going up, or cooldown going down.
Upgrade Example for "Aether-Tech Gauntlets"
Stat Block Comparisons
PAPER PROTOTYPE
PAPER PROTOTYPE
I built multiple paper prototypes in Microsoft Excel to limit test the skill scaling, create initial values for things, and test the validity of the game systems that Boundless Skies was built upon. The excel sheets were also developed to stress test the damage formula that the game was based on. This included every single accessory and where/how they were placed in the damage formula to ensure that they were calculated correctly. The sheets also grew over time to prototype the NPC shops, how quests affect their happiness system, and how the end-game content should scale. Each prototype sheet was heavily tested and iterated on before the systems became approved by me, the design and system lead, for implementation into the game.
The first rendition was establishing how the damage system was used in the game system. This included establishing the curves for defense scaling, how true damage is calculated, and where different damage types are calculated from. This graph was expanded on to also start to include the different game systems that emerged during pre-development, such as the character classes, different damage types, and as more accessories were developed.
The second combat prototype was developed to be passed around to the different members of the design team. They were able to use them to tweak values while the skills, accessories, or enemies were being added to the game in the first place. This prototype was easier to read and provided lots of places to add/remove buffs in order to simulate the exact situations that a player could find themselves in. It went further to add the different debuffs that enemies could have in order to grow the system simulation aspect of the game. The ultimate goal of this prototype was to create a system that, without a digital copy, could even be used as a physical or tabletop version of the damage system.
These additional sheets covered systems like the NPC happiness, quest infamy system, and the infinite scaling end-game. While these may not have been interacted with by many players, those that want to min-max the game would have interacted with them, thus resulting in the need to fully prototype them. These had input and output values so I could develop these systems in a way that would remain balanced.
The initial sheet was able to help confirm the damage formula by inserting massive, small, and other values for the player. These tests were done using multiple different equipment setups and were then utilized in the GDD for balancing purposes. After testing, there were minor points that needed immediate attention in order to shape it into a better system that could be used for Boundless Skies. These included nerfing and buffing certain build styles or accessories as they were clear outliers in different situations
The testing for this prototype included, as mentioned above, all of the different buffs or debuffs that the player could realistically engage with. These tests were used as simulations for the game systems that were an accurate representation of version 1 that was implemented into the digital game. Each test used the same equipment setups as the initial prototype which led to being a 1-1 replica of what was experienced in the game, barring the actual mechanical prowess of the player. This example is a high defence enemy, testing true damage and other settings.
These paper prototypes created an initial backing for the skills to start being developed. Without the initial values that started balanced, it would have taken a longer time, and more testing sessions, to confirm the balance of the game.
SKILL IMPLEMENTATION
SKILL IMPLEMENTATION
The skills were implemented from the design doc directly into the engine using parent-child actor components. While implementing, the goal was to create a modular system that was easy to tweak, add, or remove a skill from the game, drop pool, and shops.
The current skill data is read from the save game and then created when the player reassigns any inventory item or when they first load into the game level. The save game data of a skill contains a reference to the skill database, where the component data, scaling, and information is stored. This allows developers to perform balance patches without the need to reload/resave every single skill’s data. It pulls the data table row and then adds it to the player as a spawned component.
The parent skill component contained all the information that every single skill needed to utilize in order to function properly. This allows one change to propagate to every single child skill afterwards. Each skill was a child of base skill component which held the following info:
Cooldown. Timers were used to add, remove, or modify existing cooldowns
Cast Speed. Cast Speed had a timer as well as a condition saved on the data table for skipping cast time. This was used for perks of specific quick casting skills.
The cast hold VFX is a visual feedback indicator for skill being activated
​Activation triggers when the cast speed is complete and is handled independently on each skill
Additional Resources are used for when a skill needs to be activated. These are things such as selecting a perk or interupting casts
The purpose of designing the skills like this was that I, as a designer, could quickly, and easily, add a new skill to the game in very little time. It takes roughly 10 minutes to add a new skill to the game from scratch. The process is as follows if I were to add a healing skill called "Rejuvenating Bud":
Add any remaining data to the skill’s information in the GDD
Add a new line in the skills data table complete with all the important information such as scaling, cooldown, cast speed, and checks. While designing, also ticking the “no drop” boolean prevents it from being used outside the player zoo/testing map. Icon, name, descriptions also go here too.
Create a child of the base skill and add any effects that are needed to it such as activation effect, spawns, buffs, or other events
Create the additional spawning pieces, such as actors or effects, then apply them into the child component created in step 2. These are for things like a projectile or an AOE slam.
Once those steps are complete, the skill is ready to be used once animations or VFX are attached to it. This process is designed to streamline the experience so that designers can quickly add content to the game to keep it expanding and growing.
ACCESSORY IMPLEMENTATION
ACCESSORY IMPLEMENTATION
Similarly to skills, accessories were also designed to be modular, as they are the easiest to add into the game to create depth. They required a strong design, but did not require a lot of animation or VFX for the game. This meant that I could quickly devise more accessories to fill more content out for the game.
Accessories, being actor components, were able to be added to the player and are able to be checked by cycling through all of the actor components currently attached to the player. These are added when inventory changes or on load of a player into a new map, since we were not using level streaming for the maps.
The parent accessory held the standard information that was needed by a wide variety of accessories. This included the stacks, cooldown, and the ranking system that was implemented into a wide variety. Even if an accessory did not utilize the stacking or cooldown mechanic, it is still present if the developer wanted to implement one to any accessory or change them. It also held different events and functions to handle when an equipped accessory had their rank increased.
By cycling through the list of components that the player has, using a BPI call, it is easy to find out if the player has a specific component or class. This allows the accessory checks to function. This also returns the current rank and rank->variable map that each accessory utilizes to check the scaling of them. This check can be added into any section of the games code, such as damage formula, on skill cast, on enemy hit, etc.
Accessories were designed like this to allow quick addition of a new accessory or changing an old one instantly. The process to add a new accessory was faster than adding a new skill to the game, since there were less VFX or animations associated with them
Fill out the accessory table in the GDD and accessory data base
Add a new entry in the data table full of the scaling, information, cooldown, stacks, or other components that the accessory needs from a number standpoint.
Create a child of the base accessory and fill out the necessary information such as when equipped, when activated, if that applies to the accessory. Some of the accessories just need an empty component since it it handled elsewhere as well
Return to the data table and fill out the components information there.
The accessory can then be implemented into any formula or location that needs it by using a function or a macro to check if the accessory is currently equipped in the right spot. This spot changes based on the nature of the accessory, such as “Laevatein bands” in the screenshot being located in the “skill-on-hit” section.
PAWN IMPLEMENTATION
PAWN IMPLEMENTATION
Every pawn, from the player to the enemies, in the game stemmed from a single base pawn class. This is because there are several components that are shared across every single pawn in the game currently. These include things such as the damage handlers, death handlers, healing handlers, and general combat enablers. This also meant that players could be afflicted by status effects in the exact same way as an enemy can. Ultimately, this let each enemy have variations such as a poison spider or a weakening golem. This base pawn had a few components in it as well which facilitated this type of modular design.
The base pawn component included the following:
Handles when damage numbers appear or dissapear for enemy hits. It checks against the dealer to confirm it is not an enemy base. If it is, nothing happens. If the dealer is a player, the damage is allowed through to the UI instead.
Shield and damage sources are also handled in the shared pawn. This lets each pawn utilize the same formula for taking damage, starting with shields and then ending at the current health.
Status Effects are an important part of the game. Many accessories or skills can inflict, or utilize them, to unique effects. Each pawn is treated the same for a status effect. The status effects also have a base component, seen above. It is very basic, but the detail of each status effect is added into each version instead. That contains the following:
This is the bleed effect being added to the base pawn. It triggers the component and adds the bleed VFX which is scaled to match the pawn it is attached.
The status effect components are in two halves. The first is the visual effect the second is the damaging/gameplay related effect. This often is a nested timer, shown here for bleed, that triggers the repeating damage effect to the attached pawn.
Enemies are implemented by creating a child of the base pawn. Each enemy is also a child of the base enemy pawn as well. The base enemy pawn includes the modular logic for every single mob in the game. This is the shared information, such as the item drops, death, and teamwork components.
The loot table is a weighted table that can roll several items at the same time. There are also settings for pre-determined loot, such as quest drops or unique items that are required to drop from an enemy. These combine into the loot system shared by each enemy in the base enemy pawn.
A database governs each enemy and is read by the base enemy pawn via a data table row handle. Each row includes the stats, movement, class, item drops, and how they react during any moment that the enemy ranks up (the Luminstorm).
CLASS IMPLEMENTATION
CLASS IMPLEMENTATION
Classes were implemented once the base player was established and the class kits passed my design inspection. The player contained all of the movement data and initial inputs that were then sent to the classes themselves. Each class, similar to the skills and accessories, had a parent and child actor component relationship. If a new class was necessary, it was easy to implement them directly into the gameplay, not including their VFX or animation that needed to be created later. This follows the same path of making sure that everything is modular and designed to be easily copyable or modifiable.
A class was removed from the player, alongside the visual jetpack or weapon, when they were changed at any of the skill change stations. The skill change station brings up an interface to check the descriptions of each class. That data is pulled from a player class data table structure. When one is selected, the static mesh information for the weapon and the static mesh information for the jetpacks were pulled and inserted onto the player model. The component is also added to the player and given access to the class combat inputs, normal attacks, skills, ultimate, and resource bars.
Adding a new class requires more setup than the skill and accessory requires. The process to add a new class is the following
Create a child component of the base class so that it contains the appropriate data, such as cooldowns, cast speed, etc. Then fill the class action data, such as normal attacks, skill, or ultimate. Animations and VFX are also assigned here initially.
Fill in data on the class actions, these are the events that fire to activate a normal attack, skill, or ultimate ability. Animations are sent to the player skeleton while VFX are attached or played in the anim montage itself. The animation montage also includes states to activate, deactivate, or trigger the appropriate collisions to start searching for viable targets.
The database primarily holds the statistical and visual information for the classes. This is skill descriptions, icons, cooldowns, etc.
Once the database is set up, adding a reference via a data table row handle gets the information stored to fill out the numerical information for the player classes.
PLAYER ZOO
PLAYER ZOO
The player zoo is the first connection between implemented assets and the paper prototype. I take these very seriously as it also provides an appropriate location to fully stress test every skill, class, accessory, UI element, enemies, and interaction with the environment. I treated the player zoo as a staging ground for everything that ultimately goes into the final maps and shipped game project. This was both the first level that was designed and the last level to be modified. The player zoo contained many different sections that were each used to fully test every facet of the game. The player zoo is also annotated with text renders to give other developers ease of access and being able to wander around the player zoo without getting lost.
The first thing that the player zoo did was ensure that the player itself functioned properly. This meant the walk speed, vertical/air speed, how it treats inclines, how the player can maneuver the space as well. These were necessary before adding the player classes or additional skills since these values will not be changed later and can be built around them.
This section of the player zoo implements all player skills for being able to pick up and test. The player skills start at rank 0, but there are infinite spawning currency and resources in the player zoo to fully upgrade them or find any issues via a bug or missing functions. All movement and combat skills are placed here. This also was a place to test the item drop functions, chests, and VFX for item trails. Any new skill could be tested easily by copying the drop item and changing which data table it reads from.
Similar to the skill floor, the accessory floor had all accessory drops available in the game. They can be upgraded and tested for bugs and missing functions here.
All materials or non-active items are available here. This includes consumable crafting, key items, and quest items. The consumables can be tested at a crafting table located nearby and the quest items allow testing of any available quest.
Since the game is an ARPG, the height testing section is designed to establish what maximum targetable height or ground is for the player. Line is drawn from the camera through the cursor and, based on the height of the platform, will decide if it is or isn’t a valid spawn location. The height of the platform is also important due to projectiles and how they need to be tested. Once the height levels are established, a measuring static mesh was created to be given to the level design team. That dictated what counts as a “floor” and what doesn’t count.
The wall fading is an important aspect of ARPG games since it allows the player to be seen behind a wall. We debated about not having this but it felt less impactful without a fading wall. A line was drawn from the player to the camera and walls in the way (+/- 30 units) were given an actor component. The texture and material parameters were read from the current static mesh and a new material was created on top of the current one. This was to prevent overlapping translucent materials and cut back on overhead costs. That new component ran a dither to reduce the wall opacity without creating lag or too much resource cost. This was applied to every wall or object that could overlap the player in the player zoo as a full test to ensure that it was applicable to the final level.
All quests were testable in this location. This was for ensuring that the quest logic functions and was implemented accurately for the game. Each quest had a chamber with item spawns or other locations that were able to test the completion system and the quest flags. NPC dialogue and shops were also tested, since they unlocked different sections based on the completed flags set for the quests themselves.
All enemies had a room and spawner to ensure that they were testable from the ground up. This area had variable spawns that could create any group of enemies to test their logic in a group and on their own. So the spider bot enemies can group up with one another to test how they act as a team, while the golems were able to test their leashing mechanics and returning to a rock
The map traversal was also tested here and this serves as a map reload section. The map reload is for the quest items that are checked on map load instead of dynamically, since they would be located on a different map in the shipped game. The interface also provided information on the end-game content information as well as any other islands that the player could travel to.
Loot tables and chests were tested here. They used a weighted drop table to be able to put multiple item types together in order to have them drop at the correct rates. If an item of a certain subtype was dropped, say a rare skill, it would pick a random rare skill to add to the floor. There were also preset loot tables, such as “early-game weak enemy”, or “boss” which could be modified to make it easier for designers.
FINAL MAP ASSEMBLY
FINAL MAP ASSEMBLY
Once everything has been thoroughly tested with the player zoo, the systems and mechanics were implemented into the map. The level design team created the level layout maps in the GDD and then the set dressing and artist team would assemble the rest of the map. Important locations, such as quest markers, used a custom actor with an exposed colour slider and an exposed text renderer to mark where the assets needed to be placed.
The hub island was where most of the quests started or ended, the NPC’s would be located, and the majority of the interactables are located. This also had the tutorial section for it. These maps were assembled by dragging the components that worked from the player zoo and placing them in the designated locations for final setup. After those were placed, I would stress test the collisions, out of bounds zones, and the walkability of the space then make changes as needed.
The tutorial requires an npc walking a specific path and a certain chain of dialogue to occur. This is done with a tutorial component on the player and a spline that the npc will follow directly from point A to point B. The design team placed anchor points on how to get that npc from A to B and then I filled the spline for the NPC. The component was reading inputs at certain times to check if the player cast a skill or a normal attack. That advances the tutorial and uses a BPI to send a message to the interface to display the advanced tutorial
The combat island requires more work from a setup point of view. There are several components that were necessary for the setup to function as both an initial entrance and the end-game content.
The enemy spawns are an actor with an array of structures that designates what types of enemies can spawn, what size, strength, and groups also can appear. They also had a second feature for the end-game content so that they can keep spawning infinitely as long as there aren’t more than a certain number of enemies around it. This ensured that the player wasn’t swarmed every 30 seconds but also that the enemies would spawn towards the edge of the screen and not on top of the player
The quest locations were demarcated by the level design team with a similar actor to show where they wanted items placed. The quest items were then placed and different tags were used to identify the order that some of them were needed
The music and area designator actor was moved to anywhere that was a line between one biome and the next biome. Those biomes needed unique music and text to show up at the top of the screen. Using an overlap box, an audio controller actor that was placed in the level would be told to fade out or in a new track. The audio controller also handled shrinking the music when in combat to hear the combat sounds better. When the overlap happens, it also uses a BPI to message the interface to swap it over.
Audio Manager
BALANCE AND PATCHES
BALANCE AND PATCH NOTES
As the game progressed, I kept detailed notes on the numerical or substantive changes done to certain skills, effects, or attacks. These changes were made from play testing and how the players interacted with the environment. The patch notes were included on the main menu so that when a player boots up the game, they can check any updates made to their favorite build.
Adjustments were done based on the following criteria:
Too powerful? Does it trivialize certain enemies without needing to build into that playstyle?
Too universal? Is it a no-brainer to always have it equipped regardless of the playstyle that a player wants?
Non-thematic? Does the skill or effect not match the original theme or goal that was planned for the action?
Too weak? Is it never used or hardly ever touched in a game environment?
As an example, the skill “Gravity Well” originally had a perk which split the single projectile into two with a 10 degree angle between them. Originally this was made to give the skill a slightly different effect and provide some area of effect tools. It proved to be too hard to hit reliably unless the player was on top of the target. Enemies would also have a much easier chance to get out of the way. The skill was changed to a short range cone instead, pulling enemies hit in the cone radius. This contributes to the theme of the skill without making it instantly too effective at what it does.
An example of accessories: “Aether-Tech Gauntlets” increase damage dealt with every hit. The initial change was to increase the rarity, as it was incredibly powerful and the attack speed buff was strong. While this helped early game, it still made it reliable for late game. The adjustment made to solidify the game was to allow stacks to be lost when the player gets hit. It encouraged a risk and rewards style strategy that made it a non-perfect choice for almost every single build or playstyle. This change was a nerf but needed to maintain the balance and harmony of the game.
“Geirskog”, allowing healing on damage with elemental damage, was powerful but there was a lack of direct elemental damage. Originally, Geirskog was placed on the front of the damage formula, checking against the flat damage that was dealt. This meant that spells and abilities were able to allow healing. This did not allow bonus damage to heal. After fine tuning the numbers, “Geirskog” was moved to the end of the damage formula to ensure that all elemental damage applied to the heal and made it a bit more reliable on a physical build as well.
bottom of page