Etherbound · Development journal · Day 2
From animation studies to playable Earth abilities
Day 2 of the Etherbound development journal: moving a measured Blender study onto the existing Unreal mannequin, then testing two Earth abilities in one playable sandbox.
By Vincent Gauthier · · 6 minute read
Counts record share-dialog opens and completed copy/share actions—not confirmed social posts or views.
The next question was whether the work could survive play
Day 1 ended with an editable Blender study and a clearer way to review motion. Day 2 asks a stricter question: can that evidence survive transfer onto Etherbound’s existing Unreal mannequin without replacing its locomotion, vaulting, or combat sandbox?
Two Earth abilities now run in that sandbox. E, Earth Elbow drives a short forward elbow into a stone. Q, Earth Launch follows with its own release timing and props. The progress is not that a clip exported. It is that each ability now has its own source packet, motion data, test recipe, and review record while sharing a common lifecycle.
The comparison below places source E then Q beside the Unreal captures. It is a review compilation, not one continuous gameplay recording. Its soundtrack is the original source audio, not recorded Unreal audio, so it helps inspect timing without claiming that native sound playback has been validated.
Retargeting made a new class of failure visible
A Blender export can agree closely with its saved bake and still fail on the game skeleton. In the first Unreal transfer, the measured contact interval showed 11.86 cm and 8.67 cm of horizontal foot drift. That did not invalidate the Blender study. It showed that export agreement and planted feet after retargeting are different checks.
Calibration also proved specific to the source and target rig pair. E needed a different casting orientation from Q. Moving that adjustment into the export frame exposed a root-translation unit error, which we fixed without rewriting the approved Blender motion. The lesson is narrow but useful: a conversion setting that works once is evidence for that pair, not a universal rule.
Specific feedback changed the elbow, not just the numbers
The initial E interpretation treated frames 191 to 213 as a kick. Vincent’s correction was more consequential: the elbow hits the stone. That changed the choreography, release event, and evaluation target. A later review narrowed the Unreal correction again: the strike needed to be short, direct, and violent rather than a sideways hit.
The current Unreal-only correction tightens the guard, adds a brief torso lean, and drives the elbow forward during a 0.10-second strike window. The elbow travels 26.11 cm, with a measured peak speed of 3.58 m/s. About 86% of net displacement is forward. That is a measurable improvement, not a claim of final fidelity. The source torso still contributes lateral motion.
The key distinction from Day 1 remains intact: measurements can make a critique testable, but they do not replace looking at the motion. The E review remains pending human approval.
Two abilities required a reusable boundary
Q and E are separate abilities, not two branches inside one key-driven implementation. Each owns its motion specification, contact and release events, cooldown, props, audio choices, feedback, and comparisons. Shared tooling handles decoding, export, calibrated retargeting, capture, measurements, and presentation.
The test sequence Q → E → Q → E completed two casts per ability, six launches, and zero remaining projectile actors. A shared activation gate prevented overlap while each ability kept its own cooldown and props. Projectile spawning now samples the authored release transform, avoiding a later-frame position that had already moved away from the hand.
This is a development harness, not a finished Gameplay Ability System implementation. Runtime aim and contact IK, damage and stun, exact slab collision, and robust foot contact remain open work.
Automation helps preserve evidence, not approve the result
The ability iteration command separates transfer, timing preparation, native builds, tests, and captures. One E checkpoint recorded about 26 seconds for import and 29 seconds for retargeting. Those are stage measurements, not a promise that an iteration takes under a minute. Debugging and visual review still dominate the uncertain work.
A smaller evaluator experiment produced useful observations at low cost, but repeated judgments and presentation-order changes were inconsistent. It can support review, not automatically approve a run or supply targets without scrutiny. Local measurements establish quantities, stronger reasoning can inspect interpretations, and the final creative decision remains human.
What Day 3 needs to prove
The next work is concrete: reduce E’s remaining sideways travel, fix Q’s arm briefly catching behind the torso, restore reliable foot contact after retargeting, and validate aiming and effects in the playable sandbox. The goal is not to claim a finished combat system. It is to preserve a trustworthy trail from source observation to editable animation to runtime behavior.
Day 1 established a translation layer. Day 2 shows where that layer breaks when it meets a real game rig. That friction is the useful result: it gives the next revision a specific target instead of a vague request to make the animation better.
Explore the tools behind your next experiment
Browse models and compare their documented capabilities on DuckWeights. Hosted chat availability and local downloads are listed separately.
Explore models →Community discussion
Questions, constructive criticism, and your own experiments are welcome. Comments are public. Do not post secrets or proprietary prompts.
Sign in to join the discussionLoading discussion…