The problem
In classic interactive stories you choose between a few pre-written options. With a language model you can write any action, but that creates a different problem: the model tends to forget, contradict itself and make up facts the story never planned.
Parenk aims for a precise balance: players are free to choose their own path, but not to decide on their own what is true.
Context and team
It’s a personal project of mine: concept, design and development. The name comes from the Epicurean parenklisis, the minimal swerve. The design principle is the same: an almost invisible interface, a lot of order and one small deviation.
My contribution
- The concept and the experience design, from the interface to the animation system.
- The narrative engine and the consistency rules.
- Shared real-time experiences and timed ones.
- The Creator Studio for writing new experiences, and the progression path for narrators.
- The infrastructure, the release process and the measurement plan.
Design choices
The AI is not the engine
The model does two things: it interprets the written action into a structured intent, and it writes the prose. Everything else is decided by a deterministic engine: whether the action is valid, what changes in the story state, when an ending is reached. That way the story stays consistent even when a player tries to force it.
Protecting the facts
The story state is reduced to a fingerprint: different paths that lead to the same situation are recognised without asking the model anything. Player claims about facts that are still unknown are detected and handled, and the story’s secret “contract” never reaches the visible text. The model only gets the context it needs, not the whole history.
Multiple providers, costs under control
The engine talks to the models through a single interface, with multiple providers and routing between them. A circuit breaker trips on the first quota errors; each experience has a token budget and every call is logged. Model calls stay outside database transactions.
Lessons from the field
One model configuration produced responses that were truncated or prefixed with the reasoning, and about half of them couldn’t be parsed. Tuning the reasoning level and cleaning up the responses made the format reliable. Testing also surfaced a race between an action and the timer, and a text input that locked up on mobile. Both are fixed.
Real time
Shared experiences use a separate WebSocket service, with presence on Redis. The database remains the single source of truth; a lock on each running experience stops two actions from overlapping.
Outcome and status
Parenk is preparing for testing, with a release process already ready for production. What’s missing is the curated narrative content for launch; the name is also still provisional.