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.
Conjures a sword that deals damage in a frontal cleave. Reloading performs a special “Bladestorm” attack.
Shoots damaging projectiles.
Continuous fire ramps up the attack speed and decays once
fire ceases.
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.
Some document
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.
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.
I produced the initial concept for a Twin Stick Shooter game, that merges Super Crate Box’s randomized weapons and arcade-like structure with the continuous action and health drain from Post Void, in a hectic and bite-sized format.
Weapons
What
3 Weapons, targeting different playstyles and player groups.
Gif of uninterrupted gameplay
The player constantly loses health. This is caused and scaled by a resource called “Exorcism”. This serves as a difficulty scaler, which also influences enemy spawning.
Killing enemies restores health but consumes limited ammo.
Kills in rapid succession reduce Exorcism slightly.
Weapon Crates provide a random weapon with full ammo while restoring health and increasing Exorcism.
Zubek / Onion / Types of Fun
*Chaos Crystals is the name given to the Weapon Crates.
{Talk about strongly intertwined loop?}
Early Design Breakdowns
Do the Work
The player performs 3 main Verbs: Shoot, Move, Dash.
Actions are kept simple to allow players to focus on positioning and moment-to-moment decision-making.
How
I started with research, followed by creating a prototype in machination, breaking down the concept, and validating the loop for a rapid prototype implementation.
Gif of Early prototype
Early In-Engine Prototype
Machination has been a key tool to support the development of the core loop. It enabled me to visualize issues and connections within the tightly intertwined resource loop before the in-engine implementation, making iteration more nimble and time-effective.
It also served as a platform to test out the balancing and tuning of the systems, thanks to a clear visualization of the flow of resources.
Replace “Chaos Crystals” with “Weapon Crate”
Why
Player Experience
Hectic:
The player should constantly be on their toes, and be required to make split-second decisions.
Bite-Sized:
A round should not last more than 3 minutes, while still providing a meaningful experience to the player.
Kinds of Fun
Following the “8 Kinds of Fun,” these elements facilitated enjoyment:
- Challenge
- Sensation
- Fellowship
I used this to help understand the player’s motivation and narrow down the audience which provides a clearer picture of how “fun” is going to be delivered.
This helps as an additional guide for design decisions and prioritization.
The ever-depleting health system and all the interactions around it build a sense of insecurity and short-term objectives that create hectic game states where quick thinking is the only tool for a successful outcome.
Hectic Gameplay Gif
The difficulty scaling and progression are reminiscent of the balancing of classic arcade games, keeping the interaction loops concise and delivering the experience in a bite-sized format where the mechanics shine.
Hectic Gameplay Gif
Section Title (H1)
What/Why/How (Sub Title) (H2)
Standard Text (P2)
Tiny Title (H4)
Section Title (H1)
What/Why/How (Sub Title) (H2)
Standard Text (P2)