OLD THIESS: THE WEREWOLF'S TRIAL
For our final project for NAD's Narrative Game Design D.E.S.S., we designed a game inspired by the transcription of a werewolf's trial from 17th century Livonia. A 2D platformer focused on combat and exploration with an emphasis on the narrative, Old Thiess explores the roots of the myth of the werewolf, and the relationship with one's inner beast.
What I did in this project:
Designed a Metroidvania-style level with interconnected maps containing enemies, resources, NPCs and a boss.
Designed and programmed:
Game architecture and transitions.
Player character's movements and mechanics.
Combat system and enemy behavior.
Dialogue, popup and tutorial systems.
Progression system.
Collaborated to craft the game's lore, characters and story, and wrote the dialogue for the 4 possible endings.
The game is still in production and will be released in April/May 2025.
MADE WITH UNITY
Level Design - Programming - Technical Design
The game's narrative is tied to Old Thiess' trial, taking place in 1691. As villagers are called to the bar to testify, they recount events that led them to to ask for the old man's help. The player then controls Thiess in his werewolf form in flashbacks, and explores 3 levels set in Dante's Inferno.
The player's goals are to:
Gather stolen grain to bring back to the village.
Complete a quest to help the villager.
Beat a boss to acquire a piece of the contract secretly binding Bishop Nickolaïs to the Devil.
Depending on the success of the grain and quest objectives, the villagers' support either increases or decreases, leading to 3 different endings.
The success of the boss objective has no impact on the villagers' support, but if the player manages to beat all 3 bosses, they automatically unlock a fourth secret ending.
Concept
LEVEL DESIGN
Design a Metroidvania-style level with 10-15 interconnected rooms.
Design the layout of each room to reflect the difficulty increase.
Place obstacles and enemies in each room.
Include a safe room for Mélusine's sanctuary near the center of the level for easier access.
Include a room for the quest demon Aeshma.
Include a room for the boss.
Use environmental art made by our artists and lighting to mark the distinction between different parts of the level.
Place in the level environmental narration objects that can be examined by the player to get lore.
Tasks and constraints
Explore verticality in the global layout of the level as well as the individual rooms.
Create an interesting and non-linear level with backtracking and shortcuts that allowed for organic exploration.
Create rooms with distinctive layouts, obstacles, art and lighting, to make it easier for the player to orient themselves.
Keep truthful proportions and distances between the rooms and their connections, to make it easier for the player to use their spatial awareness.
My goals
The level I designed represents the Fifth Circle of Dante's Inferno, a swamp where the wrathful fight each other for eternity. It is the second of 3 levels, so the mechanics and systems have already been introduced, and this level serves as a ramp-up in difficulty and intensity to further test the player's skills.
The demon Aeshma: A mini-boss hiding in the eastmost section of the level. Beating it completes the villager's quest for this act.
Concept
Sorcerer Illmedous: The boss, he is a powerful sorcerer who's established his lair in the poison-infested caverns in the deepest part of the level. Beating him grants the player a part of the satanic contract.
Mélusine: An NPC ally of Thiess, her sanctuary is nestled in the caverns of the Furies' Den, at the center of the level. The player must pass through the Furies' Den in order to reach the demon, as well as the boss, thus giving the opportunity to gather important information about the level's objectives.
Points of interest
I designed the level to be more vertical, thus giving a better impression of going deeper in Hell, and offering more platforming challenge. It comprises 15 rooms, and 7 general areas:
Caves of Rage: A small network of caves overlooking the swamp. It serves as the level's easier first zone.
Stygian Swamp: The swamp itself. A large open area whose floor is covered in poisonous water, making it dangerous to navigate.
Festering Ash: A grotesquely huge tree that grew from the swamp into a long vertical cavern. The Heart of Hatred used to be accessible from its roots, but it was recently blocked off by Mélusine.
Furies' Den: Mélusine has established her sanctuary here. Again, her proximity protects Thiess, to whom she can also give useful information.
Shrine of Satan: Caverns infested by twisted and thorny plants. A demon has set its lair there, and commands the imps of this region.
Maze of Madness: A network a dark, twisty and cramped tunnels that is a veritable Chort nest. Going through it is now the only way to reach the final zone, Heart of Hatred.
Heart of Hatred: Large caverns located at the bottom of the level, into which rivers of poison water flow. The Sorcerer Illmedous lurks down there.
Layout
In-game map of level 2
All level 2 scenes in Unity
2 initial paths from the start.
Simple layout with easy platforming.
Flow and navigation
If the player goes at the bottom of Festering Ash, they discover the way is blocked off by a detachable block that can be broken off and lowered from the other side.
Vertical layout with open spaces and semi-solid platforms.
The layout naturally guides the player back towards the Stygian Swamp and Mélusine's sanctuary in the Furies' Den, where they can gather information from Mélusine.
Semi-solid platforms over poison water, lots of geysers.
Another detachable block serving as a shortcut that can be opened from the demon's room.
(yes that's a rendering bug that I haven't fixed yet...)
Climbing to the top of the Shrine of Satan to beat the demon Aeshma, and then opening a shortcut back to the Stygian Swamp.
Lots of spikes, a lot of platforming without semi-solid platforms.
Going through the Maze of Madness and getting back to Festering Ash to lower the detachable block and open access to the Heart of Hatred where lurks the boss, Illmedous.
Dark and cramped, full of chorts (satyrs).
Scale
One of my biggest challenges designing this level was coming up with a level layout that was not too big for our game experience, yet still interesting.
In my early designs, I started with more rooms than necessary to get a global layout I was satisfied with, and then proceeded to reduce the number of rooms by removing anything that did not serve a specific purpose. I also reduced the size of several rooms that were unnecessarily large, making it hard for the player to navigate and to orient themselves.
Playtesting greatly helped in figuring out what parts of the level were confusing or uninteresting.
Verticality
Since our playable character was a humanoid higher than its width and did not have a ridiculously high jump, it was a challenge to create maps where, for instance, they could go underneath a stretch of ground, as well as jump over it. It was pretty limiting for truly vertical maps and forced me to create bulky, inelegant design. We consulted as the design team and decided to introduce semi-solid platforms, which allowed to jump from beneath and land on top of them. This helped a lot to create more interesting vertical room layouts with more open spaces that allowed for more freedom of movement going up or down.
I did not always want to use the semi-solid platforms in my layouts, so verticality also brought situations where I designed needlessly tricky platforming. I had to fine-tune those layouts if I wanted to keep the original intention, and so I abundantly tested and tweaked them, and again got useful feedback from playtesting.
Verticality also introduced tons of possibility for blind jumps, where the player could jump down without seeing what was beyond the camera's field of view. I assumed the inevitability for blind jumps and thus always provided a way down with platforms and ground (except for the boss room where the player is meant to fall down into it blindly). I tried to avoid placing obstacles in spots where the player could land following a blind jump.
For example, in the Stygian Swamp's big room, the floor is covered in poison water. I managed to reduce the probability of a blind jump into that water, while keeping its danger present, by adding platforms with different heights along its length. The player is thus more likely to fall onto one of those platforms, but to traverse the room horizontally, they still need to jump from one platform to the next, sometimes from a lower point.
Challenges and lessons learned
Comparison of level 2 feedback from our final 2 playtests, done within a month of each other. It shows significant improvement on the target difficulty, scale, and the fun of exploring.
PROGRAMMING / TECHNICAL DESIGN
Code all the architecture and systems to make them functional, solid, scalable and (almost) bug-free.
Design the technical details of all player mechanics, enemy behavior and additional systems such as dialogue, popups and tutorial.
Optimize for performance and maintainability.
Provide a smooth experience to favorize immersion.
Simplify usage of the game engine for other team members (especially the level designers).
Simplify version control usage for other team members and avoid merge conflicts.
Tasks and constraints
Experiment with platforming mechanics to create an experience that felt good to play.
Experiment with combat mechanics to make for satisfying combat
I implemented several additional mechanics such as a blocking/parrying system, a slide-attack and a backstab. However, in order to simplify our game design for this short game experience, and since we did not have enough art resources, these mechanics did not make it into the final game.
Experiment with enemy AI and complex behavior.
My goals
Singleton pattern with "manager" scripts for each element.
Scene "Boot" containing all persistent manager game objects
Game Manager
Loading Manager
Transition Manager
Spawner
Time Manager
Progression Manager
Cutscene Manager
Input Manager
Audio Manager
UI Manager
Camera
Loading scenes asynchronously to keep a more modular control of what's loaded, and optimize performance during scene transitions and load time
Architecture and loading/transition system
Jump higher when holding button + high gravity to allow for better control.
Complete control over horizontal movement (no momentum) fits better with our level design.
Velocity cap when falling to give more slightly more reaction time in vertical maps.
"Regrab" mechanic inspired from Super Mario World: the character falls slightly slower when holding down the jump button, to allow for even more control.
Player mechanics - Technical Details
Slide down walls when next to them to allow a slower fall and better control over wall jumps.
Horizontal momentum prevents going back to the same wall at the same height or higher.
Can activate wall jump from a short distance from the wall (inverse coyote).
Can be used to slide underneath walls in one-tile gaps.
Will not exit sliding state as long as there is a wall overhead.
Several regular attacks executed in succession add up to a combo. The third one inflicts slightly higher damage.
More powerful attack with a cooldown.
When used in midair, Thiess dashes forward and downward and tears through enemies.
When used on the ground Thiess dashes forward and tears through enemies.
When low on health the player can choose to sacrifice some grain required to complete one of the level's objectives in order to eat it and recover some health.
Eating takes a short time and shows feedback of grain being lost.
Thiess can meditate to gradually lower his rage.
1 second to get down before starting the meditation, and 1 second to get up. This pushes the player to find a safe spot to meditate.
A small amount of rage is lost each second while meditating.
The player can open the current level's Map to better orient themselves and find the different points of interest.
The rooms are not revealed until discovered.
The points of interest are not revealed until discovered, or hinted at by Mélusine.
Goes down over time, increases when enemies are killed.
In Mélusine's room and the first tutorial room, the rage moves towards its center, towards balance.
Meditate to gradually reduce rage.
Jump
Wall Jump
Slide
Attack
Can attack upward and downward.
When holding down the attack button, Thiess charges up and executes a more powerful charged attack.
Dash Attack
Consume Grain
Meditate
Map and Quest Panel
The player can open the Quest Panel to see their progress on the 3 different objectives. They can keep playing while leaving it in the HUD, or leave it closed for a cleaner HUD.
Rage Bar
The character "vaults" over top corners to avoid frustrating near-complete jumps and wall jumps.
Can be used to dodge enemy attacks
Coyote time and input buffering to allow for slightly more imprecise inputs and avoid unfair situations.
When attacking downward an enemy while in midair, Thiess bounces up.
If the rage reaches its maximum, Thiess goes in an uncontrollable rage state.
Thiess loses a small amount of grains when falling into that state.
Thiess gradually loses health.
The camera zooms closer to Thiess, decreasing visibility.
Thiess inflicts slightly more damage.
Several feedback elements to emphasize the state.
If the rage reaches its minimum, Thiess turns back to his human form and is kicked out from Hell.
Player behavior split into several classes for modularity:
Player Controller (main class)
Wall Jump Manager
Slide Manager
Attack Manager
Dash Attack Manager
Player Health
Player Rage
Abstraction of enemy classes for repeated behavior.
Player actions and enemy behavior handled by state machines.
Playable character and enemies
GitHub
Checkout system on our Discord server
Send a message with the scene, prefab or folder structure to checkout in the channel, with a X reaction to indicate it's checked out.
When done with the files/folders, change the X for a checkmark to indicate it's ready for a merge.
When a merge is done, I delete messages with a checkmark to indicate the files/folders are free.
Clear branch hierarchy
Version control
Scaling
We started developing the game using an old Metroidvania prototype I had realized, which I modified to better suit our needs. During development, the scope changed several times. Sometimes we reduced it to eliminate additional mechanics or features that were not essential to our core experience, thus allowing ourselves to spend more time on polishing what actually was. Other times, we increased the scope, adding small mechanics or features that we realized (especially after playtests) would actually help our players a lot to better understand and play our game. All these scope changes pushed me to make implementation easier by making the code more flexible, modular and abstract (see Playable character and enemies).
Knowledge transmission and troubleshooting
Not everyone on the team had the same level of experience with Unity and GitHub, and being the one with the most technical expertise in the team, I took the time to teach other team members the basic functionalities. I obviously did not have the time to teach them everything I knew, so I provided several resources and tutorials for them to learn on their own.
For GitHub, I managed the repository, pull requests and merges. Early on, we had several merge conflicts due to misunderstandings or miscommunications, so I brought to the team a simple system to allow them to checkout files and folders in the project in a channel on Discord.
I also had to take more time than expected to troubleshoot technical problems that my team members had in Unity. This experience taught me to plan for that time in the future when I serve as a technical resource for the team.
Enemy AI
Developing good and not-too-janky AI took much more time than I had expected. Due to my other numerous tasks and the limited time at my disposition, I eventually realized I couldn't implement all I had initially planned, and had to focus on making the enemies' overall behavior feel real and motivated, as well as polishing and fixing bugs as much as I could to avoid breaking immersion.
Being the only programmer on the team
...was certainly a challenge. I ended up in this position due to several scope changes and timeline extensions during development, which was initially supposed to last 3 months. As such the tasks I accomplished were feasible, but in the long run, with other projects and a job intertwined with the development of Old Thiess, we would have been better off bringing other programmers on board. This project allowed me to get a better sense of how much I could do within a certain timeframe.
Challenges and lessons learned