Dark Skies of Willowtown
-Catbear Games-
This game project, slated to have a steam release later this year, focuses on a master witch hunter and his apprentice, the player, who go to a small village to find things are not quite as they seem. By talking to NPC's in the town and using a mix of melee combat and ranged third person combat, designed to both interact with the environment and enemies, the player progresses into the mystery. The game features boss fights and thought out gameplay mechanics to combine multiple different gameplay styles into the players repertoire.
For this game title, I was both lead game designer and the lead programmer. Worked alongside Rebekah Leon, Seth Butler, Sasha Lvov, Ben Broer, Keyi, Jingkun, Ari, Jason Scalfano, Phineas Schulman, Tanner Wells, Liana Cannon,
Beta Gameplay Video
Software
Tools Used: Unreal Engine 4 - Blueprint Scripting, Blender - Animation creation and tweaking from Mixamo, Excel - balance sheets and damage statistic tests.
Process: Design and Implementation
As a third person mystery game, focus on the sword gameplay, crossbow gameplay, and NPC interaction was of the upmost importance. Starting with different games for research, such as the Witcher 3 and Dragon's Dogma, worked to create game baselines. These baselines included player speed, jump/roll distance, attack speeds, ranged attacks, and how to interact with the world. This process started with the player metric system, surmised by a infographic below. The testing room and full player zoo is also included below, designed to quickly iterate and test mechanic changes in a safe area of the project.
Branching from there, player combat and statistics were the next to be brought into play. Using a combination of written tests, done in excel to mimic statistics in gameplay, and with player feedback, I could create strong and meaningful mechanics. Combining the dodging capabilities of the player and, after user tests, the stamina meter led to enemies and combat feeling meaningful. Below is a test of ranged combat before and after feedback, specifically that players want to fully ADS with the crossbow, despite stating otherwise initially. All of the UX for players was part of the design process.
Testing the combat and player experience was a major part of the gameplay balancing and creating a strong, player centric, gameplay. Mechanics, such as the sword upgrades and enemy health was tested heavily. As the game progressed, more smaller mechanics needed to be created and fine tuned, such as specific respawn points and being able to find potions in more readily available portions. As the lead game designer, I took and synthesized my data from the game feedback in order to create a stronger gameplay loop. Below are screenshots of different mechanics that were tested for players.
The next component of the gameplay loop was creating interesting and complex enemies for the player to fight. For inspiration, taking from MMO games and large online games was the big component, as they have a small amount of enemies to the player, but some of them being very detailed. With the crabs, they can function as both a ranged and melee combat, being able to launch orbs at the player, while defending themselves in melee range by slashing, to fit with their crab appearance. In order to combat the melee of the crab, they are executable under half of their max health. I made this decision to give players more options when dealing with these smallfry. (Character models by Liana Cannon)
The miners originally had a rather bland moveset, with only one interesting attack. After testing, it was revealed that they did not have satisfying combat, as shown in the above video. Using more reference from games such as Dark Souls and Elden Ring, I transitioned them into more of a brute type character. Each attack of the enemy has a chance to chain into an additional attack, mixing up how the player needs to roll from the enemies or when to time their own attacks. This made them more satisfying and players were much more interested in fighting the miners. (Character models by Liana Cannon)
Finally, the boss was much more demanding from a design perspective, as it needed lots of different moves, fitting its aesthetic. Ultimately, having it be able to perform ranged and melee attacks at semi-random with abilities to stack onto the player led it to be the most loved enemy, to fight, in the game at the time. It is both a cinematic fight, and one to spend time learning to fight back, utilizing both ranged third person combat, and melee combat.
Process: Programming
While programming the functions we needed for the game to function, players to test, and for a strong video, the key feature was modularity with programming. As some members of the team were not perfectly proficient with coding functions in unreal, creating the scripts and blueprints for ease of access was of priority. Alongside that, the second priority was to create the backbones of the system, specifically dialogue, combat, and quests. All of those features listed above needed to be implemented in a strong and successful way into the gameplay of the game itself. Below are some examples of the modular coding and having level designer "hacks" built in so radius, pathing, and other features are seeable to the designers, making it easier on their part. Under those are images of the code used to create some of these, using construction script.
Plant obstacles that damage the player, if the player does not have a torch
Adds an item to the player, which the level designers can use a master list and a variable to set.
Adds the testing abilities for the ghosts to be able to function properly.
Plant obstacles that damage the player, if the player does not have a torch
The next phase of programming was to begin the background of the game itself. I started with the fundamental systems listed above and continued to make them as modifiable as possible for the game to work. This also let the Narrative team be able to create the dialogue for the game, using a preset excel file that I created and import into the engine itself. It uses a combination of a structure, enumerators, and excel imports to read the dialogue lines, export the information to the game, and be able to change on the fly based on the characters choices. This also led to creating the save games and the interaction system, based on both vision and modifiers for the player, letting level design teams be able to dynamically change vision detectors for the player, if something is far or close. Below is both implementation and creation of the narrative documents.
Sets up the current dialogue by reading the data structure, created by the narrative group
These determine what the dialogue is going to do, letting the narrative team not have to deal with too much Unreal
Sets up the current dialogue by reading the data structure, created by the narrative group
Combat and player maneuverability came next. Using line traces to detect the floor beneath the player, I was able to create a pseudo physics system for the game to function on. This allows a massive amount of usability when it comes to flying/area of effect enemies and player cinematics. The rest of the combat came in after those were created. I proceeded to make some of the AI and enemy ai as well, making sure they are unique in animation with and without behavior trees, to ensure proper cancelation and interruptions in the enemy code. Arrays of hit actors also are used in order to prevent characters from hitting multiple times alongside checks before and after attacks to confirm enemies can not attack when disabled. Below are examples of the player and enemy attack code in use for the game.
Determines what attack to use based on current state
Selects current combo number, animation, and the current damage type/amount to apply
When the player takes damage, determines how much, what reaction to have, and other components.
Determines what attack to use based on current state
Finally, once a vast majority of the game was created, bug fixing and user feedback had to come into the game in a large portion. While it may cause trouble, I find it quite enjoyable to find and seek some bugs out, yes I am aware that is a little weird. It is a problem solving event and some issues, such as a corrupted save file if a very specific chain was implemented in game, are things I want to be able to solve so that players never have to deal with it. It gave time to be able to come back and change/modify some components of the game, using UX, to make it a smoother and more enjoyable experience for the player. Below are some images of assorted code that has been fixed and sorted out throughout the gameplay process.