top of page
FutureGamesProjectThrall_edited.png

Thrall

Genre:
PvE
Horde Shooter/Slasher

Contribution: 

Systems Design
Tech Design
Prototyping

Time:
7 Weeks

Team Size:

14

Engine:

Unreal Engine 5

Thrall Background.png

The third gameproject at FutureGames, we were let very loose to determine a game theme.

We landed on a horde slayer theme with possession as a main mechanic.

​

And thus, Thrall was conceptualized.

​​

The player plays as the broken spirit of a former tyrant, jumping from host to host, using their abillities against their allies.

​

​

My main role for the project as a Systems Designer, designing, implementing and maintaining the games various gameplay systems. I also helped provide tech solutions for my less technical colleauges.

Concept

Pillar VIT.webp

Weapon-as-Verb

 

The Host is the weapon. Host dictate gameplay.

 
Pillar VIT.webp

Power Fantacy

 

Make the player feel powerful

 
Pillar VIT.webp

Brutal world 

 

Uneasy atmosphere, encourage cold blooded behaviour

 
Thrall Poster Background.png

I took the responsibility of making the main mechanic of the game, the possession system.

​

​The player can take controll of an enemy to gain access to a physical form, now able to inflict harm on its former allies.

​

​If the host were to die, so would the player. Therefore the player can switch host at any point of their choosing.

 

I wanted to make a chaotic gamplay system for the player to interact with and wreak havoc on their foe to reinforce the third pillar. I landed on fire and explosions

​

Fire spreads, rappidly. The player can knock down torces and ignite their arrows on fire sources. Theese then start chain reactions in the level.

​

A burning enemy walks too close to an explosive barrel? BOOM!
Is the player themselves burning? Now they are also shooting burning arrows. 

​A very modular and emergent system to help the level designers create controlled chaos in the areans.

Thrall Emergern Flowchart.png

Initial designs were messy and very much "throw everything at the wall and see what sticks". I decided to streamline my initial design into the three diffrent modules of the system.

​

Fire Source: A fire source can ignite Flammable Objects in close proximity.

​

Flammable Object: Once ignited will turn into a fire source and apply Burning Status Effect to enities in close proximity.

​

Burning Status Effect: Deals damage over time to applied entity. Turns the entity into a fire source. After a duration the effect wears off.

​​

This all results in a big feedback loop where one thing ignites another and so the cascade continues.

​

All of these diffrent modules is its own Blueprint Actor Component making the whole system easily expandable.

This renforces the first and second pillars, prompting the player to swich host, overpowering its concience and gaining a new weapon.

​

We initially had problems with the player changing host too often, constantly jumping between hosts making them effectiley unkillable. To solve this I added a charge requirement for the possession to purposfully slow the player down a nudge. This worked wonders, encouraging the player to remain with one host but not enough to make changing of hosts feel punishing.

 

Players also didn't know how much HP the new host would have. And since player health is tied to the hosts health that became a feel-bad for the player, changing host effectiley became gambling. A colored outline was added, ranging from green to red to communicate to the player the health value of the soon to be host.

Explosive Madness

Possession System

DividerOrange.png
Thrall Background Learnings.png

Working on Thrall has been an incredibly insightfull experience and exercise. In communication, stress and good old personal growth.

 

This was my first time working in in an agile workflow, showing me work structure I had never before experienced in game development. An invaluable insight into how games are made.

​

Constant communication with team members provided a unified vission of the game and made sure we were all moving towards the same success. But communication does not stop at the team members. Player communication must also be clear so that the player understands whats happening or what to do to progress. Playtesting here is key, hosting, noting and acting on the feedback provided by players is the only way to work through said problems.

​

Build-day-nightmares is also something we encountered. I've started building projects alot more often to make sure we catch issues early and can propperly allocate the time and resources needed to resolve said issue. 

 

What I Learned

bottom of page