Things people play with.
Playable brand pieces, configurators, toys and interactive explainers — built in a browser and shipped as a link. No install, no app store, no separate build.
Interaction is in the graph, not bolted on afterwards.
Input is part of the graph
Pointer, touch, keyboard, gamepad and hit-testing are operators you wire straight to what they drive. They are not a scripting layer bolted on at the end, so a drag can move a camera, a colour and a sound at once — and you can see the wire that does it.
State machines hold the logic
What the piece is doing now, and what moves it somewhere else, is a visible graph: title, playing, won, retry. You read the behaviour off the canvas instead of untangling conditionals, and you change it by moving a wire.
Real-time 3D and physics
Geometry, materials and rigid-body simulation cook every frame. Things fall, collide and settle because the piece is genuinely computing, not replaying a recording — so it responds to whatever the person does rather than the path you anticipated.
It ships as a link
No install, no store review, no native build. Someone opens a URL on a phone and is playing. And a piece that never uses 3D carries no 3D payload at all, so a small toy stays small.
Change it after it is live
It is a graph, not a build. Tune a number — difficulty, colour, timing — and the thing people are using is updated. No recompile, no resubmission, no waiting on a release window.
Same idea, two shapes.
Today
An interactive idea gets mocked up flat, then rebuilt for real by a developer in a different language on a different timeline — and the two drift. What was approved and what gets shipped stop being the same thing, and nobody notices until it is live.
With nooodles
The thing you designed is the thing that ships, because the document, the interaction and the 3D are all in the same graph. There is no second build to fall out of step with the first.
The same graph makes the campaign around the piece.
The piece itself is a scene — something a player opens and uses. But everything that points at it is a workflow: the stills, the cutdowns, the store and press art your team places across channels.
Both come out of one graph, so the promo shows the real thing. Change the colourway in the playable piece and the key art changes with it — because it was rendered from the same nodes, not recreated by hand in a second file.
The playable piece
A live interactive experience at a URL — you touch it, it responds, it runs on the phone in your hand.
- Mode
- Scene
- Who opens it
- Your players
The campaign around it
Stills, cutdowns, store and press art — flat files your team places wherever the piece is promoted.
- Mode
- Workflow
- Who opens it
- You and your team
Start from something that already works.
These ship with the beta — you will open them, run them, or take them apart. You never start from a blank graph.
Product Configurator
SceneSpin it, swap it, configure it, in the browser.
by Jacques ParysPlayable Piece
SceneA small branded game someone can finish in a minute.
by Jacques ParysScroll Story
SceneDrive a 3D narrative from scroll.
by Jacques ParysFrame Extractor
WorkflowPull graded stills and cutdowns out of the live piece.
by Jacques ParysWhat people ask first.
Do I need to know how to code?
No. You build by wiring nodes and setting values, and you start from a Recipe rather than a blank graph. The assistant wires much of it for you — describe what should happen when someone taps, and it makes the connection. If you can lay out a design, you can build one of these.
How complex a game can this actually make?
Short-form: playable pieces, configurators, toys, interactive explainers — the kind of thing someone finishes in a minute or two. It is not for building a forty-hour title, and we would rather say so plainly than let you find out three weeks in. If the brief is a brand piece, a product experience or a demo, it fits.
Does it work on phones?
Yes — that is the normal case. It runs in the mobile browser, with touch, tilt and multi-touch treated as ordinary inputs. Layout responds to the screen it is given, and a piece only carries the payload it actually uses, so it loads on a phone connection rather than only on office wifi.
Can it save player progress or scores?
Yes. State can persist on the player's device for a returning visit, or go to a service you already run for a shared leaderboard. You wire where it is stored the same way you wire anything else, and you decide what is kept — which matters if the piece is collecting anything about the person playing.
Can we embed it in an existing site?
Yes. It is a web page, so it can live on its own URL or sit inside a page you already have. Your team publishes a link and drops it in — nothing needs to be rebuilt to fit whatever the site is made with.
Build the thing people play with.
Free to start, nothing to install. Or tell us about the piece you have in mind and we'll walk you through it with your own work.
Working with a team?
Tell us where to reach you and we'll set up a walkthrough.
No spam. A real reply from a human.