SOUL POSSESSION

Lead Programmer · Gameplay Systems Programmer

Soul Possession was created during a 96-hour game jam by a seven-person team, formed from the same development team I work with on RealmWalker. After spending years developing a larger project together, we decided to step away from it temporarily and challenge ourselves to build something completely different under a strict deadline.

I took responsibility for the entirety of the game's programming, including player movement, abilities, enemy systems, health and damage, possession mechanics, gameplay state, VFX integration, audio implementation, level flow, and online leaderboard functionality.

The game was designed around fast movement and speedrunning, with the player's primary ability being a grapple-based possession mechanic. The player can grapple enemies and ultimately possess them, gaining their unique movement or combat capabilities.

The result was a project that required me to move quickly while still building systems that were responsive, reusable, and robust enough to support the game's speed-focused gameplay loop.

PROJECT DETAILS

Project: Soul Possession
Event: GMTK 2026 Game Jam
Development Time: 96 Hours
Team Size: 7

https://thauma-creations.itch.io/soul-possession

TECHNOLOGIES

Unreal Engine
Blueprint
Gameplay Systems
HTTP Requests
JSON
Unreal Sound Classes
Cable Component
Camera Splines
GameMode Architecture

AREAS

Gameplay Programming
Player Movement
Combat Systems
Ability Systems
Possession Mechanics
Enemy Programming
Health & Damage
Grapple Systems
VFX Integration
Audio Systems
Camera Systems
Level Flow
Runtime State Management
Online Leaderboards
Rapid Prototyping
Game Jam Development

My Role

With only seven people on the team, I took ownership of the entire programming side of Soul Possession.

Rather than specializing in one particular gameplay system, I was responsible for taking the game's programming from initial concept through to a complete playable build.

This included:

Player movement and momentum
Grapple and traversal
Enemy possession
Combat and abilities
Health and damage
Enemy behavior
Enemy spawning and respawning
Level state and restart logic
Camera systems
Audio systems
Time-dilation effects
VFX integration
UI and menu architecture
GameMode and gameplay framework setup
Cinematic camera sequences
Online leaderboard functionality

I also worked closely with the rest of the team to integrate their VFX, assets, and other content into the gameplay systems.

The biggest challenge wasn't necessarily any individual system. It was making all of these systems work together within 96 hours while keeping the game responsive enough for its speedrunning-focused gameplay.

The Core Gameplay Loop

Grapple → Weaken → Possess → Become Something New

The grapple is the foundation of Soul Possession.

It can be used to attach to environmental grapple points for traversal, but its more important purpose is interacting with enemies.

The player can grapple an enemy and then use a close-range area attack to reduce its health. Once the enemy reaches the required health threshold while being grappled, the player can automatically possess it.

This creates a gameplay loop where combat and movement aren't separate systems:

Grapple an enemy → weaken it → possess it → gain its abilities → use those abilities to progress through the level.

The same grapple system can also attach to dedicated traversal points, allowing the player to use the mechanic for movement when an enemy isn't involved.

This made the grapple the central connective tissue between combat, traversal, enemy interaction, and progression.

Possession

Making the Mechanic Feel Right

Possessing an enemy was one of the most technically interesting parts of the project.

At a basic level, possession sounds simple: move the player to the enemy and change the player's form.

The difficult part was making the transition feel seamless from the player's perspective.

There were a large number of small details that needed to be handled correctly.

For example, simply transferring the player to the enemy's location could cause the camera to snap, rotate unexpectedly, or leave the player feeling disoriented.

I needed to account for:

Preserving the player's camera rotation.
Maintaining an appropriate camera offset relative to the new body.
Accounting for the positional difference between the player and possessed enemy.
Maintaining orientation and momentum through the transition.
Making the camera transition feel natural rather than like an actor swap.
Correctly transitioning the player's gameplay state into the new possessed form.

A significant amount of iteration went into these small camera and transform adjustments.

The technically correct solution wasn't necessarily the solution that felt correct.

I repeatedly adjusted the transition based on how it looked and felt from the player's perspective until possessing an enemy felt like a natural extension of movement rather than a mechanical teleport.

Every Enemy Changes How You Play

Possession wasn't simply a visual transformation. Each enemy type gave the player a different gameplay capability.

The game featured several specialized enemy forms:

Speedster - A speed-focused enemy provided increased movement speed, allowing the player to traverse sections of the level much faster.
Jumper - A high-jump enemy provided significantly greater vertical mobility, opening up traversal routes that weren't available in other forms.
Firelobber - The fireball enemy provided a ranged attack capable of destroying wooden barriers, allowing the player to use possession as a means of interacting with the environment.

This meant that enemies effectively became abilities the player could acquire through gameplay.

Instead of simply asking the player to defeat an enemy, the game encourages them to consider: "What can I do if I become this enemy?"

That question became an important part of the game's movement and puzzle design.

Grapple Traversal

The grapple's second major purpose was traversal.

Dedicated grapple points allowed the player to use the same mechanic to navigate the environment, creating a movement system that could be used independently of possession.

I implemented the underlying grapple interaction and used Unreal's Cable Component to visually communicate the connection between the player and their target.

I also applied a custom texture to the cable to give it a more intentional visual appearance rather than relying on the default component.

This was a relatively small technical feature, but it had a significant impact on the game's presentation because the grapple is used so frequently.

Movement & Momentum

Soul Possession was designed around fast movement and speedrunning, so movement needed to feel responsive while also providing enough visual feedback to communicate momentum.

We had limited animation resources and didn't have a large animation team available during the jam.

Instead of relying entirely on animation to communicate movement, I used the player's movement state and momentum to drive the character's rotation.

The player could lean and rotate based on their movement, creating the impression of physical momentum without requiring a full animation pipeline.

Combined with the team's VFX work, this gave movement a much stronger visual presence and helped compensate for the limited animation resources available during the jam.

A Speedrunning-Friendly System

One of the most important architectural decisions I made was how the game handled restarting a level.

Soul Possession is intended to be played quickly and repeatedly. If you're trying to improve a speedrun, restarting shouldn't feel like a loading screen simulator.

The obvious solution would have been to simply reload the level.

However, that would have introduced unnecessary loading time and disrupted the gameplay loop.

Instead, I built the gameplay around resetting runtime state without fully reloading the level.

This required tracking and restoring the state of things such as:

Player state
Possession state
Enemy state
Spawned enemies
Respawn state
Gameplay objects
Level-specific runtime state

The result was a much more seamless restart experience.

This was especially important because the game needed to support the speedrunner mindset:

Make a mistake → restart → immediately try again.

The architecture therefore had to consider not only how the game starts, but how efficiently it can return to a clean initial state.

Dynamic Time Dilation & Audio

One of the systems I was particularly proud of was the game's low-countdown time-dilation effect.

As the player's countdown approaches zero, the game enters a heightened state of urgency.

When the countdown becomes critical, I slow down the game world while also slowing the game's music and sound effects.

I used Unreal's Sound Classes and Meta Sounds to ensure that audio responded alongside the gameplay time dilation rather than continuing to play at normal speed.

This created a much more cohesive effect:

Gameplay slows → music slows → sound effects slow → the entire game feels like it is entering a final moment.

Instead of treating audio as something separate from gameplay, I connected the two systems so the player's perception of time changed across the entire game.

This ended up being one of my favorite presentation effects in the project because it required relatively little content while producing a very noticeable change in how the game felt.

Level Presentation & Camera Systems

I also implemented a system allowing the team to create camera spline sequences for level introductions.

The first time a player entered a level, we could have the camera follow a predefined spline path through the environment before returning control to the player.

This gave us a lightweight way to establish a cinematic presentation without building an entirely separate cinematic framework.

The camera system also had to coexist with the game's normal gameplay camera, possession transitions, and movement systems, so camera state needed to be handled carefully when control transitioned back to the player.

Gameplay Architecture

Because I was responsible for essentially all of the programming, I had to establish an architecture that allowed us to move quickly without turning the project into a collection of tightly coupled one-off systems.

I made deliberate use of Unreal's GameMode and gameplay framework architecture to establish clear ownership of game-level and gameplay state.

I also made use of reusable parent/child relationships throughout the project's gameplay and UI architecture.

This became especially useful for our menu and HUD systems.

Rather than rebuilding functionality independently for the main menu and gameplay, shared parent classes allowed us to reuse common functionality while specializing behavior where necessary.

That meant we could move quickly during the jam without constantly duplicating systems every time we needed a new interface or gameplay state.

For a 96-hour project, this balance was important:

Build quickly, but don't make future iteration unnecessarily expensive.

VFX & Presentation

The project had limited animation resources, so the team's VFX became an important part of communicating gameplay.

I integrated the VFX produced by the team directly into the relevant gameplay events, giving mechanics visual feedback without requiring extensive animation work.

This was particularly important for:

Possession
Grappling
Abilities
Enemy interactions
Movement
Combat
Gameplay state changes

The combination of VFX, momentum-based character rotation, and the custom grapple cable allowed the game to maintain a strong visual identity despite having a small team and extremely limited development time.

Global Leaderboard

Learning HTTP & JSON Under a Deadline

The feature I'm probably most proud of from a technical learning perspective was implementing a global online leaderboard.

Before this project, HTTP requests and JSON-based communication were relatively new areas for me.

Rather than keeping the leaderboard local, I wanted players to be able to see how their performance compared against other players.

I implemented the game's communication with an external leaderboard service using HTTP requests and JSON, allowing scores to be submitted and retrieved remotely.

The final system created a complete loop around the game's speedrunning focus:

Play → Optimize → Improve Your Time → Submit → Compare Against Other Players

Getting this working during a 96-hour game jam was particularly rewarding because it required me to learn an unfamiliar technology while simultaneously integrating it into the rest of the game's architecture.

It was a good example of one of the skills I value most as a programmer: being able to quickly learn and apply technology when the project requires something outside my existing comfort zone.

The 96-Hour Constraint

The biggest engineering challenge of Soul Possession was simply the amount of ground that needed to be covered.

As the sole programmer, I was responsible for systems spanning almost the entire gameplay stack:

Movement → Combat → Abilities → Enemies → Possession → Traversal → Audio → Camera → UI → Level State → Online Services

And all of it needed to be functional within 96 hours.

This forced me to make constant decisions about where architectural investment would provide meaningful value and where a simpler solution was appropriate.

I couldn't build every system as though I had unlimited development time.

At the same time, shortcuts that would make a system difficult to iterate on could become more expensive later in the jam.

The project therefore became an exercise in rapid architecture: determining which foundations were worth establishing early so that the rest of the game could be built quickly on top of them.

Outcome

Soul Possession was successfully developed and shipped as a seven-person game jam project within 96 hours.

As the sole programmer, I was responsible for taking the game's programming from concept to a complete playable implementation while working closely with the rest of the team to integrate VFX, assets, and other content.

The project challenged me to work across almost every major gameplay layer while maintaining the responsiveness necessary for a speedrunning-focused game.

More importantly, it gave me the opportunity to solve several problems where the obvious implementation wasn't necessarily the best one:

Building runtime level resets instead of relying on level reloads.
Designing possession around player perception rather than simply swapping actors.
Preserving camera orientation and positioning during possession transitions.
Using one grapple system for both traversal and enemy possession.
Connecting time dilation with audio through Sound Classes.
Using gameplay-driven movement and VFX to compensate for limited animation resources.
Establishing reusable gameplay and UI architecture under a 96-hour deadline.
Learning HTTP and JSON to build a global leaderboard.

Soul Possession represents a different side of my programming experience than my longer-term projects.

Where RealmWalker demonstrates my ability to build and maintain complex systems over years of development, Soul Possession demonstrates my ability to take complete technical ownership, learn unfamiliar technologies quickly, make architectural decisions under extreme time constraints, and turn a gameplay concept into a shippable experience in 96 hours.

7 developers. 96 hours. One complete game.

Soul Possession