# godot-ink wires the ink narrative runtime into a Godot 4 project
> godot-ink is a C# addon that connects the ink narrative engine to Godot Engine 4, installed by dropping an addons folder into the project and importing one props file into the .csproj.
**paulloz/godot-ink** — Ink integration for Godot Engine.
- Repository: https://github.com/paulloz/godot-ink
- Stars: 787 · Forks: 46
- Language: C#
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/paulloz-godot-ink
## A Godot 4 addon that needs a working .NET installation
godot-ink is an integration for the ink narrative language, the project from inkle that lets writers author branching stories in a text format, packaged as a Godot Engine 4 addon written in C#. The scope is narrow on purpose: it does not try to be an ink implementation, it packages the existing one for use inside Godot.
The engine target matters for anyone deciding whether to use it. The README states plainly that this is an integration for Godot Engine 4 and that it targets Godot 4, not earlier versions. The repository is consistent with that: it carries a GodotInk.csproj and a GodotInk.sln, a project.godot file at the root and an addons directory, which is the convention Godot uses for editor plugins and for resources imported by the engine.
The other constraint is the .NET toolchain. The installation instructions assume that you have a working Godot and .NET installation, and they point readers without one to the official engine documentation. That assumption is the dividing line for adoption: a project that already uses the C# version of Godot can follow the guide directly, while a GDScript only project would have to change its language strategy before this addon is usable, since the addon itself is a C# assembly and the .csproj is where it is wired in.
## The install works through an addons folder and one MSBuild import
The mechanism is more concrete than the word plugin usually is. The release archive is extracted at the root of your project, and what appears is a new addons/GodotInk/ folder. That is the Godot convention for a plugin that lives inside a project rather than being installed into the engine itself, and it means the addon travels with the project directory.
The C# side is connected by a single line added to your .csproj, before the closing tag:
```xml
```
This is an MSBuild import, so the props file participates in the project build and the addon assembly becomes available to your C# code. That explains the next instruction in the guide, which is to build the project once: the import is only effective after the project has been compiled, and the GodotInk.props file is the piece that tells the build where the addon code lives.
The final step is to enable GodotInk in your project settings. This is a per project switch, which means the addon can sit in the repository and be switched off while debugging, and it is also a hint about the design: the addon is a set of autoloads or services registered with the engine rather than something you call directly from each scene.
If your project has no .csproj file yet, the guide points to the Create C# Solution button in the editor's Project/Tools menu, which is how Godot 4 scaffolds a C# project.
## Installing godot-ink step by step
The whole installation is four steps, and it assumes nothing more than a Godot 4 project with the C# support in place.
First, download the latest release from the project's releases page and extract the archive at the root of your project, so that a new addons/GodotInk/ folder sits next to your other project folders. Second, add the import line to your .csproj before the closing tag:
```xml
```
Third, build the project once, so that the imported props file takes effect. Fourth, enable GodotInk in your project settings.
Two details are worth planning for. The archive is extracted rather than installed, so there is no package manager step and no version resolver: whatever is in the release archive is what lands in your repository, and it becomes your responsibility to keep it in sync. The second detail is that the guide assumes the .csproj already exists, so a team that has not yet enabled the C# version of Godot has to click Create C# Solution in the editor's Project/Tools menu before the instructions apply.
The README does not describe a rollback, and it does not document how to remove the addon later. Undoing the installation is a matter of removing the import line and the addons/GodotInk/ folder, and disabling the setting, which is easy to do but is your own procedure rather than one the documentation gives.
## Ink files arrive as imported resources through a sidecar .import file
The repository layout shows how ink content is handled. The Examples directory contains TheIntercept.ink alongside TheIntercept.ink.import, and that pairing is the signature of Godot's import pipeline: the .ink file is the source asset, and the sidecar .import file is the record Godot writes so that the engine knows the resource has been imported and what it produced.
That means ink scripts are treated as project resources rather than as loose files that the addon reads at runtime by path. The practical consequence for a team is that an .ink file moved or renamed inside the project directory becomes a change the engine's importer has to notice, and that a story file lives under version control next to the rest of the assets.
The example itself, TheIntercept.ink, is the only story content the repository ships, and it sits under Examples rather than under a demo project, so the repository is a library plus a sample asset rather than a complete playable demonstration. If you want to see the addon working before committing to it, the cost of evaluation is low: drop the release archive into a scratch project, follow the four steps, and point the import at the example story.
What the repository layout does not show is any GDScript side. The primary language of the project is C#, and the addon code and its props file are the integration points. The README does not document a GDScript API surface, so a project written in GDScript should assume the entry point is C#.
## The README documents installation and nothing else
Be clear-eyed about what is available. The README has three sections: a title, a usage section with the installation steps, and a license section. It states that a quick start guide and the general documentation live on the project's wiki, and links to github.com/paulloz/godot-ink/wiki for both.
That split has consequences. The installation path is reproducible from the README alone, but every question that comes up afterwards, such as how a choice is presented in Godot, how a variable is bound to a node, how the ink runtime is stepped, or how ink output maps onto Godot signals, has to be answered on the wiki. A team evaluating the addon therefore evaluates two artefacts: the release archive and the wiki.
The wiki is also the only place a version compatibility statement can be found, since the README does not say which version of the ink runtime is bundled. The repository has no homepage listed either, so there is no dedicated documentation site to cross check. Topics listed on the repository include godot, ink, gdscript, gamedev and game-development, and the .github directory, CODE_OF_CONDUCT.md, CONTRIBUTING.md and AUTHORS.md files show a project with a contribution process rather than a single authored script.
For a narrative library, this thin surface is the main practical risk. Dialogue systems touch saves, translation, testing and timing, and none of that is described in the README.
## Adding the addon versus wiring the ink runtime into your own code
There are two routes to ink inside a Godot 4 project, and they differ in where the work sits.
The first is what godot-ink offers. You add an assembly to the build through a props import, the engine imports .ink files as resources, and the plugin is switched on in project settings. The addon takes care of the runtime plumbing, the resource import and the editor registration.
The second route is to skip the addon and drive the ink runtime from your own code, embedding the runtime as a dependency of your C# project and calling it directly. The difference is where the responsibility lands. Without the addon you own the loading of story files, the mapping between ink output and your own scene graph, and the lifetime of the story object, but you also own every behaviour, so nothing is hidden behind a plugin switch. With the addon, the wiring is done for you and the behaviour is whatever the plugin exposes, which you can only learn from the wiki.
Neither route is obviously wrong. The addon is the sensible default when the goal is a working dialogue flow quickly, and the manual route makes more sense when a project needs ink output shaped in a way the plugin does not offer, or when the team wants to understand the runtime lifecycle directly.
A practical caution applies to both. The addon is C# only, so a GDScript project choosing either route faces the same .NET requirement. Whichever path you take, the ink story files remain plain .ink sources, so the authoring side of your pipeline does not change with the integration choice.
## MIT licensed, last tagged release in February 2024, last push in July 2026
The licence is MIT, stated in the README and recorded in the LICENSE file at the repository root. For a plugin that ships as source inside your project, that means you can include it in a proprietary game without the copyleft obligations of a more restrictive licence, though the licence file has to travel with the code. This is a reading of the licence terms for your own compliance review rather than legal advice, and the LICENSE file is the authoritative text.
The release history shows three tagged versions: v1.1.0 on 2023-09-17, v1.1.1 on 2023-12-09 and v1.1.2 on 2024-02-12. The repository is not archived, and the last push was on 2026-07-04. So there is work landing in the repository after the most recent tag, and if you install by downloading the latest release rather than by tracking the main branch, you are running code that is a couple of years older than the tip of the tree.
That gap is the thing to check first when you upgrade. There is no tag to diff against the last push, so a team moving from the v1.1.2 archive to a recent main branch checkout should read the commit history between those two points and confirm that the addons/GodotInk/GodotInk.props path still exists, since the .csproj import in your own project refers to that exact file and a renamed or moved props file breaks the build with an import error rather than a runtime fault.
## Conclusion
godot-ink is worth adopting if your Godot 4 project already uses C# and your writing team authors in ink, since the addon removes the manual wiring of the runtime and the import metadata. It is the wrong choice for a GDScript only project, because the installation instructions assume a working .NET installation and a .csproj file, and it is the wrong choice for a team that needs a documented API surface today, since the README defers every API detail to an external wiki. Before committing, open the wiki page for your ink workflow, confirm that the release you download contains addons/GodotInk/GodotInk.props for your Godot 4 version, and check that the last push on 2026-07-04 has not left the addon behind the ink runtime version your project depends on.
## FAQ
### How do I install godot-ink in a Godot 4 project?
Download the latest release and extract it at the project root so that an addons/GodotInk/ folder appears, add the props import to your .csproj before the closing tag, build the project once, then enable GodotInk in your project settings. The instructions assume a working Godot and .NET installation.
### What line do I add to my .csproj for godot-ink?
The README gives one MSBuild import line: . It has to go before the closing tag, and the project must be built afterwards for the import to take effect.
### Does godot-ink work with GDScript only projects?
The README does not document a GDScript API surface, and the project is written in C# with a GodotInk.csproj and GodotInk.sln. The installation guide assumes a working .NET installation and a .csproj file, which the editor can create through the Create C# Solution button in the Project/Tools menu.
### Where can I find the godot-ink API documentation?
The README contains only the installation steps and the license note, and it states that the quick start guide and the general documentation live on the project's wiki at github.com/paulloz/godot-ink/wiki. The repository also ships an example story, Examples/TheIntercept.ink, with its Godot import sidecar file.
### What licence is godot-ink released under?
MIT. The README states that GodotInk is released under the MIT license and points to the LICENSE file at the root of the repository for the full terms.
## Sources
- [Issues](https://github.com/paulloz/godot-ink/issues)
- [License: MIT](https://github.com/paulloz/godot-ink/blob/main/LICENSE)
- [paulloz/godot-ink on GitHub](https://github.com/paulloz/godot-ink)
- [README](https://github.com/paulloz/godot-ink/blob/main/README.md)
- [Releases](https://github.com/paulloz/godot-ink/releases)
---
Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/paulloz-godot-ink