THE TAKER

Stolen hearts tend to leave a trail of pain.

One day Devan Durand wakes up in a world he does not know. He remembers almost nothing. His Memories come alive as relics of his life emerge, setting him off on a mission to protect them from waves of enemies, while trying to find out why he woke up there. These relics lend him the power to fight off the waves with special abilities, all only avaviable in range of the item.

Play on Itch.io!

Engine: Unity

Platform: PC (Keyboard & Gamepad)

Extent: Vertical Slice, 16 weeks

Year of launch: 2024

Average session: ~ 35 mins

Genre: Action, Adventure, Story, Fighting

Language: C#

Short Summary

THE TAKER

Combat game with focus on narrative
Attacks only work inside radius of objects
Three different enemy types, one introduced each round
Three different abilities, one each round

My Responsibilites

Sole Programmer
Game Design
Project Management
Sound Design
User Experience
Quality Assurance
Technical Art

Learnings Programming

Advanced Unity Skills
Advanced C# Programming
Main Takeaways: Interfaces, Serialized Lists, CSV-Implementation,
Debugging with Gizmos, NavMesh, Player Prefs, Scriptable Objects,
Timelines, Camera Movement, 3D Vector-Math

Learnings Game Design

Combat Design
Combining narrative and gameplay
Difficulty Design

Content

Game Design

In THE TAKER you step into the role of Devan Durand, a techno artist that has to deal with his ex-best friends sickness. He wakes up in a strange place that is later revealed to be his subconscious. He does not remember much and has to entangle how his friend got sick and what he had to do with it. You play as him trying to literally fight his fears, by using multiple abilities granted to him by different items from his past.

The Combat and the enemies played a big role in the Game Design process. For a long time we only worked on trying to make the combat feel right and fine-tuned areas such as the camera, the character controller, the hp and damage values, the abilities or the enemy behaviour and analysed our changes in playtests. We put high priority on these playtests and continually organized groups of testers to come play.

We also continuously presented the game, not only in front of our class, but also in seperate coaching sessions with our professors and another team. This helped us gain valuable insights and kept us on track.

To ensure a high level of accessibility, I added multiple settings, such as brightness or sensitivity, along with the option to play with either a controller or keyboard.

Our organization was mainly done in Miro and Trello. There we kept track of our tasks and timelines. We tried to make sure that all of our tasks were S.M.A.R.T.-Tasks, that way all of our tasks were measurable and time-bound.

Abilities

THE TAKER centers around it's combat and the abilities each unlocked after a new wave was completed. Overall there are three playthroughs of the level, so three abilities added. First players learn how to attack. They can only attack if the item they carry is dropped and they are within it's action radius. There is a fast attack that deals ranged damage and a slower, but stronger attack.

In the second wave players unlock an energy ressource that grants them new skills. First is the nova ability, that launches a devastating implosion at the items position. This costs 50% of the maximum energy amount.

In the last wave players unlock the shield ability that costs a set amount of energy per second.

Ranged Melee Attack

Nova Ability

Shield Ability

Enemy Types

In the first wave we mainly encounter the swarm enemy. They appear in big groups and follow the player relentlessly. If they are close enough they charge their attack.

As the first waves boss we introduce the ranged enemy. They also start charging once the player comes close and fire one of three projectile attack patterns. The first is a simple projectile, second is a shotgun-like blast of three projectiles next to each other and lastly they can shoot three projectiles one after the other in a row, this is probably the most dangerous one.

In the third wave players are surprised with the boss of the game "Guilt". They serve as a giant roadblock that will first launch two melee attack with a long range that charge quite long. After these two attacks he will launch his devastating main attack that reflects the players nova very much and deals high damage. Then the cycle repeats.

Swarm Enemy - Denial

Ranged Enemy - Anger

Boss - Guilt

Technical Aspects

I will now highlight the most interesting technical aspects of THE TAKER.

Prototype Stages

Stage 1: Ideation

Stage 2: Pre-Production

Stage 3: Interim

Stage 4: Production Start

My main focus was to trying create a more scalable code structure and ensuring a high level of cleanliness inside of the project. I experimented with different techniques to fully support the workflow of our tech artists, modelers, sound designers, and storywriters.

A good example of this is the Subtitle System, which relied on Scriptable Objects. Here, storywriters could input dialogues into a CSV file, where each dialogue line was then imported into Unity. This system allowed for customization and simplicity, enabling the triggering of sounds or events in each line as needed.

Throughout the project, we stayed committed to this ethos, which made us achieve our highly ambitious goals within the set time frame. Our production process went smoothly as a result.

Combat

When we started prototyping the Combat it got very clear to us that the players needed some assistance in hitting the enemies, since without it was very frustrating.

So I implemented a rotational adjustment. This was very well received, since the players did not notice it and had signifi-cantly more fun.

Audio Manager

To make the sound management simpler, I implemented a singleton "AudioManager" that was responsible for handling the sounds. It was able to carry out functions such as fading in/out or choosing random sound clips. The advantages of using a singleton in this case, were that it was possible to call sounds from any script, by passing a scriptable object "AudioContainer". They contained all of the information on each sound, such volume, delay, it being paused in the menu or if it was 2D or 3D.

The VFX-System was based on the same concept of scriptable objects and a singleton. Since I didn't reload the scene on player death, but reset everything by code, it made keeping track of all active VFX and deleting them all at once much easier.

Subtitles

Also based on scriptable objects, the subtitle system was based on a CSV-File, that stored the information for each subtitle line. When clicking the button "GenerateCSVText" it imported them into the scriptable objects, read to use.

The parameters include lifetime, content or person speaking. Inside of Unity you could then also add Sound Containers to each subtitle line or trigger custom events, which could then start tracking shots, UI, rewards or else.

This imported Subtitle was then part of a sequence, which could be played from anywhere by calling a singleton and by using enumerators no reference was needed. In the overloads it was also possible to define if the subtitle sequence was skippable or was to be displayed as a blackscreen. It was then added to the queue, sorted by priority or displayed directly.

Camera

A lot of my time went into the camera. It underwent many changes and was constantly being examined. I used two different cameras, one for the tunnel and another for all of the other areas, since combat and exploration required different settings.

At the beginning of the camera journey I used a lot of damping and made the camera feel heavy and grave. Since it induced motion sickness for some people that was greatly reduced and even completely cut towards the end by using a "hard look at" aim.

Since the camera speed was customizable in the settings the finetuning there was also finished. One of the last parameters to be decided was the orbit binding mode. This was set to world up for a long time, since it provided to option to set the recenter to target heading, when attacking or moving to the side. I disabled it when players wanted to go downwards in the direction of the camera itself. This option meant simply that the camera recentered to be behind the players back. Since this is movement without a clear cause, some people also felt a little dizzy after, so it was also simplyfied with choosing "Simple Follow With World Up".

Glitch Effects

To enhance the surreal, technological atmosphere of our game, we wanted to give players a little peek behind the curtain. To achieve this I thought about ways to give feedback to player's actions, while doing so. On my research I found a package with a few glitchy post-processing effects. I utilized these effects by displaying them randomly for a short amount of time, when the player hits an enemy. This proofed to be a great feedback effect and also empowered the players in their experience. To add to this is also used some of Unity's pre-installed such as chromatic abboration.

Probably the most memorable way in which we gave "glitchy" feedback was the display of wireframes when the player got damage, almost resembling a thunderstorm. This was also achieved by using a pre-made shader and modifying it a little to fit our needs.

At the start of the game all the tunnel's rocks were added into a list, based on a tag. The length and which rocks were chosen were also randomized, whereas the length of displayal of each individual group of rocks, was then also controlled by an amination curve to achieve a kind of decrescendo or letting it roll out.

I would have loved to do more effects and also craft some of my own, but our time schedule was too tight and I still had to implement some features, so we left it at this.

Cutscenes

In combination with the subtitle system our cutscenes were done using Unity's Timeline feature. I mainly switched the cameras to fit the dialogue, animated to camera positions to create some dolly or tracking shots and triggered positional changes or the gate's opening with Signals, that essentially work like Unity Events. Lastly I tried to make our animations fit the conversation and blend between them as smoothly as possible.

Interaction System

In the final rooms the player has to interact with many different objects. To achieve this I used an Interface that looked for a script in range, inheriting from the interface, on button press. That way players could pick up phone calls and items or look at objects more closely.

These scripts would then call sounds, subtitles, camera-switches or events, many based on the systems explained above.

What was good about this project?

We learned a lot and I reached a new level in coding
Good division of labor
Quick ideation
Very polished for the available time
Sound design and atmosphere

What could have been better in this project?

Intense crunch
Feature creep
Sometimes saying no or delegating tasks
Better structure and planning in code
Improving how mechanics are taught and their intuitiveness

I want to thank the coaches Prof. Susanne Brandhorst, Prof. Thomas Bremer and David Witzgall for their valuable insights and feedback.