A terse, flexible language and runtime for creating and executing visual novels.
We're open to contributions from anyone and everyone. If you'd like to chat with us, feel free to contact us on Discord.
NovelRT and everyone contributing (this includes issues, pull requests, the wiki, Discord in all forms, etc.) must abide by our code of conduct, which can be found here. Instances of abuse, harrassment or otherwise unacceptable behaviour must either be reported to a NovelRT Developer via direct message on Discord or by contacting us via email.
This is a rough synopsis of the project structure as it stands today:
The Fabulist compiler library and frontend, for translating Fabulist files to an intermediate format used by the runtime.
Project documentation, including this readme :)
A not-comprehensive list of examples of Fabulist syntax, used primarily for testing. As the language is fleshed out, there will be more examples added here.
Effectively scratch space, this directory is used for rapid development and prototyping of Fabulist syntax.
The implementation of the Fabulist runtime, in ABI-portable C++.
Samples using the Fabulist compiler or runtime.
Third-party dependencies which are automatically retrieved by CMake.
Before building Fabulist, you need to install some dependencies, and ensure they can be located by CMake
- A C++ compiler supporting C++17 (Debian-derivates:
build-essential) - CMake 3.18 (Debian-derivatives:
cmake)
Compiling Fabulist should be fairly simple, using commands something like this:
mkdir build
cd build
cmake ..
cmake --build . -j
There's no set code style yet, so for now just try to be consistent with the rest of the code.
During the development of NovelRT, we evaluated many options and ultimately decided that none of the existing options completely satisfied our needs:
-
Terseness: Visual novel writers shouldn't feel it necessary to abbreviate character names just to get more of the script in view at once. Additionally, code should not get in the way of the script when it's not necessary.
-
Maintained: Any option chosen should have very few maintenance challenges.
-
Simplicity: The language should be simple to read and write, without remembering the meaning of a bunch of symbols.
-
Standalone: The language and runtime shouldn't be attached to an entire game engine, as that's the job of NovelRT.
These are the options we were aware of before setting out on the task to design our own language, and an explanation of why we felt they did not satisfy our needs.
-
Terseness: It is well known that authors abbreviate their character names because the Ren'Py language is fairly verbose in places. Furthermore, it is regularly the case that code and script are entertwined, causing maintenance and density issues.
-
Maintained: Ren'Py is absolutely maintained.
-
Simplicity: Ren'Py is fairly simple.
-
Standalone: Ren'Py is mostly attached to the Ren'Py engine, and the work necessary to extract it would functionally mean forking the language and making our own anyway.
-
Terseness: Ink is fairly terse, keeping a lot of the script in view at once.
-
Maintained: Ink is questionably maintained, as the developers rarely if ever respond to GitHub issues, or review PRs. As of writing this, there is a PR open that hasn't been merged or closed since 2018. In comparison, the Ink package for Unity was last updated in February 2021.
-
Simplicity: Despite Ink's terseness, there are a lot of special symbols and syntax constructs that need to be remembered.
-
Standalone: While Ink is "standalone" in that the Ink compiler and engine is detached from any game engine in particular, it is functionally tied to Unity as this is the only way it is distributed - and it appears most of the development effort has moved there.
There are many languages used in Twine. However, they have the same basic properties:
-
Terseness: Code is regularly interpolated with script - it appears more like a language designed for developers rather than authors.
-
Maintained: As there are many different syntaxes, it's hard to say if they are maintained. Of the three observed, only two seem to be actively maintained.
-
Simplicity: The fact that there are many languages says a lot; having to decide which language to use and if it will support all the features needed may be overwhelming to beginners.
-
Standalone: Twine's languages appear closely related to the Twine engine, which is purely web/JS-based. It does not look like it would be easy to separate the two.
Copyright (c) 2022 FiniteReality and Contributors.
See License for more information.