Technical Designer
7 Weeks (2025)
17
Designed and prototyped gameplay features and mechanics.
Developed custom blueprints/interactions for level designers.
Collaborated with programmers on optimizing my prototypes.
Designed and developed enemy AI, including behavior trees.
Implemented animations through blend spaces, animation blueprints, and montagesPrototyping, pitch, feedback, iteration
Development of essential gameplay systems and frameworks
Core mechanics implementation, level blockouts
Playtesting, refining art direction and mechanics, adding 'juice'
Level dressing, finalize mechanics / features
Bug fixing, performance optimization, more playtesting
Final polishing touches, marketing materials, feedback
Given combat and sandbox as our genres, we established a few core goals to guide our decisions:
With our full team assembled, we immediately collaboratively brainstormed and documented ideas, keeping our past prototypes and chosen genres in mind. The designers then combined these ideas into three different packages, each with a concise pitch. Following a team vote, a pitch was selected.
Drawing from our gameplay inspirations, we analyzed their common audiences, noting their likes and dislikes:
Inspired by Control, I felt that telekinesis as a core player ability was perfect for a combat-sandbox type game. It offers extensive freedom, enabling interaction with entities and the environment, causing destruction, and solving puzzles.
My prototype focused on replicating Control's "Pull" ability's feel. While the core logic was in Blueprints, I discussed with a programmer about implementing custom C++ nodes for optimization later on.
For a third-person perspective, the crosshair was not aligned with the camera's forward vector. Therefore, I utilized a line trace along a specific channel, originating from the screen location of the crosshair and extending a reachable distance in front of the player.
Since combat can be chaotic, if no object was directly within the player's crosshair, I implemented a secondary sphere trace to detect any nearby objects around the player that were not obscured by walls.
The nearest detected object would always be stored in a reference variable with a post-process highlight effect activated to indicate to the user what was currently within pull range.
When the player activates telekinesis with a valid object, it is attached to a physics handle on the player. While this handles much of the position updating, collaborating with another designer and programmer allowed us to add interpolation and position offsets based on each object's size.
To denote objects that were pullable, I made an actor component you could easily attach to any static mesh in the level. It would automatically set the correct variables and channels needed, but also had adjustable values for different behaviors.
When using the physics handle, I wanted to give players more control and responsiveness over held objects. I started by implementing a system where the object would rotate with the camera's pitch, allowing it to follow the player's gaze when looking up or down.
This enhancement helped players stack objects using telekinesis. Additionally, I added an adjustable offset for the physics handle to control the distance of objects from the player. This prevented objects from colliding with the player or going off-screen, improving the overall feel.
I attempted to implement a system to update the physics handle's location when encountering walls, aiming to keep the object consistently in view. However, this led to issues with items clipping through walls or becoming permanently stuck. As a result, we later decided to simply drop the object if it moved too far from the player.
To give players a sense of control and power, I designed launched objects to have a strong impulse force and temporary no-gravity for 'x' seconds. Upon impact, the object's behavior was determined by its assigned enum in the actor component, allowing for actions like sticking, destroying/exploding, bouncing, etc.
The third-person perspective presented challenges for aiming. I initially used a line trace from the held object's location to where a secondary, extended crosshair line trace would hit. Since this wasn't a direct line to the crosshair (like a camera's forward vector would provide), accuracy often felt off.
Later in the project, working with a programmer, I designed and he implemented a solution using a larger sphere trace to detect objects, rather than a thin line trace. While this improved accuracy, I aim to refine this system further in the future. Control locks on targets and I prototyped this too, but I decided against this to keep the theme of freedom for the player.
Montages proved invaluable for playing quick animations, particularly for enemies taking or dealing damage. The Scientist utilized an animation blueprint to manage its looping animations, such as walking, pull attacks, and being stunned.
I struggled with implementing the procedural animation our animator created for the Spider. Due to time constraints, we had to revert to a standard walk cycle. I'm hoping to revisit this in the future, as smoother movement transitions across different surfaces were also something we wanted to achieve.
Neila's diverse movement, especially when using telekinesis, required careful animation management. To keep her animations structured and consistent, I built two separate blend spaces and a state machine within the animation blueprint. During telekinesis, I track the player's movement direction and speed to ensure a proper blend between the different animations.
As the player's captors, Scientists were designed for building tension and showcasing strength. Using a behavior tree for the first time, I began the design with a slow, menacing walk culminating in a powerful slam attack with knockback.
Collaborating with artists, we gave them a steam engine weakpoint on their back for significant damage. To make it possible to reach, I enabled the player to stun Scientists with their telekinesis.
I initially experimented with the weakpoint being the only way to damage the Scientists, and stuns dealt no direct damage. However, this approach led to overwhelming feedback about difficulty and frustration. So, I revised it to include a damaging stun while upgrading the weakpoint to be a one-shot.
To balance their slow movement with their threat level, I gave them a beam attack that pulls the player. Early playtesting showed that an auto-latching beam was too frustrating. To make it more avoidable, I designed a version with a charge-up period, a moving beam that sweeps in a radius towards the player, and the ability to cancel the attack with stuns.
The Ball was our first enemy, designed by a teammate as a common, easily defeatable foe that also offered opportunities for player experimentation. While I believe it largely succeeded, we received significant feedback regarding confusion about its identity as an enemy and its overall purpose. To clarify this, I adjusted its behavior accordingly.
Before (Initial Concept)
After (Refined Version)
For this project I mainly focused on:
However, I had other repsonsibilities, making it my personal goal to have every component I worked on be understandable and modifiable so other disciplines could use them with ease. If a level designer had a request, I would do my best to make their workflow easier.
During playtests, we observed that players often felt physically lost or confused about their objective. To address this, I introduced three types of optional upgrades players could collect, incentivizing exploration and making escape much easier.
I also developed a flexible Blueprint interactable. This allowed artists and level designers to easily place custom lore elements throughout levels. The system supported variable UI widgets, offering customization while centralizing core functionality.
To help guide players, especially through the tutorial sections, I implemented flashing UI indicators on points of interest. This ensured players wouldn't miss crucial information, such as the game's two other abilities.
I achieved this using a UI animation. The interaction points themselves relied on box triggers and an interface created by a programmer to function.
Initially, I envisioned dedicating specific rooms to scripted enemy encounters, much like the games that inspired us. However, I shifted to developing an easily modifiable enemy spawner. This approach offered better performance and greater adaptability in the long run.
For example, I'd planned a dramatic, almost jump-scare-like first encounter with the Scientist, where they'd burst through a door. But this coincided with players unlocking the "glue" ability, leading to players overlooking the new mechanic. To allow players time to learn their new ability, I redesigned the encounter. Now, the door can only be unlocked by the player's glue ability, and the Scientist spawns once the player opens the door.
Working with a larger team for a shorter period of time can have its difficulties, but we did a good job of creating a strong core from the beginning that we stuck with throughout the project. We took feedback in stride and adjusted when needed. I learned a lot of technical knowledge about UE5, behavior trees, implementing animations, and prototyping blueprints that were readable and usable for other disciplines. However, I also learned a great deal about target audiences, marketing strategies, conducting playtests, delivering staged builds (pre-alpha, alpha, beta, etc.), and working with project managers. This project was a great experience and I hope to continue improving it and upon myself going forward.
