Lichgate

Lichgate is a survivor, rogue-like,
twin-stick shooter developed with the design objective of providing a short but fun experience that highlights
the capabilities of Coral Engine, an engine made by our team.

2024
Q2 & Q3

8 Week Duration

Coral Engine

Team Project

?

Windows

Single Player

Key Responsibilities:

Design Weapons, Perks, and Enemies
Design Progressive Scaling & Balance
Design & Execute Game Feel
Design Core Loop & Systems
Co-Design Movement / Controls / Camera
Maintain a holistic view of the game & development

Role & Tasks

For this project, my main role was to design gameplay & systems through research, feature breakdowns, playtesting, and iterating.

In addition, I had to proactively identify must-have engine features while maintaining the scope and prevent bottlenecks by prioritizing Engine Features & Systems throughout development.

Pillars

Power Growth

Strong Game Feel

Each event or action should feel right to the player and convey necessary information to the player such as intentions, effect & impact.

Replayability

Gameplay and Systems should encourage players to play multiple runs regardless of finishing a run during their first contact with the game.

These Pillars were used to help drive design decisions, help achieve the intended player experience, and ensure coherence throughout the game’s design.

Camera & Controls

Initial Prototype

I designed the 4 enemies in our game, for which I provided breakdowns to our programmers to ensure the intended behavior and functionality were communicated effectively for implementation.

The diagram to the right is an example of a breakdown for programmers.

The systems were implementation by our programmer, after requesting specific functionalities and providing them with examples or breakdowns if neccessary.

When we added a manual “reload” to the game, the
Left Trigger became the appointed button for this action.
The intention was to avoid forcing players to change their grip or move a finger to perform actions, while still feeling intuitive, which was later validated through playtests.

I used the research conducted on Camera, Controls, and Character to adjust the camera to resemble reference games and iterated on this based on playtests & design intentions.

Final Version

The final camera is more angled, there is a 45° yaw offset between the camera and the world, the distance has been adjusted.
Additionally, a slight camera lag and offset toward the aim direction were added. Last but not least an aim adjustment system was added.

I increased the angle of the camera to help with the readability of the game as well as highlight the assets better. However, an angled camera makes aiming a lot harder which is why I requested the addition of an aim adjustment system (Screen Space Aiming), which our programmers implemented.

The distance adjustments were to ensure that all relevant information, such as approaching enemies and enemy actions, were conveyed early enough to the player.

After player feedback, I decided to add the camera lag and offset towards the aiming direction to create a more dynamic feel, as well as allowing the player to see slightly more in the direction of their actions.

The rotation difference between world and camera was done to avoid tiling patterns too be apparent, while also helping highlight the assets better.

The player should frequently feel like they are becoming stronger throughout a gameplay session (a single run).

Enemies

The Process

Our initial prototype started with a player centric but static top-down perspective and typical fps controls
(L-stick movement, R-Stick aiming, R-trigger shooting).

Enemy Roster

Enemies have 3 main attributes that define them: Their Health, Movement Speed, and Attack behavior.
Each enemy type has a unique Attack behavior with different intentions.
For this section, I will focus on Enemy Attack Behavior and design intent, as I will address movement speed and health in the Balancing section below.

The diagrams below are simplified versions, to help convey functionality from a design perspective!

Warrior

The Warrior is a low priority, melee enemy with low health and slow movement, intended as cannon fodder.

They approach the player and attack once in melee range.

During the early phases of the game, the simplicity and pacing of this enemy intend to allow novice players to get familiar with mechanics while allowing other players to explore the map for points of interest to speed up their power growth.

During later phases of the game, the simplicity of this enemy is crucial to avoid cognitive overload as hundreds of them are in play. Additionally, their purpose shifts as they swarm the player, forcing players to clear paths through them and avoid walking into them.

The Assassin’s attack is designed to force the player to avoid it by moving in any direction other than a straight line to or away from the Assassin.

As the dash ignores terrain collisions, it poses a larger threat to the player, especially near terrain, that other enemy types need to navigate around. As the level is randomly generated this becomes even more relevant.

Assassin

The Assassin is a medium-high priority, enemy with low health and fast movement.

They approach the player and charge their attack from afar before dashing forward.

Archers are intended to create more variety in the combat dynamics.
Due to the randomized offset-direction perpendicular to the line between the Archer and Player, their attacks serve as a trap and only as a direct threat, when moved into.

The element of randomness in tandem with the offset, forces the player to reevaluate their path when navigating around enemies, attacks, and obstacles.

Archers effectively help diversify the solutions required to avoid other enemies and their attacks.

Archer

The Archer is a medium priority, ranged enemy with low health and fast movement.

They approach the player and shoot a slow projectile at an offset from the player.