Lichgate
Game Designer
Replayable Survivor Action Roguelike made in a custom engine in which the player obliterates hordes of undead with magic, to grow in power and prevent the Lichgate from opening. However, enemies grow in strength and numbers, as they don’t take kindly to this attempt!
Project Info
Genre: Survivor Roguelike
Project Type: Team
Timeline: 8 Weeks - 2024
Engine: Coral Engine (custom engine)
Platform: Windows & PlayStation 5
Released: Itch.io
Key Responsibilities
Designed and Implemented: Core Gameplay Loop & Combat Dynamics.
Designed and Implemented: 3 Unique Enemies fulfilling different design intentions.
Designed and Implemented: Meta-Progression, reinforcing a Bite-Sized experience.
Designed and Implemented: Onboarding & Audio-Visual Communication.
Designed and Implemented: Local Multiplayer Mode.
Designed and implemented: UI/UX.
Prelude
As developers, we wanted to highlight and leverage the strengths of our custom engine, which led us to create a survivor-type game. The initial design draft was guided by reference research (the primary reference was 20 Minutes Till Dawn).
Using reference research and target audience research, we defined our target player experience (pillars) and guidelines.
A key challenge that we faced was a tight & unforgiving 8-week production schedule, as we needed to develop the demo game in parallel to creating engine features & tools.
Limiting the scope, avoiding bottlenecks, and being risk-averse were essential to the success of the project.
Player Combat - Weapons & Upgrades
Combat Framework
What
Designed a flexible and scalable core combat/weapon system that supports unique weapon mechanics, supports iteration for the design team, and allows for future expansion through upgrades.
How
By analysis of combat, upgrades, and effects in reference games, I created a document listing potential weapon variables (e.g., attack speed), events (e.g., on-hit), and functionalities (e.g., damage over time).
We narrowed it down based on the first weapon draft, design priorities, and technical feasibility.
Along with a breakdown of the weapon framework and information on what needs to be exposed to the design team, this was used to communicate the system and its capabilities to the programmers.
Why
Given the tight schedule, we needed a flexible system that allowed the design team to experiment and iterate with weapons and future upgrades, without major refactoring or delays.
Weapons
What
3 Weapons, targeting different playstyles and player groups.
Shoots a damaging projectile on release. Holding will use more mana (ammo), progressively increasing damage, size, and penetration.
Shoots damaging projectiles.
Continuous fire ramps up the attack speed and decays once
fire ceases.
Conjures a sword that deals damage in a frontal cleave. Reloading performs a special “Bladestorm” attack.
How
Guided by combat analysis and target audience research, intentions for weapons were defined. Weapon design was aimed to fulfill these goals within the existing framework.
Each weapon was communicated to programmers through a pseudocode flowchart and definitions for unique variables & functionalities, as well as how weapon framework variables influence unique weapon behavior.
Through playtest & iteration, they were refined & validated.
Why
The target audience is mostly divided between players gravitating toward passive or active gameplay and consists of players blending Action & Mastery profiles (Quantic Foundry motivation model). Spreading the weapon profiles would also help us further define gameplay dynamics and cater toward a wider part of the target audience & skill range.
Upgrade System & Principles
What
An upgrade system, consisting of multiple trees and upgrade tiers, with cross-tree synergies. The system is designed to naturally onboard synergies and increase the chances of obtaining them.
Tier 1 consists of minor synergies, a starting point (e.g., stat or effect) that does not seem to synergize at first glance.
Tier 2 consists of major synergies, they are the bread & butter of the tree, defining and driving the fantasy home. This tier also foreshadows upgrade tree synergies.
Tier 3 serves as the capstone of the tree (most impactful upgrade), doubling down on the fantasy/playstyle.
Tier 4 is the result of combining two trees and provides a very powerful upgrade.
It creates a bridge between the trees and ideally should provide a scripted synergy (e.g., Piercing Tree + Damage Tree = “Projectiles deal 25%
more damage for each
enemy pierced.”)
How
I researched different upgrade systems and the differences between types and rarities of upgrades in a variety of games (focal point rogue-like/lite).
Guided by power growth as part of our core player experience, I designed the tier system and corresponding design guidelines.
I compiled a list of potential goals based on the research to further guide the design of the upgrade delivery system under consideration for the technical scope.
Why
The different tiers create a smooth progression for the power growth. This allows the game’s difficulty to gradually increase, providing enough time to onboard enemies & mechanics. Additionally, this window of “calmness” allows for exploration, which funnels back into the power progression through points of interest.
Furthermore, the smooth power progression allows for a higher frequency of upgrades, pushing the power growth fantasy (core pillar) to the forefront.
The structure of the upgrade tree adds more upgrades of the chosen path into the pool, naturally supporting the player in achieving their desired build.
The Tier 2 upgrades expand on the power source of the tree (e.g., higher fire rate), but also provide a minor power increase with one of the trees that it synergizes into a Tier 4 upgrade. This is done to leash/foreshadow the combination & synergy.
Tier 3 or the “capstone” serves as a reward and the first magic moment related to power growth. It is meant to be similar to a signature move and expand on the player fantasy of power growth.
The chargeable weapon caters to challenge and strategy.
It rewards delaying your attack (through charging), which leaves the player rather vulnerable, and can clear paths through the hordes of enemies, requiring strategic deployment for survival.
Because of this, the playstyle is the most difficult and active.
The ramping weapon is flexible and versatile. It creates a middle ground between the two other weapons.
It is between the passive and very active gameplay. Even in terms of mastery, it is in between the two weapons, creating a nice blend and middle ground, covering a variety of players.
The conjured sword caters to destruction and excitement.
Due to its ability to destroy hostile projectiles, it is the easiest to use and allows for a more passive playstyle.
The objective was to have a weapon that contrasts with the chargeable weapon and thus caters to the opposite spectrum of the target audience.
Enemies & Combat Dynamics
Enemies
What
4 Enemies, with unique behavior, each prompting a different player response.
Warrior
The Warrior serves as a Fodder enemy.
It chases the player and performs an attack once close enough.
The Warrior serves as a Fodder enemy.
It chases the player and performs an attack once close enough.
The Assassin locks onto the player, charging a dash attack before executing it, ignoring all terrain.
The Assassin locks onto the player, charging a dash attack before executing it, ignoring all terrain.
The Archer shoots an arrow to a random side, perpendicular to its direction to the player.
How
I centered the design around the only defensive tool available to the player: movement.
A strong consideration with the enemy design was the assets available (our team had no artists), meaning that the design needed to fit within the constraints. For implementation, I created flowcharts outlining the logic, related feedback/anticipation, and changes in states (e.g., can be knocked back).
The Golem is a tank that charges a powerful Stomp Attack, dealing damage in the sourrounding area.
The Golem is a tank that charges a powerful Stomp Attack, dealing damage in the sourrounding area.
Assassin
Archer
Work in Progress
{Content Placeholder}
Golem
Work in Progress
{Content Placeholder}Why
I followed the design philosophy that enemies should prompt different player responses and ideally allow them to utilize aspects of their toolkit.
The Player has two persistent tools: Attacking & Moving.
The Archer shoots an arrow to a random side, perpendicular to its direction to the player.
Spawning System, Encounter & Difficulty
Spawning System
What
A Wave-based spawn manager, allowing for precise control, that enables onboarding and ensures the feeling of being swarmed.
How
Utilizing research as a foundation, I defined the capabilities and tweakable variables the design team would require. This was provided to the programmers for implementation.
Why
The Minimum Threshold of Enemies alive at once, together with the max enemy distance, allows the player to constantly feel swarmed by the enemies.
The one deals with the player killing too quickly, while the other deals with enemies being left behind, bringing them back to the action.
The other variables provided tuning capabilities for a hand-crafted experience, as we wanted to create a finite experience before allowing players to dive into the endless mode. This allowed for low-intensity waves when a new enemy is introduced to the game for onboarding purposes.
The ability to add a component at the end of a wave provided us with freedom moving forward, as the “Begin Play” event of a newly added component fires automatically, allowing for special moments such as the “Lichgate Event” (ending of finite experience).
Encounter & Difficulty
What
I designed and balanced a 7.5-minute combat encounter composed of 20 progressive waves, each crafted to introduce, escalate, and/or evolve both the gameplay challenge and sensation of being overwhelmed by a horde of enemies.
How
I developed a spreadsheet-based encounter simulation. It allowed me to maintain a holistic view of the encounter across all 20 segments by visualizing the time-dependent health scaling based on the variables inserted into the formula. Furthermore, I forged the experience and structure of the encounter by finetuning the wave duration, enemies spawned at the start of the wave, spawn rate, minimum enemy threshold & increased spawn rate, enemy assembly, and per enemy spawn chance and maximum number alive.
Why
The encounter aimed to gradually teach the player new enemy types without overwhelming them, then test their mastery by increasing the complexity and challenging combination of enemy types. Low-intensity introduction waves players with time for adaptation, while escalatory waves support skill growth. Varied combinations and strategic omission of enemy types prevent repetition, improve pacing, and sustain a fresh and dynamic combat experience across the encounter duration.
Intro waves: Introduces a new enemy in small numbers to onboard the new enemy & mechanics. This is a low-intensity wave, removing other special enemies from the spawning and reducing overall enemy numbers (e.g. Fodder).
Scaling Waves: Reintroduces Fodder in higher quantity and scales the numbers of the newly introduced enemy, allowing players to get used to the new enemy while increasing the challenge.
Mix Up: These waves evolve the combat dynamics by utilizing two special types of enemies along with the fodder.
Once all enemies are introduced, the maximum number alive of each non-fodder enemy type is progressively scaled up. This is occasionally broken by waves that remove one of the enemy types to use a higher number of another type, to change the flow and dynamics of the encounter over its duration.