top of page
DARK SKIES OF WILLOWTOWN is a souls inspired, investigation and mystery-centric action combat RPG. Take the role of a monster hunters apprentice in a strange, dilapidated, town. Investigate the truth behind the town by getting to know the villagers, rescuing them, and finding out what happened to your master. Players can engage in investigation and combat in 4 unique open maps tied to progression. The player uses multiple weapons and combo-based attacks to fight back against multiple enemies and bosses, all while learning their weakness.
GROUP GAME
LEAD ENCOUNTER DESIGN
LEAD GAME PLAY DESIGN
LEAD SYSTEM DESIGN
SOLE PROGRAMMER
Winner of SCAD Entellechy 2022 - Best Game Design
SYSTEM FEATURES
Engage in souls-like combat with 3 unique weapons with their own customization options and upgrades. Each weapon provides bonuses in different situations
Investigate the town and all its occupants while you piece together the mystery of the main story and several side quests available to the witch hunters apprentice
Fight a multi-phase, cinematic, environmental boss with multiple approaches to taking it down
Explore several fully designed environments each with several of their own unique enemies whose logic works together to provide challenge
Use your journal and investigative skills to unlock new dialogue, discover secrets, and even save villagers before they get taken over
PRE-PRODUCTION
PRE-PRODUCTION
As this was a detective/investigation based game, the pre-production setup was very important in order to ensure that the scope of the game was accurate. This included several different components such as the quest progression, how dialogue should be handled, and the player progression as a whole. These factors also shouldn’t change since the team included a dialogue writer and a game quest writer who both need the information to stay constant.
The GDD held the pre-production information that was decided and how the systems will work with one another. This was where the rough flow of the game was decided and was stuck to for the remainder of the game production.
The player would start in the town and be required to start their investigation at a seemingly random point throughout the story. I added some features to give a bit of context to the player such as the implementation of a pre-game cutscene that fixes some of the story being lost on new players.
The mines were designated as the primary combat zone that featured two different enemies. I wanted this zone to serve as a training ground for different mechanics that the player was able to utilize, such as the crossbow, sword, and interactables. The narrative and design team communicated here to establish the runbacks and a narrative reason why the player should have the need to perform a run back through the mine to access a further part of it.
The ghost section was primarily headed by the design team and the system team since we wanted it to be both somewhere that the player needed a new mechanic, but also something that felt wholly different from the standard gameplay loop. The torches and ghost interaction, where they run from the player, were placed to make it a little more of a puzzle section, attempting to gauge where the end of the torch lifespan was and how to find a new one fast enough.
The final arena, where the player confronts what has been taking both their master and the villagers, I intended the player to have a cinematic experience and final boss fight to feel very satisfying in the end. Because the team knew that an environmental boss was being created, the level design was adjusted to ensure that there was a section where players could fight an enemy within the environment. I had a strong hand in the mapping and design work for the whole final section of the game, as I was the enemy designer, combat designer, and sole gameplay programmer.
I worked heavily in pre-production to design a dialogue system and toolset that the entire team could utilize to create their own quest and/or dialogue for any creature, npc, or even a sign post. This involved a toolset which converted lines of dialogue into an excel sheet which could be implemented as a data table into Unreal Engine. I also had several mini-”Workshops” that were used to teach the members of the team how to correctly utilize the dialogue toolset.
I pushed to have this finished in pre-production because it would be necessary to create dialogue and any text that the player needed. It allowed the narrative team to work side by side with the design and programming team, myself, to not leave any dead time during production. This helped keep the agile workflow better and always have a testable zone.
COMBAT DESIGN
COMBAT SYSTEM
As this was primarily a souls-like investigative game, the player combat needed to be tight, responsive, and feel impactful. I worked on the combat systems by adding multiple different weapon types that would enable the use of some player familiarity and skill within the system itself. The player had access to three different weapons, two to start with and one towards the end of the game. The sword and crossbow were both available at the beginning of the game while the musket/blunderbuss was at the very end of the game. This was intended to provide more gameplay options without the need for abilities or extra features that distract from the game itself.
The sword was the primary attacking feature and I designed several iterations on the gameplay. The first iteration used walkable combat so that it felt fast paced and moved properly. Since the enemies had static animations, the player was always too mobile for them to succeed in damaging the player. After player testing, I changed the sword to be static/root animations instead. It provided necessary thought in dealing with enemies as they were locked into certain animations and gave more strategy.
While the player never gained any abilities, I designed the swords to be upgradable to provide a sense of growing strength in the game. Visually, I wanted the swords to begin to be corrupted with the evil force of the game to show how ingrained the gloom is in the world. The blacksmith acts as a story/function unlock since they are locked behind some investigation. It ensures that players can’t get too powerful too early.
The crossbow serves as the ranged weapon for the player to utilize in combat. The player is able to aim down sights with the crossbow for additional damage or use it as a free stun for certain targets. The damage on the crossbow was kept intentionally low since I intended it to be a combat tool not a combat weapon.
As the crossbow is primarily a tool, it can be used to interact with combat. By adding these targets, it rewarded both skill and game knowledge. Players can shoot at overhangs to cause them to drop, instantly killing the enemies on top. Since the overlap checks were placed close enough to the enemy spawns, a player usually did it by accident and then learned
The crossbow was also a toolset against the boss enemies that the player encounters. Since there was no way to refill bolts in the boss fights, the bolts could be used to get a mini-stun against the boss. It would stagger them for a few seconds. I selected this to give players different options to how to engage with a boss fight and a handful of get-out-of-jail cards.
The gun was the final weapon that players have access to, because it was given to the player literal steps before the final boss, it was necessary to complete the fight. Unlike the crossbow, the blunderbuss was on a cooldown instead of a finite resource. The reason for this is so that the player can learn how to use it during the boss fight. The player must break a pillar to collapse it onto the boss in order to fight it. With a finite resource, there was a chance for a soft-lock, but with a cooldown based resource, there wasn’t a chance of that happening.
The player could interact with combat through additional actions as well, such as rolling and using finite health potions. The roll provided invincibility frames but also the ability to interrupt enemy attacks. Players were able to roll into an enemy to apply a brief stagger and interrupt their swings or charges.
While not a direct addition to combat. The healing wells provided locations for players to gather their flasks and their bolts. It facilitated combat but, importantly, did not act as a save point should they die in game. The design and system team wanted save points to be milestone locations, but also to have enough heal stations to be able to gather bolts back again before a major stretch of exploration
ENEMY DESIGN
ENEMY DESIGN
I was the enemy encounter designer and enemy system designer for Dark Skies of Willowtown. The goal was to have all 5 enemies, including both bosses, feel different from one another and require a separate approach. The design philosophy that was outlined carried into each aspect of the enemy; their visuals, moveset, and player based interactions. The enemies were also designed to not feel oppressive once a mechanic was discovered about them, such as the Gloom Spider, which is able to be stepped on.
The Gloom Spider was the most plentiful and constant enemy. They were designed to be a nuisance as a group, but never a real threat for just a solo player. It had 3 different attack types as well as a unique interaction with the player. The vision for the Gloom Spider was to serve as an introductory enemy at the beginning and then a constant feature towards the middle and end of the gameplay cycle. The spiders functioned as both a melee and ranged enemy, able to attack the player from a distance with some projectiles, or to strike the player in melee after charging after them. The spider also, since it was low health, would occasionally attempt to make distance from the player and try to use ranged attacks again.
At around ¾ of their maximum health, the player is given a prompt to “squish” the spiders. This is visually represented because of the big bulbous green ball on their backs. The squish VFX matches the colour and the brief animation plays to show it occurring. This was added as a quick way to deal with the Gloom Spiders. Since their vision was to be fodder, instead of having to slash them a few times, the player can instead execute them easier, matching the goal of the enemy
I wanted the spider to feel like it was different based on how it was attacking the player in the first place. The spider would shoot green coloured projectiles if above a certain height from the player. If the spider was on the same Z plane, it would fire a projectile across the ground. Originally, it always fired projectiles, but felt that it was disjointed from the point of it being in a mine. Using the ground projectile attacks, the spider fits the mine aesthetic and shows it utilizing the terrain.
The gloom miner is the second enemy, in progression, that the player would encounter. Because of this, they had a more interesting gameplay kit and move set that was designed to give players a taste of higher level combat. The Gloom Miner went through several variations before it was solidified into the final version. The first version was very in-organic and represented what the creature would have done by being a parasite on the enemies. It didn’t fit the speed of combat and often resulted in the enemy being skipped or turning into a health sponge which was negative on player experiences. By taking inspiration from other game titles, the Gloom Miner became a brute style enemy, one that commits to longer attack chains but becomes a danger due to its aggression. That was received better in player testing as well as matching the design goal of the enemy
As it became more of a brute with unknown attack styles, I wanted to replicate that in its AI. Each attack has a chance to follow up with an additional attack up to a maximum. This plays into the attack style of a brute and keeps the player on their toes as their windows of opportunity are not clearly defined. It also prevents getting into a constant rhythm with those enemy types.
Since the miner does not have any form of ranged attack, the pull was added to punish players that didn’t want to engage with the enemy and instead use their crossbow. This was two fold. The crossbow was originally designed as a combat tool, not a true weapon and it fixes the issue with the original miner being too simple to kite.
A key point when creating the enemy was the flags to trigger their lock on turning while attacking. Without this, the enemy would either have to snap to face the target, or would be susceptible to infinite attacks from behind it. This turning flag allowed attacks with windup to rotate to face the player and then attack, meaning the player had to move around, rotate, or roll to engage with the target.
These “enemies” were placed in the gloom forest, second to last level, as a wandering/environmental hazard. They were designed not to be killable, but would follow the player around, dealing constant damage. The purpose of this was to force the player into exploring the region instead of running straight through the center of the area. The balancing of their damage to speed ratio was a very careful dance because too high and it would be too oppressive and too low meant players could run by it. This was done with a lot of play tests of the section.
The mini-boss, Gloom Knight, served as a mid-point and skill check for the players. It was designed to be foreboding and make use of the mechanics that they saw earlier in the mines. This meant taking some mechanics from the spiders or miners and utilizing them in a slightly different way. Players were meant to recognize what an attack was without getting significantly off put by too many new things. Since this was a mini-boss, a cutscene, custom health bar, and interactable gameplay mechanics were necessary. This also meant that the crossbow mini stun wasn’t a 100 percent success rate anymore, forcing the player to play skillfully instead of cheesing the boss. This boss was the most loved enemy to fight in all play tests and had lots of tweaks to it over production to get it in the right state.
The first unique mechanic designed for the boss is a stagger system. This was built into specific attacks of the boss and their animations. The boss would leave their sword lodged in the ground for a few seconds and struggle to pull it out after attack chains. This was an opportunity to attack the weapon and break it, staggering the Gloom Knight and forcing his sword to regrow. It was placed during an animation where the knight could not attack back in order to give the player the opportunity to learn the move set
Their attacks also covered an AOE, which is the first instance of this for the player. The rocks coming from the ground forced the player to disengage and reassess. This was a good change of pace for the fight which typically was fast paced.
This attack is an evolution of the spider's ground projectile. They share the same “charging” vfx so the player can recognize what it is. The change is the speed, area, and damage that the ground projectile has. It matches the design goal of being something slightly familiar but is also a skill check. This was also decided since the VFX is slightly harder to tell against the ground, so having something they have seen before prevents enraging movements of “phantom hits”
The final boss was designed to be a cinematic and over the top conclusion to the game. The boss had 2 totally distinct phases which changed both where and how the player fought it. The goal and design philosophy for the boss was to create an encounter that was cinematic and engaging for a player in a different way than before. The whole arena was part of the fight and required each section of the players gameplay kit to succeed. The boss incorporated destructibles, gameplay cinematics, and new strategies to the player throughout the different phases.
The arena was arranged so that the player was near the boss's head on the balcony. The boss takes swings at the player and must be baited into certain sections to collapse a pillar on themselves. The gun and crossbow also provide the ability to take out a pillar early and collapse it onto the boss
As the boss takes damage, the armour that he has visually shatters as a destructible. I made this decision to show that as an in-universe health bar for the boss instead of giving a big UI element. Similar to the health strikes on the back of characters in a game like Dead Space, the bosses' shattered armour represents their remaining health bar. The armour is able to be shattered if the player is able to bait the boss into attacking the pillars. They collapse onto the boss, staggering it and knocking them back.
The boss could also interact with the stage and balcony that the player was standing on. This required lots of forethought and communication between the design and the art team. The platform was broken into several different sections that the boss could shatter, forcing the player to jump or fall and take some damage. Originally, falling down meant the player was dead and was unable to continue the fight, but after feedback, it was changed to allow the player to keep fighting, but take heavy damage. Jump distance was heavily considered during this fight as well and tweaked for the arena specifically to allow easy crossing of the gaps.
The boss was primarily interacted with from the balcony. After the boss takes enough damage and the heart is hit enough, they will drop the heart to the ground. This then is attackable by the player in the same way that the spiders were, with an interact prompt. Not only does this call back, but it also puts an environmental fight onto the ground as well instead of just a gimmick style fight.
QUEST DESIGN
QUEST DESIGN
The quests were designed by the narrative team, but I focused on creating modular quest systems with objects that were able to be added/removed quickly to expand the list of available quests. A flag system was used to denote when a NPC was able to talk about certain events or when items needed to spawn on map load. These two systems combined into the total quest system. It was made extremely modular so that the set dressing/level design team was able to drag and drop the right items in the correct location without needing to add any features.
​The journal was added to the game so that a player could easily see what they needed to do, what clues they have, and be able to piece together their own opinion on the game's storyline. It held different sections so that the players could learn about different characters or important key words that they discussed previously or found out in the world. The journal had additional tabs added with player feedback so that they always had access to their previous information
Clues were different flags that can be added through a quest, object, or via dialogue. The clue system of the journal allows a player to readjust the priorities of what they think is most important in the game
The people tab provides details on the NPC’s so that the player can establish what their normal routines and events are.
The quest tab provides a little bit more feedback on where a player is in their journey through the game.
​The NPC’s quest and dialogue system go hand in hand with one another. They both are built on the same general system of flags. For example, by picking up the shovel, that flag is saved into the player's save game. Once you talk to NPC’s that flag is read and then able to be talked about. This lets lots of dialogue options be added but also hidden from the player until certain points come up. Any dialogue that a player has not tried yet will remain yellow and not faded. This prevents players from forgetting what they already heard or not.
The game is designed to be more open from a player perspective. The player can interact with or pick up any item that they want from the world at any time. This means that late game clues can be picked up early, the player just would have to find them earlier. While this provides a lot of different routes to go about solving the mystery, it may provide issues for players that want to follow the intended storyline at the right pace. The journal system pairs with the quest sparkle system to alleviate this. Any clue that is at the top of the journal will have a VFX sparkle on it in the world, drawing a player close to it without exposing every single secret in the game.
PLAYER IMPLEMENTATION
PLAYER IMPLEMENTATION
The player was implemented as a sole pawn without many components, as the vast majority of the gameplay mechanics do not change regardless of what the player does. They will always have a sword, crossbow, and, later, the gun. They don’t find new things so the player pawn is a typical setup with the input system
Animation for rolling is a root motion where the root was given keyframes to adjust the exact distance of the dodge roll. This value was able to be adjusted to get the correct feeling of combat. The flags and notifies to start/cancel the invincibility frames were also built into the roll animation, allowing exact frame timings.
The first addition for the player is to establish what the norms for the player are. These are the movement speed, jump height, roll distance, roll height, etc. Without these, the level could not be developed using the correct player archetype. There would be mismatches or distances would be too long to cross with a jump or roll. These are added directly to the player or in the animation.
The character attack input was driven based on the specific attack key that was used. When pressed, an animation montage fires which puts the player into a specific state to play the animation. Just like the animation for rolling, the start/stops of the hit boxes were located in the animation notify. When triggered, the hit box, matching the sword +/- 15 units, is triggered to check whether a target it hit. An array stores hit targets to prevent any double hits and is cleared post attack or attack interrupt. The gun is also a single button press without going into the ADS like the crossbow. The attack damage type (stab, blunt, slash) is also set so it can be used by enemies hit.
The crossbow ADS puts the character into the aim state. That is triggered in the animation blueprint which keeps the arm extended in the correct position. While aiming with the crossbow, the ADS flag is set to true and prevents attacking with the sword, instead shooting the bolt with the left mouse button.
The lock on system for the player was implemented with a tick and delta time. While locked on, the player's movement in the animation blueprint changes tracks and becomes strafing movement primarily. The delta time and speed of lock on rotation is quite a bit lower than instant so that there is the ability to move around the world a little easier while locked on. This was added for enhanced abilities to dodge attacks such as the miner pull and the AOE on the Gloom Knight
The VFX were also attached directly to the animations, such as the sword swing. This was done by cycling exact frame by frame start/end of each visual effect attached to a character.
QUEST IMPLEMENTATION
QUEST IMPLEMENTATION
As mentioned before, quests and dialogues were built using a toolset that converts a line of dialogue text into an excel sheet. That sheet was converted into a csv and then implemented into the engine using a structure that contained dialogue information. Quests were done in a similar manner, by selecting different flags that look for and which ones are rewarded at certain quest points.
The dialogue uses a text, speaker, line to, and reward column to generate the visuals on the screen. As a dialogue option is selected, the line to will pull the next dialogue option that was necessary. If that dialogue continues or has different options, they are all listed as the same line number to have them generated at the same time.
Based on the reward column and line to, the interface will generate the appropriate text based on the answers. The first thing that it looks for is a line in order to confirm what they need to generate next and who is saying that line of dialogue to get the correct image and title. The next thing it looks for is a reward. That information is sent to the npc who requested that reward info.
The reward information that was presented to the NPC is handled via the incoming string. It then is filtered with a switch to determine what to do with that string. This was done because each NPC may have an auxiliary command to execute when they need to do a reward. This could be walking to a new location, disappearing, or advancing the story even
The NPC dialogue is also regenerated on each dialogue press. This allows one interaction section to unlock new options without having to talk to the same NPC again. When the player selects an option, the flags are rechecked every single time, as well as the read/unread checks on the dialogue lines which are saved into the save game.
This is an example of a handled NPC reward that advances the story, or an auxiliary command. An NPC evaporates and disintegrates, opening up a new section of the map.
The other section of quests are the quest items or overlaps that trigger events for the player. The items were generated off a single base item. This allowed different features to be added to every single item at the same time. When placed into the world, the designer was able to select, from an enumerator, which quest item it was. On level load it would then generate the item and determine if it was active in the clue list.
This is an example of how to swap models based on the item that needs to be picked up or utilized. Based on the type of clue, and the number, it would pull the static mesh data base and check if the player has it or not. This actor handled adding and dealing with any clue or quest items.
PLAYER ZOO
PLAYER ZOO
The player zoo was where all components were tested for the implementation into the final game. This was the most important testing level since it confirmed the validity of different mechanics, quests, and enemies. This was also where the different player metrics were confirmed and decided upon. The player zoo was in use from the start to the end of the entire game production lifetime. The player zoo was split into different sections that were used by different team members, primarily myself, to implement or test the features that were in the game. The four sections were enough to hold the different mechanics, as the game was not a mechanic heavy title, but just enough to create expansive content.
Each NPC was added into the quest section with all clues available around them. This was to ensure there were not any failures in the game as they were tested often. When a failure was found, the NPC has a flag which paints their model grey, indicating to the team that they are not functional or have an issue and to avoid them when testing the whole map.
The alternative world section provides a spawning space for the ghosts, torches, and dangerous plants. Each of these were tested for their damage formula, speed, and passability. This was where the majority of the issues discovered with the ghosts, mentioned above, were discovered.
The combat section had spawning types for each enemy in the game. This section was also complete with see-through walls that the player could pass through but not the enemy. This was to ensure that enemies were tested to make sure they couldn’t run into a safe zone to chase the player. The spawning system on the ground had an enumerator to select which enemy to create and how many
The boss section was made up of two areas, one for the Gloom Knight, and one for the final boss. Each section had all the necessary components to make the boss fight function, such as the cutscene triggers and the crumbling platforms. This was used to heavily test the final boss and the way it shattered the different platforms accurately.
FINAL MAPS
FINAL MAPS
After fully testing and confirming the success of each mechanic, they were implemented directly into the game maps before the final art passes. This let me test the collisions, modify them, and get the scale of the overlap boxes/collisions. The set dressing team, narrative team, and myself used the assets and placed them onto designated locations while constantly testing the accessibility of the clue items or interactables
The village was primarily tested for out of bounds access and soft-locks. The objects were placed and the NPC’s had their walking locations or walking paths added properly.
The mines went through a few iterations to get the right level design, but in terms of the systems available, it was similar to the village. The testing and important item placement was the hanging ledges for spiders and the assorted kill boxes.
The final biome, the Gloom Forest, had a lot of system testing for the shipped version. The ghosts, AI nav mesh, and walkability was very important for the whole level. There were also lots of “skip” points that needed to be addressed, since the level was heavily set dressed. These included collisions that were tightened up and the speed of the level as well.
bottom of page