Operation P.L.U.S.H
Operation P.L.U.S.H
Embedded Files
Game Play/Trailer
Game Play/Trailer
Operation P.L.U.S.H.
Lead Engineer • Combat Designer Unreal Engine 5 • C++ • Blueprints • Gameplay Ability System • Nintendo Switch
Operation P.L.U.S.H. is a 1–4 player cooperative horde-defense game where players control dream-powered plushies defending the Nightlight from waves of Nightmares.
As Lead Engineer and Combat Designer, I developed core gameplay and combat systems in Unreal C++ and Blueprints, implemented character abilities using Unreal's Gameplay Ability System, built round-preparation and placement mechanics, contributed to cooperative vehicle systems, debugged gameplay and engine issues, and worked on Nintendo Switch development and optimization.
Team: 15 developers • 4 engineers
Platform Development: Windows / Nintendo Switch
Released on: Steam
Engine: Unreal Engine 5
Languages: C++ / Blueprints
My Contributions
Combat & Character Abilities
Designed and implemented each character's core combat kit using Unreal's Gameplay Ability System, including basic attacks, heavy/special attacks, and utility abilities. I worked across gameplay logic, animation timing, ability sequencing, VFX integration, and game-feel iteration.
Gameplay Systems
Developed gameplay systems in Unreal C++ and Blueprints, including the pre-round placement system used to pick up, position, and deploy defensive objects and power-ups before combat begins.
Cooperative Vehicles
Worked on interactive gameplay objects including a two-player tank and a drivable explosive car, implementing the gameplay logic required for players to interact with and use these systems.
Debugging & Optimization
Investigated and resolved gameplay and C++ issues throughout production, including system interactions, edge cases, Unreal packaging/cooking problems, and platform-specific bugs.
Nintendo Switch
I contributed to development and testing of a Nintendo Switch version of Operation P.L.U.S.H., focusing on performance optimization, platform-specific debugging, and Unreal Engine build stability. My work included investigating differences between PC and Switch builds, resolving packaging and cooking issues, debugging platform-specific problems, and optimizing gameplay and content for the hardware constraints of the platform.
Combat & Character Abilities
I worked on the combat kits for all four playable characters in Operation P.L.U.S.H., implementing their basic attacks, special abilities, and utility abilities using Unreal Engine's Gameplay Ability System (GAS).
My work included gameplay logic, ability timing, animation implementation, VFX integration, cooldown and charge behavior, hit detection, damage and healing interactions, movement changes, and general combat feel.
Each character was designed around a different gameplay role, so the abilities could not all use the same behavior. Some relied on combo timing, others used charge-based cooldown systems, held-input behavior, directional movement, healing, knockback, stun, or interactions with other players.
Important balance values such as cooldown durations, charge counts, damage, healing, attack radius, movement speed, timing windows, and other ability parameters were exposed so designers could tune the characters without changing the underlying implementation.
Dream Bubble Placement System
Before each combat round, Dream Bubbles spawn around the map and allow players to prepare the arena before the Nightmares begin attacking.
Players can pick up a Dream Bubble, move it to a desired location, and place it to spawn its associated gameplay object. Depending on the bubble, this can create defensive blockers, power-ups, or larger interactive objects such as vehicles.
I developed the system using a combination of Unreal C++ and Blueprints, including the player pickup component, targeting logic, placement validation, grid snapping, object spawning, visual feedback, and support for repositioning previously placed objects.
Player Pickup Component
I implemented a reusable character component responsible for handling the player's pickup and placement state.
The component tracks the currently held Dream Bubble and prevents invalid interactions such as attempting to pick up multiple objects simultaneously. It also stores the character-specific held-object offset used to position the Dream Bubble while it is being carried.
When a Dream Bubble is successfully picked up, it:
becomes the player's currently held placement object.
disables its physics behavior.
attaches to the character using the pickup component's configured held location.
begins displaying the placement preview for the object it will create.
This kept the pickup logic centralized on the character instead of duplicating it across every type of placeable object.
Technical Implementation
Reusable Unreal C++ character component
Held-object state management
Single-object pickup restrictions
Character-relative held-location offsets
Actor attachment / detachment logic
Round-state interaction restrictions
C++ and Blueprint integration
Selecting the Correct Dream Bubble
Picking up an object required more than simply checking which Dream Bubbles overlapped the player.
On interaction, I perform a sphere trace around the character and evaluate the detected Dream Bubbles using both their distance from the player and their position relative to the player's facing direction.
The goal is to select the closest valid Dream Bubble that the player is actually facing.
Close-Range Targeting Problem
During testing, I found an edge case where Dream Bubbles positioned extremely close to the character—or slightly outside the expected facing angle—could fail the targeting check even though they visually appeared to be directly in front of the player.
To solve this, I moved the origin used by both the sphere trace and directional-angle calculation slightly behind the player.
This widened the effective selection area at close range while preserving the intended forward-facing targeting behavior.
That small adjustment made picking up objects much more reliable without requiring an excessively large interaction radius.
Technical Implementation
Sphere-trace-based candidate detection
Distance comparison between valid candidates
Player-facing / angle validation
Closest-valid-target selection
Close-range targeting edge-case debugging
Adjusted trace and directional-check origin
Placement Preview & Validation
Each Dream Bubble contains a reference to the placeable object it represents as well as the mesh used to preview that object while the bubble is being carried.
The preview provides immediate visual feedback about whether the current location is valid:
Green silhouette — Valid placement
Red silhouette — Invalid placement
The system continuously evaluates the area beneath and around the proposed placement location before allowing the player to place the object.
Different placeable objects can use different validation settings, allowing larger or differently shaped objects to require different amounts of valid ground space.
Technical Implementation
Placeable-object references
Placement-preview mesh
Real-time valid / invalid placement feedback
Multiple ground line traces
Configurable validation checks per placeable type
Environment and ground validation
Grid Snapping & Placement
When the player drops a Dream Bubble in a valid location, I calculate its final position and snap the placement to the game's grid.
The system then performs additional safety checks on the calculated grid location before committing the placement.
Once the location is accepted:
The Dream Bubble is positioned at the validated location.
A pop VFX is triggered.
The associated placeable object is spawned.
The spawned object plays a small scale-up / scale-down bounce animation to provide placement feedback.
The Dream Bubble transitions out of its held state.
This allowed placement to remain visually aligned with the environment while still letting players freely move Dream Bubbles around before choosing where to commit them.
Technical Implementation
World-to-grid position calculation
Grid snapping
Final placement safety validation
Placeable actor spawning
Spawn animation
Pop VFX implementation
C++ gameplay logic with Blueprint presentation
Repositioning Placed Objects
Placement is not permanent during the preparation phase.
Each spawned object maintains the information required to restore its associated Dream Bubble if players decide they placed it incorrectly or want to reorganize their defenses.
I used an interaction interface to allow different types of placeable objects to participate in the same pickup workflow without requiring the player component to know the implementation details of every object type.
When a placed object is picked up again:
The placed gameplay object is removed.
Its Dream Bubble becomes active again.
The bubble is returned to the player's pickup system.
The player can move it and place it somewhere else.
This gave blockers, power-ups, vehicles, and other placeable objects a shared interaction workflow while allowing each object to retain its own gameplay behavior.
Technical Implementation
Interface-based interaction
Reusable placeable-object architecture
Object-to-Dream-Bubble references
Pickup-after-placement support
Placement state restoration
Shared workflow across different placeable types
Round Transition Safety
Dream Bubbles exist specifically for the preparation phase.
When the combat round begins, any Dream Bubble that has not been successfully placed is automatically removed without spawning its associated object.
This prevents uncommitted placement previews or carried bubbles from leaking into the active combat phase and keeps the round state deterministic.
System Flow
Technologies / Techniques
Unreal C++ • Blueprints • Actor Components • Interfaces • Sphere Traces • Line Traces • Vector / Angle Math • Grid Snapping • Actor Attachment • Runtime Validation • VFX • Reusable Gameplay Architecture
Page updated
Google Sites
Report abuse