BOUNCEED

3rd-person movement sandbox (jumppad-focused) · Unreal Engine 4.27 · PC

My Role

Technical Game Designer (solo dev)

Project At a Glance

A jumppad-focused traversal game that reframes jump pads from a supporting movement tool into a learnable core system, built around structured tutorials and player-driven experimentation.

Play Now

Project Information

Type: Course project (ISART Digital Paris, Third-year “3C Project”), later continued as a Gold polish pass
Genre: movement sandbox, jumppad-based experiments
Engine: Unreal Engine 4.27
Platform: PC (Keyboard + Mouse)
Team size: 1
Duration: 6 weeks (course sprint) + ~3 weeks (Gold polish)

Highlights

Public traction: ~160K views, ~10K likes, ~1.4K comments on Bilibili.
Academic evaluation: received a high final grade as a third-year game project.

What I Built

My Contributions

As a solo project, I was responsible for nearly all gameplay-facing systems. My main focus was building a movement-centric sandbox where jumppads act as the core gameplay language, supported by clear onboarding and readable interactions.

Built the third-person 3C and locomotion foundation, including Animation Blueprint setup and tuning for jump-heavy, high-speed traversal.
Designed and implemented two placeable jumppads as the primary gameplay brick, each with distinct risk–reward profiles:
- Blue JumpPad supports flow, velocity stacking, and rebound-based traversal.
- Red JumpPad provides strong, directional launches for deliberate setup.
Defined jumppad rules as part of the gameplay language, including placement replacement and mixed-pad chaining that rewards mid-air alternation with a charged triple jump.
Built a tutorial-first hub structure that teaches movement through “demo, then test” loops before opening into free sandbox exploration.
Designed firearms and projectile interactions as a supporting layer, extending jumppad play beyond movement into indirect shots, setups, and experimentation.
Created an interaction-focused energy weapon, whose visible beam makes projectile rebounds and jumppad-based setups easier to reason about.
Developed reusable interactive level design objects (LDOs) such as buttons, elevators, doors, and speed challenges to validate mechanics and scale content efficiently.
Implemented readability and discovery tools (scan-based visibility, trajectory cues) to help players form a mental model of high-speed interactions.
Completed a post-course Gold polish pass, fixing deferred bugs and adding settings and bilingual localization (EN / Chinese).

Key Design & Tech Challenges

Two problems shaped most of my work.

Onboarding a high-speed sandbox so first-time players can learn it
- Problem: early playtests showed the core mechanic was fun, but players could not infer the rules, so they assumed randomness.
- What I did: structured onboarding in a hub map (Basic then Advanced), plus Metrics and Speed Challenge LDOs to make outcomes measurable and comparable.
- Why it mattered: movement systems need a teachable ramp, otherwise they do not communicate skill progression.
Blue JumpPad (All Direction), consistent launches under velocity stacking across floor, wall, and ceiling placements
- Problem: Blue pad stacks player velocity, so placement orientation and surface type magnify small differences. Floor logic applied to ceiling did not produce expected results, and wall or corner placements could create direction flips that players read as bugs.
- What I did:
  - Split launch rules by placement surface using a placement-time trace and the hit normal, routing to dedicated logic for floor, wall, and ceiling cases.
  - Preserved player intent during chaining by using smoothed movement intent and a low-intent fallback, so near-stationary launches do not feel jittery.
  - Added post-launch landing feedback via PredictProjectilePath, reducing trial-and-error when chaining or rebounding at speed.
- Why it mattered: jumppads are the core gameplay brick. If outcomes drift across placements, players stop experimenting, and the sandbox loses its mastery loop.

Inside the Project

Systems, decisions, and how things actually worked.

Project: BOUNCEED (ISART Digital Paris, Third-year “3C project”, later continued as a Gold polish pass)
Genre: 3rd-person movement sandbox, light shooter interactions, puzzle-like traversal challenges
Platform: PC
Engine: Unreal Engine 4.27
Primary input: Keyboard + Mouse
Team: 1 (solo dev)
Duration: 6 weeks (course sprint) + ~3 weeks (post-course Gold polish)
Shipped scope: a hub-style sandbox map, no strict win condition by design
Tutorial runtime: Basic ~10 min, Advanced ~12 min
Hub structure:
- Basic Tutorial, isolated movement and single-pad lessons (demo, then test)
- Advanced Tutorial, pad mixing, Speed Challenge LDO, Tracing Beam Pistol, final combined test
- Level Zone, extra mechanic demos not fully tutorialized
- Sandbox Zone, experimental and unfinished content (enemy prototypes without AI)
- Metrics Zone, a calibration space to measure movement outcomes (single jump, chained jumps, etc.)
Public traction: ~160K views, ~10K likes, ~1.4K comments on Bilibili

Brief

BOUNCEED is a movement-first sandbox built around one idea: jumppads as the primary gameplay brick. The hub map works like a curriculum plus playground, it teaches pad rules quickly, then lets players freely experiment with combinations and interactions.

Gameplay Goals

Make two pad types feel meaningfully different:
- Blue pad supports “flow” and rebound behavior, it should feel agile and consistent.
- Red pad is more powerful, it should feel risky but still controllable.
Reward mastery through mixed-pad chaining, enabling multi-jumps without landing.
Keep high-speed movement readable, so players can form a mental model instead of blaming randomness.

Constraints

Solo dev under a short course timeline, with a later polish window for robustness.
Needed reusable LDO patterns and stable system behavior, otherwise the hub could not scale fast enough.

Systems I owned

3C and locomotion: third-person movement controller and Animation Blueprint tuning for jump-heavy traversal.
Jumppad systems:
- Blue JumpPad (All Direction): velocity-stacking launch behavior supporting ground, wall, and ceiling placements.
- Red JumpPad (Specific Direction): strong directional launcher with rotatable placement.
Pad gameplay rules:
- pad replacement on placement,
- mixed-pad chaining rules enabling a charged triple-jump when alternating pad types mid-air.
Tutorial-first hub structure: a curriculum-style hub with Basic and Advanced tutorials, followed by free sandbox exploration.
Interactive LDOs: buttons, elevators, doors, Speed Challenge objects, and other reusable level-design actors.
Firearm and pickup systems:
- pickup, equip, drop loop for weapons and items,
- firearm shooting and reload logic with Animation Blueprint integration,
- projectile behavior integrated with jumppads, enabling indirect shots and setup-based interactions.
Special interaction weapon (Tracing Beam Pistol):
- object tethering and interaction-focused gameplay,
- visible beam used to reason about jumppad reflections and extended setups.
Scan station system:
- custom stencil and depth-based highlight,
- time-limited visibility for devices, hazards, and invisible killzones.
Post-course Gold polish:
- bug fixing and stability improvements,
- settings menu,
- English and Chinese localization with region-based switching.

Key decisions I pushed

Treat onboarding as the first-class system.
- Early playtests showed that dropping players into two placeable pads created confusion, so I committed to a curriculum-style hub (teach, then test) before opening the sandbox.
Enforce “smooth and intuitive” launch rules over raw physics purity.
- For pads that stack velocity, I prioritized outcomes that match player expectation across placements, even when it meant adding rule-based handling for edge cases.
Make outcomes readable instead of mysterious.
- I added a post-launch landing marker (Based on PredictProjectilePath) so players can form a reliable mental model of chaining and rebounds with less trial-and-error.
Keep combat as an optional layer, not the identity of the project.
- I retained and lightly developed firearms as a sandbox extension (e.g., auto-ammo energy pistol) to expand experimentation without competing with the pad-centric mastery loop.

TLDR;

The hardest part was turning a fun movement toy into a controllable system. That meant:

making a sandbox learnable fast, and
keeping a combinatorial movement system shippable through deliberate scope control.

Problem 1

Teaching a high-speed jumppad sandbox without killing experimentation.

Why it was hard

The core mechanic became fun early, but playtests showed that without guidance, players could not infer the rules. With high-speed launches, they have little time to interpret what happened, so they conclude the system is uncontrollable even when it is consistent.

In other words, the problem was not “fun”, but comprehension under speed.

What made it hard

Two pad types with different launch logic, plus mixed-pad chaining
Wall placement changes expectations immediately compared to ground use
A sandbox structure where players choose their own order, removing linear pacing
High-speed traversal leaves no room for slow trial-and-error learning

What I did

Introduce curriculum-based tutorials as part of the hub:
- Basic Tutorial isolates one pad at a time, showing a clear demonstration before asking the player to perform a controlled test
- Advanced Tutorial introduces mixed-pad chaining and validates understanding through a combined challenge
Forced learning through use, not explanation:
- Players must place and trigger pads themselves to progress
- There is no optional skip or abstract instruction layer
Delayed full freedom until after core rules were internalized:
- The sandbox opens only after players have successfully executed intentional pad setups

Result

By the end of the tutorial sequence, player behavior visibly changed:

players actively experimented with mixed-pad setups instead of single-pad spam
players began predicting landing outcomes rather than placing pads randomly

The system shifted from “random bouncing” to intentional chaining without reducing speed or freedom.

Problem 2

Keeping a jumppad-centric sandbox shippable as a solo project.

Why it was hard

A jumppad system scales combinatorially.

Surface type, placement orientation, velocity stacking, chaining rules, and player intent all interact, and each new axis multiplies edge cases.

As a solo developer under a fixed course timeline, I could not afford an ever-expanding design space.

If I did not actively constrain the system, the project risked collapsing under bug fixing and unfinished polish rather than design iteration.

What made it hard

Jumppads interact with surfaces, angles, and velocity, creating many potential edge cases
Tutorial design amplifies system complexity instead of hiding it
Solo development meant limited debugging bandwidth and recovery time
Late in production, personal health issues further reduced available energy, forcing sharper prioritization

The real challenge was deciding what not to build while keeping the core idea strong.

What I did

Committed to a strict core vs extension split
- Core system: two pad types, mixed-pad chaining, and predictable launch behavior
- Extensions (weapons, scan, projectile interactions) were treated as optional layers and never allowed to redefine the core loop
Compressed complexity into combinations, not new systems
- Instead of adding more pad types or surface rules, I focused on meaningful interactions between the two existing pads
- Charged triple-jump emerges from alternating pad types mid-air, rather than a standalone mechanic
Used curriculum structure to control exposure
- The tutorial hub gates complexity deliberately, so players encounter rules gradually instead of all at once
Made deliberate cuts and constraints
- Did not introduce additional surface types
- Limited red pad rotation to discrete steps, even though finer control was possible
- Deferred enemy AI and deeper weapon systems due to low priority relative to the movement core

Result

By actively constraining system growth:

I was able to reach a polished Gold build within a limited time window
Players learned and mastered the jumppad system instead of being overwhelmed by it

The project shipped as a coherent movement sandbox with clear scope and polish.

Early engine learning prototype

I started with a small Unreal prototype to validate fundamentals: Animation Blueprint setup, basic firearms, pickups, and overall character feel.

This phase was tool-focused rather than idea-driven. The prototype confirmed I could move fast in Unreal, but it also made one thing clear: the project needed a stronger core than “a collection of mechanics”.

This led me to step back and commit to a single gameplay question instead of expanding features.

Locking the core: Jumppads as the gameplay language

After drafting an early concept document, I committed to jumppads as the central gameplay brick.

The goal was not to add more mechanics, but to see how far two pads could go when treated as a primary system rather than a support tool.

Early iteration focused heavily on launch behavior and chaining, because every later decision, tutorials, puzzles, and readability, would depend on whether pad outcomes felt intuitive under speed.

You can check the Game Concept Document here.

Alpha: fun without comprehension

By late Alpha, the core movement was already fun.

However, both playtests and instructor feedback revealed the main risk: players were disoriented.

New players struggled to understand what the two pads were capable of.
High-speed launches left little time to reflect on what just happened.
Without guidance, players assumed randomness even when the system was consistent.

At this point, it became clear that the problem was not adding content, but teaching the system without slowing it down.

Reframing the project around teachability

This was the turning point where I committed to a tutorial-first hub as a core system decision.

Instead of treating tutorials as optional explanations, I designed the hub as a curriculum:

Basic Tutorial isolates one pad at a time, showing a demonstration before asking the player to perform a controlled test.
Advanced Tutorial introduces mixed-pad chaining and validates understanding through a combined challenge.
Full sandbox freedom is deliberately delayed until players demonstrate intentional use of the system.

The decision was pragmatic. Without structured onboarding, the project would remain impressive to watch but difficult to actually learn.

Scope control under solo constraints

While building the tutorial hub, system complexity became much more visible.

Lighting, optimization, pad edge cases, and iteration speed all competed for limited time and energy, especially late in Alpha when I began to experience health-related constraints.

This forced a series of deliberate cuts and constraints:

I did not introduce enemy AI, because combat was not the focus and would dilute the jumppad-centric loop.
Firearms were kept as sandbox extensions and prototypes inside the hub, not as a full combat system.
Red pad rotation was limited to discrete steps, even though finer control was technically possible.
No additional surface types or new pad variants were added.

The guiding rule was to compress depth into combinations of existing systems, rather than expanding the system count.

Gold pass

After the course milestone, I treated the final phase as a shipping and robustness pass.

No new content was added. The focus was on removing friction:

Fixed numerous small but immersion-breaking bugs, including character offset issues that became more noticeable after adding Foot IK.
Refined visual feedback such as jumppad activation particles to improve clarity and consistency.
Standardized interaction behaviors across systems.
Added English and Chinese localization with region-based switching.
Improved stability and accessibility for public-facing builds.

The goal of the Gold pass was simple: deliver a build that players could actually learn and enjoy, rather than expanding scope.

Results

Shipped a polished movement-first sandbox within a tight solo development timeframe, bringing a system with high combinatorial risk to a stable Gold build.
Public showcase received strong qualitative player feedback, with comments consistently focusing on the novelty and expressiveness of jumppad-based movement, indicating that the core idea resonated beyond the classroom context.
Course evaluation highlighted the project’s completion level and design judgment, especially the ability to scope, prioritize, and ship a coherent experience rather than an overextended prototype.
The project demonstrated that a jumppad-centric system can support sustained experimentation and mastery, rather than serving only as a short-lived movement gimmick.

Takeaways

Solo development requires active constraint, not just efficiency.
Without clear limits, system-driven games scale faster than a single developer can maintain. Defining what belongs to the core and what remains optional is a design responsibility, not a production afterthought.
System design is about combinations, not accumulation.
Meaningful depth came from interactions between two pad types and chaining rules, not from adding more mechanics. Restraining feature count improved both learnability and polish.
Technical solutions only matter when they serve player understanding.
Launch smoothing, readability aids, and rule-based handling were valuable because they reinforced player intuition, not because they were technically complex.
Player feedback validated the design direction.
The most insightful responses focused on freedom, creativity, and movement expression, confirming that innovation emerges from identifying what players want to explore, not from novelty alone.
There is a clear upper bound to solo development.
Even with strong technical control, collaboration would enable faster iteration, broader exploration, and better content quality. This project clarified where teamwork and communication become force multipliers rather than overhead.

If I did it again

I would cut more, earlier, and formalize scope boundaries before production pressure forces reactive decisions.
I would design the player experience flow earlier, using explicit flowcharts to control when complexity is introduced and when freedom is unlocked.
I would actively seek collaboration, using my strengths in system design and movement feel to support a team, rather than carrying the entire production alone.