Appearance
Game Engine Plugins
Version 0.1.0 — 2026-08-19. Covers the Godot and Unity plugins at 0.1.0.
Tarinoi publishes two official plugins: one for Godot and one for Unity. They pull authored content out of a Tarinoi project and into your game, walk the dialogue graph, and call into your code. They do not try to be a dialogue system.
Pre-1.0
Both plugins are at 0.1.0. The API is not stable yet, and it will change before 1.0 without a deprecation period. Pin a version, read the changelog before upgrading, and expect to adjust call sites. Until 1.0 we support only the latest engine version listed below.
They are reference implementations
The plugins are MIT licensed, and we mean that in the strongest sense. They are yours to build on, modify, take apart, take inspiration from, and incorporate into your own work — shipped or not, credited or not, under whatever license your game uses.
That is not a fallback for when the plugins fall short. It is the intended use. We wrote them to be read: the traversal logic, the expression evaluation, and the sync layer are all plain, commented code with no framework around them. If you find yourself wanting different behaviour, forking the relevant file is a supported answer, not a defeat.
If you are outside our supported engine versions, or on an engine we do not cover at all, start from Writing your own integration — it documents the data contract the plugins implement, so you can build one that fits your project instead of bending ours.
What they do
| Connect | Authenticate against a Tarinoi project with an API token, or read from a linked Git remote. |
| Sync | Pull documents into a local SQLite database, incrementally. Content lives on the player's machine, not behind a network call at runtime. |
| Expose | Give you typed access to cards, entities, variables, functions, and lists. |
| Traverse | Walk a dialogue graph from a start card: evaluate entry conditions, resolve output selectors, order and filter choices, follow jumps, detect dead ends. |
| Dispatch | Evaluate authored expressions (Fn.combat.RollSkill(...), Var.ferryman.met) against implementations you register. |
| Hook in | Raise events — a line is ready, choices are ready, the dialogue ended — and take advance() and select_choice() back from you. |
| Generate | Emit typed binding stubs from the authored declarations, so a renamed function is a compile error rather than a runtime surprise. |
They are stateless. The runtime holds only the dialogue currently playing. Nothing is retained between dialogues, and nothing is written to disk except the synced content itself.
What they deliberately do not do
Every row here is something we expect you to build. The right-hand column is the seam we give you to build it on.
| Not provided | Build it on |
|---|---|
| A dialogue UI you would ship | line_ready / LineReady, choices_ready / ChoicesReady, dialogue_ended / DialogueEnded. The bundled dialogue strip is a debug view — plain, unstyled, and not meant for players. |
| Save / load, or any persistence | The history store interface, for seen-card tracking. Everything else — variable values, which dialogues have run — is yours. |
| Variable storage or scope | Binding a variable collection. The plugin asks you for a value and hands you a new one; where it lives, and whether it is global, per-scene, or per-save, is your decision. |
| A function library | Binding a function collection. Tarinoi has no opinion about what Fn.combat.RollSkill means. |
| Deciding when dialogue starts | Trigger components that notice and tell you, plus start_dialogue() / StartDialogueAsync() when you decide. |
| Audio playback, camera work, character animation, lip sync | The line event carries the entity and the card payload; drive your own systems from it. |
| Game-ready art | Avatars in Tarinoi are 320×320 authoring aids and media cards are writers' reference images. Neither is a shippable asset — the plugins can place them as placeholders so your artists see what goes where, but your pipeline supplies the real thing. |
| Choice timers, typewriter effects, history logs, skip/auto modes, branching visualisers | All of it. These are game design decisions, and putting our answer in your way would cost you more than it saved. |
On the roadmap
Two things are absent from the plugins today because the platform work comes first, not because we think they belong to your game. Both are planned as core Tarinoi features on our higher paid tiers, targeted for 2027:
| Planned | What it will mean |
|---|---|
| Localization | Authored content translated and delivered per locale, rather than coming down only in the language it was written in. Plugin support will follow the platform feature. |
| Voice-over | VO managed alongside the lines it belongs to, so a plugin can hand your game the audio for a line instead of leaving you to match filenames to card IDs yourself. |
Until then, both are yours to solve: content arrives in the language it was authored in, and the line event gives you the card payload to hang your own VO references on. When these ship, they will arrive as capabilities you opt into — not as weight added to the runtime for projects that do not use them.
What we intend
Minimal and data-focused, on purpose. The plugins connect, sync, traverse, and dispatch. We do not plan to grow them into dialogue frameworks with themed UI kits, portrait systems, or effect libraries. A richer UI layer is not on the roadmap. If that changes, it will arrive as something separate you can ignore, not as weight added to the runtime.
Easy where we can be. If you are on a supported engine and version, we intend the path from install to a line of dialogue on screen to be as short as we can make it — one install, one token, one sync, one scene. That is what the getting-started guides are measured against.
Adaptable where we cannot. If you are outside that, the source is the product. We would rather write a clear data contract and a readable implementation than pretend to support every engine and version combination that exists.
Unopinionated about your game. Tarinoi does not know whether you are making a point-and-click adventure, a strategy game with diplomatic exchanges, or a rhizomatic RPG. The division is: Tarinoi owns authoring and the data contract, the plugin owns traversal and dispatch, and your game owns everything the player actually experiences.
What we commit to
We maintain the plugins and keep them current with their engines, within a reasonable timeframe of a new engine release. When Godot or Unity ships a version that breaks the plugin, fixing it is our job.
We do not have the capacity to maintain plugins for older engine versions. This is a real constraint and we would rather state it plainly than let you discover it in a support thread. If you are pinned to an older engine — as many shipping projects reasonably are — the plugin source is MIT and the data contract is documented precisely so you can maintain a version that suits you.
We keep the data contract documented and versioned. The synced document format is checked against a compatibility version at load time; a plugin that is too old to read current content says so rather than misbehaving.
Connecting to your project
Plugins pull content out of a Tarinoi project into your engine directly — there is no export step. Your content is reachable in one of two ways.
The public API. The plugin authenticates with an API access token and calls the read endpoints directly. This is the simplest path: generate a token, paste it and the project's documents URL into the plugin's settings, and it can pull the latest content on demand. Generate the token from within Tarinoi — app menu → Integrate, or Integrations → API Keys from the hub — where the documents URL is shown alongside it. That document also covers how tokens are scoped and revoked.
A Git remote. The project is linked to a Git repository that Tarinoi keeps in sync on every commit, and a pipeline can clone or pull it directly with no API token at all. This suits pipelines that already work in terms of files and history rather than API calls.
The two are independent and can be used together — a CI pipeline might pull from the Git remote for build automation while an in-editor plugin uses the API for on-demand refresh during development.
If you are unsure, start with the API. It needs no Git setup and is the faster path to a working connection. Move to a Git remote when your pipeline already expects a file-based, versioned checkout, or when you need history rather than current state.
Both official plugins sync over the API, and both store the token outside your project directory so it cannot be committed or shipped in a build. Where the settings live is covered in each engine's guide below. The Git remote is for your own pipelines and integrations — neither official plugin clones a repository.
Supported versions
| Engine | Supported | Distribution | Guide |
|---|---|---|---|
| Godot | Latest stable 4.x only | GitHub release — copy addons/ into your project | Godot plugin |
| Unity | Unity 6 (6000.0) and newer | GitHub — install by Git URL through the Package Manager | Unity plugin |
While the plugins are pre-1.0, support means the latest stable release only — there are no backports to earlier Godot 4.x point releases or to Unity 2022 LTS.
From 1.0 onward the policy becomes the current stable release and the one before it, which gives you a version behind to sit on while you upgrade.
Engines we do not have official plugins for — Unreal, GameMaker, Bevy, LÖVE, your own — are covered by Writing your own integration. We are glad to link to community plugins; tell us about yours.
Where to go next
- Godot plugin — install, configure, and play dialogue in a Godot 4 project.
- Unity plugin — the same, for Unity 6.
- Writing your own integration — the engine-agnostic data contract: document types, expressions, traversal rules.
- Adapting a plugin — how the two implementations are structured, which parts port cleanly, and the mistakes we already made so you do not have to.
- Public API and Git remotes — the two ways a plugin reaches your content, in detail.