VEX: When the Marketing Idea Is Simple and the Code Is Not

The concept took about thirty seconds to explain.

Put a character on the landing page. Make it run around. If a visitor catches it, they get fifty percent off their build. The character is called VEX. He is not cooperative.

That is the entire brief. It fits in a text message. The idea is genuinely good — interactive, funny, memorable, on-brand. The kind of marketing that earns a second look.

What nobody in that thirty-second conversation mentioned was forward kinematics.

What “a character runs around the page” actually means

A character that moves convincingly is not a sprite sliding across a screen. A convincing character has a body. The body has segments. The segments have joints. The joints have rotation. And critically, when the thigh rotates, everything below it — the calf, the foot — moves with it, each in its own local coordinate space.

This is called a bone hierarchy, and building one in HTML is exactly as complicated as it sounds.

VEX has twelve body segments rendered as separate PNG images: upper and lower arms on each side, thighs, calves, feet, torso, belt, and a head that has four different facial expressions depending on what is happening to him. Each segment is a positioned div with a transform-origin set to its joint — not the corner of the element, the joint — because the math falls apart if you get that wrong.

The legs alone have four bones per side: hip → thigh → calf → foot. To animate a walking cycle you need to coordinate eight bones through four phases: contact left, passing right with the knee raised, contact right, passing left with the knee raised. The arm animation runs in counter-phase. The head bobs on the opposite axis from the body lean.

The number of rotation values that need to be coordinated simultaneously for a single convincing walking step, tuned until the foot doesn’t clip through the floor and the knee-raise looks natural and the arm swing is proportional to the stride: that is not a thirty-second conversation.

The thing that was also required

VEX tracks the cursor. His pupils follow the mouse across the room. His ears twitch when you get close. He leans away from the cursor when you’re within a hundred and fifty pixels — a proximity recoil — and leans slightly toward it at mid-distance, out of what can only be described as curiosity.

When you click him in the idle state, there’s a thirty-five percent chance he falls over backwards with his arms out, lies on the ground for a second while he decides how he feels about it, then gets up. The other sixty-five percent of the time, he just gets annoyed and tells you to watch where you’re pointing.

He speaks. He proposes deal terms. He has opinions about the arrangement.

There is also a reaching arm — a separate SVG bezier curve drawn across the full viewport — that originates from VEX’s shoulder position, updates its coordinates in real-time as he moves, and extends a hand toward whichever element he is currently pointing at. Getting the arm coordinates right required understanding that VEX’s position on screen is not the same as his internal coordinate origin, because the bone hierarchy and its nested transforms have already shifted the visual anchor relative to the containing element.

Why a dev background matters

It is not that a developer who understood all of this upfront would have said no. The idea was worth building and the build was completed.

The point is different. A developer reads “interactive character that runs around the page” and has an immediate, accurate sense of what that brief is agreeing to. Not a rough sense. An accurate one. They know before a single line of code is written that the project contains: a bone hierarchy with forward kinematics, a GSAP animation engine with multiple concurrent timelines that need to be killed cleanly before new ones start, a game state machine, a pointer events unification layer for mouse and touch, an SVG arm overlay with real-time coordinate transformation, and a set of expression images that require art direction alongside the code.

A non-developer reads the same brief and sees the concept — which is correct, and good, and worth building. What they cannot see is the implementation surface that sits between the concept and the shipped version.

That gap is not a criticism of anyone. It is a structural feature of creative work. The idea and the build require different kinds of knowledge to evaluate. The dev background is the thing that lets you hold both at once — to see the concept clearly and the implementation honestly, at the same time.

VEX exists. He runs. He evades. He has opinions. He falls over thirty-five percent of the time when you poke him. The thirty-second brief became a full character rig, a game engine, and a state machine with a personality attached.

The lesson is not that the brief was wrong. It is that knowing what the brief actually contains — before you start — is itself a skill. One that takes years of building things to develop. And one that, once you have it, changes every conversation you have about what something “simple” will take.

---

The same gap between concept and implementation exists in every domain TVS works in. The knowledge engineering required to build TKAD is described at TKAD: Engineering a System for the Knowledge AI Cannot Invent. The production complexity behind the market intelligence research is at The Crash Diary.