top of page
Katharsi_Logo.png

Katharsi is a puzzle-adventure game where you delve into a cathedral and it's catacombs, solving puzzles in order to destroy the source of the plague.

ROLE

Technical Designer

GENRE: Puzzle-Adventure
TEAM SIZE: 15
PROJECT DURATION: 1 year
ENGINE: Unreal Engine 5
PLATFORM: Steam

My Role And Responsibilities.

My main role for this project was initially the Combat and 3Cs (Character, Camera, Controls) designer , however because our team shrunk in size we had to reduce scope and cut combat. Which left me with just the Character, Camera and Controls, as well as doing some general Systems Design work. Some of the combat systems will be talked about on this page as they were reworked into other systems, for their original design intention you can check out the Third Person Combat System page.
A list of the features I worked on include:  

  • Designed and implemented the third-person character.

  • Integrated custom camera collision and behavior.

  • Implemented motion matching system for the third-person character and implemented all character related animations.

  • Implemented character retargeter.

  • Designed some of the companion behaviors

  • Designed UI and Menus.

  • implemented various cut-scenes and game trailer

Designing and implementing a third person character

  • Implemented character movement and strafing.

    • Character can move with and without control rotation depending on whether automatic targeting is triggered or an aiming input is pressed. After combat was cut this is only used for the aiming input. 

​

​

​

​

​

​

​

​

​

​

  • Implemented an auto jump and manual jump.

    • Either can be toggled through a boolean, the auto jump traces for ledges and jumps if the player has reached a minimum velocity. Initially the game had an auto jump over a manual one because it freed up controls for the combat inputs like the roll. With combat cut I decided to make it manual as this would allow the level designers to add some light platforming elements to break up the puzzle segments. 

​​

​

​

​

​

​

​

​

​

​

  • Implemented player dodge.

    • Omnidirectional roll that is triggered by a single button press. Has I-frame functionality. Cut together with other combat functionalities. 

​

​

​

​

​

​

​

​

​

​

​​

  • Dynamic rotation rates.

    • rotation rate changes depending on player actions both for better visuals as well as gameplay. For example: when rolling the rotation rate is instant, and when walking the rotation rate is slow. â€‹â€‹

​

​

  • Implemented third person action controls.
    • Designed the third person character control scheme. 

​

​

​

KatharsiControls.png

Integrated custom camera collision and behaviour

  • implemented custom camera collision.

    • Allows for smoother collision events by lerping towards the nearest "safe" position, instead of instantly snapping towards it. This was necessary because our environments had a lot of tight corners, pillars and other objects that could interact with the camera, with a snapping camera this did not feel good to play and could even be nauseating for some players.

​

​

​

​

​

​

​

​

​

​

  • implemented automatic targeting / aim assist.

    • Initially used to automatically lock onto enemies for combat, reworked to use as an aim assist when redirecting light behind blind corners. While the player is aiming, Traces are drawn where the player is looking for Mirrors and buttons in range, will interpolate the camera control rotation towards the aim assist point on these mirrors while the trace is in range. This made the blind corner mirrors less frustrating to use. 

​

​

​

​

​

​

​

​

​

​

  • implemented aiming system

    • Used to redirect light or aim the companion shot, lowering the sensitivity for more accurate aiming. Can also be used to take a slightly better look at the environment as it also has a smaller dead-zone.

​

​

​

​

​

​

​

​​

​

​

  • ​implemented camera dead-zone and camera zooming on exceeding dead-zone.

    • Implemented a camera dead-zone to prevent the camera from getting too close to the ground or player. When exceeding this dead-zone but the input is still held, zoom in or out a bit to make the stop less harsh.

​

​

​

​

​

​

​

​

​

​

Set up Motion Matching system

  • Set up Motion Matching system using Anim Sample Pack animations.

    • There was no animator or rigger in our team, this meant that the system design and animation packs would have to do the heavy lifting. For the smoothest locomotion possible I opted to use a motion matching system. It is a Slightly Simplified version of the one provided in Epic Games UE Anim Sample Pack, as this is free and has a lot of documentation available. It utilizes a Chooser with 4 nested choosers which pick from 19 Pose Search Databases. All locomotion animations use this system.

CHTImg.png

Implemented Player Animations and Retargeting

​

  • implemented Anim Notify System for all player actions. including the possibility for animation cancelling. 

    • Uses an animation notify system for every player action that utilizes an animation montage, these notifies enable or disable actions for their duration to prevent animation cancelling, or allow for intentional animation cancelling. It used to also provide I-frames and notified active attack animation frames for hitboxes.

​

​

​

​

​

​

​

​

​

​

​

​​​​

  • Implemented real time Character retargeting.

    • Because the team didn't have a rigger the character artist sculpted the player character around the default unreal engine mannequin rig. This allowed me to use all of the animation sample pack animations and some Mixamo animations like the animation used to send out your companion. I used a real time character retargeting system utilizing an additional Animation Blueprint, as retargeting the individual animations caused the events within them needed for the motion matching and audio to break​​The retarget pose from mesh node gets the current pose from the default manny mesh utilizing an automatic IK retargeter, the default mannequin inside the player blueprint uses the motion matching system. The system then applies that pose to the actual characters mesh.

 

​

​

 

 

 

 

 

​

​

​

  • Implemented bone adjustments

    • Because an automatic IK retargeter was used there were some minor issues with the characters mesh, but because we didn't have a rigger I decided that it would be better to resolve this issues through the animation blueprint rather than doing the retargeting by hand. The two main issues with the mesh were the spine bones being a bit off, causing the character to slouch. And the arms not bending properly. The slouch occured while running, the arm issues occurred in the idle and walking state of the character. In the animation blueprint the characters current state is gotten and based on that the problematic bones are interpolated to their correct position. 

​​

​

​

​

​

​

​

​

​

​

​​

​

​

​

​​

AnimMontageStates.png
retargetingimg2.png
ABPRetargeter.png

Designed some of the companion behaviours

  • Implement improved companion "shoot".

    • Initially the shoot worked by simply shooting out the companion in a straight line, and going towards objects through a lock on system, as in a reference like Ocarina of Time. However, players didn't like this lack of agency, so I pivoted to the manual aiming system. In order to do this, I reworked the companions logic to utilize two line traces, one from the camera and one from the companion to find the point where the companion should move to, similar to a bullet trace in first or third person games that start from the gun and go to the center of the screen. 

​

​

​

​

​

​

​

​

​

​

​

  • Designed Companion light redirection. 

    • In early versions of the game, the character itself redirected the lightbeams, however we received player feedback that this looked a bit weird as well as that the companion felt disconnected / useless. In order to kill two birds with one orb I designed a way for the companion to redirect the light by dynamically moving into a lightbeam while aiming next to one, and using the shoot trace to find the lightbeams new rotation. One of our programmers then implemented this system properly. 

​

​

​

​

​

​

​

​

 

Designed and scripted UI

  • Designed player HUD.

    • Added a reticle for aiming that changes opacity depending on the shoot trace resulting in a hit or not. This helps players to gauge whether or not they can hit their target with the companion. 
      The HUD also has a vignette that appears and disappears depending on the players health, as fall damage was added to avoid players from dropping down the level and skipping narrative beats

​

​​

​​

​

​

​

​

​

​

​

​

  • ​Designed menu's 

    • Before the demo release the menu's still looked very bare-bones, using just the default button textures in Unreal Widgets, having no step up for the variable sliders, and having moving text depending on length. Since the team didn't have a dedicated UI designer I decided to work on sprucing up the menu's a bit. I did this together with the Visual Art Lead, basing the style on the reference game A Plague Tale: Requiem. I created the background room for the main menu, animated the credits menu and set up the basic logic for the button hovers and settings menu, and made sure to set-up proper 0,X slider stepping and locking all the text in a central position. A programmer later revisited and improved upon my code, but the visuals stayed pretty much the same until the end of the project.

​

​

​

​

​

​

​

​

​

​

Created Cut-Scenes and Trailer

  • Created cutscenes

    • In order to assist narrative beats or transition between segments of the level several cut-scenes needed to be made.

    • For the stair transition: The way the level is structured, with the player starting at the Top, going to the very bottom and then working their way back up requires the player to be teleported down, in order to make this transition smooth the stair cut-scene was introduced.

    • For the Central room cut-scene: Aside from showing the awesome art and creating an initial wow moment, it provides a narrative beat as well as giving the player some sense of what is to come.

    • For the rotating room: I specifically scripted the rotating room logic, not the actual camera movements. We don't want the player to move inside the cube while it is rotating as this could result in the player clipping out of the map, but locking the players movement doesn't feel good. This is why the cut-scenes were introduced.

    • I also scripted the logic to block player input aside from the skip button and hiding the HUD and the skipping logic itself for all cut-scenes. 

​

​

​

​

​

​

​

​

​

​

​

​

​

​

  • Created the Demo and Full Release trailers

    • In order to both market the game and finish the steam page required asset list trailers needed to be made for both the demo release and the full release, I worked on these since I had some prior video editing experience. â€‹

​

​

​

​

​

​

​

​​

​

​

​

​

​

​

​

​

​

​

Demo Trailer

Release Trailer

bottom of page