Description

8 Weeks, 50%
Custom Engine & Unity

In Damsel you play as a Princess tired of failed rescue attempts.

Take up armaments and fight your way out of the evil Necromancer's castle! Collect keys and Gems while solving the ancient Mouse King's mural.

The game features a linear story across 5 distinct areas, with a final Boss Fight to test your mastery.

- Development -

Short but Gold
Damsel was one of the shorter Projects we had, especially accounting for the fact that we also had to make a custom engine for it. The Project was however one of my favourites and with the given time frame I reckon we produced a complete but compact experience.

It was also one of the few Projects where I never felt any stress or pressure. Everything just seemed to go forth so effortlessly and the Team behind it was really fun and lighthearted.

The Game remains on Itch.io, where it's publicly available for anyone to test if they wish.

Pipeline
During the project I was in charge of the level exportation from Unity to our Custom Engine. This included:
- Objects, Textures & Animations
- Colliders & Triggers

- Objects with Functions

- Entities

- Room Data

In Unity we wrote all objects in the scene to a .json file, going through multiple error checks in-case someone had done something faulty. Then we read the file in our Custom Engine and recreated the scenes, with added gameplay functionality.

(Click to Enhance)

- My Contribution -

Room System

One of the things I've done that I'm really proud of was the Room System in Damsel.

(Click to Enhance)

By selecting the bounds, the Level Designers could add Room Data to their Scenes, which was then exported in the Level files. To my knowledge our LDs loved using this Tool, as it gave them easy representation with debug lines on how their rooms would work inside of our engine.

These Rooms handled Combat Encounters, Spawn data, Camera bounds, and much more.

Here we can see very early development footage from our Engine, where rooms exported from Unity has clamped our Camera's bounds. In Room #1 we have a vertical area which the camera can slide across, while in the smaller Room #2 the Camera is locked to the middle. In the final implementation the Camera was of course smoothed to travel between these bounds instead of instantly snapping.

Camera & Cinematic System

As mentioned in the Room Section, the Camera features clamping. One of the other major things it features is the ability to take control of it and the player execute cinematics. This was done for the dialogue in the boss fight where the Camera pans over and the Player is manually controlled by Code, as well as during the fight itself where the camera is slightly offset to follow the Boss, essentially always giving the Player the direction towards him. This was seen as a necessary implementation due to one of the Boss' core mechanics; teleportation.

Render Manager

In the beginning of the project I was responsible for creating a Render Manager, which simply compiled all of our render commands inside a singular structure, verified them and then executed them.

This also included things such as Ambient + Directional Lighting and Shadows, which were made by TGA and modified by me, I then distributed my solution to a few other Groups and their Projects. Ultimately the lighting was further modified by Jakob Persson.

Boss Fight

The Boss features 3 phases and 5 different attacks with multiple variations, as well as having the option to summon clones of himself which mirrors some of his attacks. It was all built in a State Machine framework which made timings and animation handling much easier.

I consider myself very happy with how this boss turned out, after spending my Graduation Thesis at LBS on Boss Design I was really excited to be able to put it to the test in a team environment. It received some critique that it was too hard, but after tuning it down by introducing more moments of vulnerability I believe I have landed on a good balance of difficult but not unfair.

(With Sound)

The boss functions by having a couple of points where it can teleport inbetween, where it will cache where it's been lately and try to avoid those, while still pursuing the Player. The same goes for attacks where it keeps a stack of which states it has been in lately and will try to avoid repetition, but force attacks which can be reflected back towards himself at a set interval so that the fight cannot be potentially infinite.

When it comes to the Clone it has a separate timer for when it can spawn. Some of the boss attacks will also try to override this timer if it's below a certain value, as to provide more cinematic moments (such as them co-ordinating attacks from different directions).