- Gameplay Systems
- In development
Shinobi Story 2
The Unreal Engine 5 follow-up to Shinobi Story. This page covers my two areas: the character creator UI, which I designed and built end to end, and the C++ traversal layer I wrote on top of third-party movement plugins.
- My role
- Co-owner. Sole UI designer and implementer; traversal programmer alongside the team
- Ownership
- Character creator UI: all mine. Traversal: my C++ layer on top of third-party movement plugins
- Built with
- Unreal Engine 5, C++ and Blueprints, Mutable character customisation
- Status
- Early prototype, in development
Jump to a section
Character creator UI
I explored eight art directions in two rounds, among them a clan-archive scroll, a field dossier, orbiting clan seals and a hanging scroll. The talisman fan won: categories hang as paper tags from a rope, the selected tag swings forward, and a banner below holds its slider or options. Then I rebuilt it in Unreal, comparing each version against the target.
Hand-drawn, not 3D cards
An earlier version used 3D card meshes. I moved to layered 2D parchment, brush lettering and ink icons, because matching the art target mattered more than keeping the 3D route.Clean cutouts
Frame, rope, cards and the confirm stamp were cut out with a Segment Anything workflow in my local ComfyUI. My export step strips the old white matte from soft edges and keeps thin rope gaps open.Native UI materials
Shadows, a gold selection rim, warm grading, worn paper edges and the ground seal are UI materials with small HLSL expressions, not baked images, so they move with the cards.Motion that reads
Each talisman sways ±0.6° on its own phase. The motion stepped at first; turning off pixel snapping on the moving panels fixed it. A 565-frame profiling capture showed the widget ticking in 0.07 ms on average, so the UI wasn't the bottleneck.
How I verified each pass
The creator went through 19 numbered versions. For each one I compiled with warnings as errors, captured every creator page in play mode, checked the log for Blueprint errors, and confirmed the sway graph was unchanged unless the pass meant to change it.
The notes also say plainly what wasn't tested yet, such as controller input and other aspect ratios.
Traversal system
The goal is fast surface-to-surface movement: leap to a branch, dash between trees, run along a wall, chain them together. Traversal is a shared effort, so here is exactly which layer is mine.
Third-party base: gravity and surface movement
Dynamic-gravity movement from a tutorial-derived plugin, OmniWalk for surface walking, and a marketplace targeting system. I kept these as reference and didn't edit the originals.My C++: traversal query
USS2TraversalQueryComponent picks the best target from camera aim, WASD intent, distance and actor tags. Scoring lives here, not in the character class, so new surface types plug into one contract.My C++: leap, tree dash, wall run
Separate components for leaping to a validated landing point, chaining tree-to-tree dashes and running along walls. Capsule movement stays code-driven; animation sells the pose but never owns the position.My C++ and Blueprint: feedback
Events like TargetLeapStarted and WallRunEnded let designers attach VFX, camera shake and audio in Blueprint without touching the movement maths.
camera aim + WASD intent → traversal query (score tagged targets) → leap / dash / wall-run component (validate landing, move capsule) → feedback events → Blueprint VFX, camera, audio
Early on, most of this lived in one movement bridge component. In a second audit I split it up: input binding, traversal focus, traversal execution, sprint presentation and cosmetic cues each got their own owner, so teammates can extend movement without breaking each other's work.
Combat prototypes
Alongside traversal I prototype combat ideas in a separate test project, such as a shadow-clone ability that spawns AI-driven copies of the player. They stay outside the main project until they prove themselves.