About

Why HumanCodeable exists

Every real-time project rebuilds the same layer. Someone writes grabbing. Someone writes a menu that works in VR and on a monitor. Someone writes teleport, and highlighting, and a settings screen, and the plumbing that makes any of it replicate. It takes months, it is rarely the interesting part of the project, and the result is usually tied to one platform and one team's assumptions.

HumanCodeable builds that layer properly, once, so it can be reused. The design goal throughout is that content should not know what kind of player is interacting with it. An object declares what may be done to it; the player's abilities decide how. That single decision is what makes a VR project, a desktop build and a mobile version the same project rather than three.

How we build

Readable over clever. The framework is almost entirely Blueprint because our customers need to read it, extend it and debug it. C++ appears only where Blueprint genuinely cannot reach — hand tracking, the net driver, editor tooling.

Modular, with real boundaries. 42 plugins with dependencies that point one direction. You can take the interaction system without the UI, or the UI without the interaction system.

Documented as a product, not as an afterthought. Concepts, workflows and a per-plugin reference, generated from the source so it cannot silently drift.

Extension points, not forks. Where behaviour needs to differ, there is an interface to implement or a class to subclass. Customers should never need to modify the framework itself, because that is what makes updates painless.

Who it is for

Studios and independent developers building architectural visualisation, product configurators, training and simulation, and any real-time project that has to reach more than one kind of device.