Faden.Platform 0.1.0-alpha.2

Faden

Faden is a visual novel engine written in C#, targeting desktop (Windows, Linux, macOS) and mobile (Android, iOS). It supports linear visual novels and sandbox novels through a single storylet based narrative model.

The name is German for thread.

Starting a Game

dotnet tool install --global Faden.Cli
nadel init --name "Rainy Days"
dotnet run

nadel init writes a project file, a first script, the folders of its assets and a program that plays them. The project references the packages Faden.Game and Faden.Build, and the second one carries the build integration together with nadel itself, so nothing else has to be installed to build a game. nadel init --kind sandbox starts a sandbox novel instead, with a world state and a command of its own, and nadel init --engine <path> references a clone of this repository rather than the packages.

Writing a Story

cd editors/vscode
npm install
npm run package
code --install-extension faden-0.1.0.vsix

The extension in editors/vscode starts nadel lsp, the language server of the script language. It is not on the marketplace yet, so it is built from this repository. It underlines what keeps a story from compiling across every script of a project, proposes the nodes, tags, assets, commands and world state a project has, says what a name is and opens the script or the C# file that declares it. It renames a node, a character or a tag everywhere, and offers to mend a name nothing declares. Every other editor that speaks the Language Server Protocol starts the same server with nadel lsp, as described in editing.md.

Status

Milestones one to eighteen are complete. Sprites and text render through SDL_GPU on the Vulkan backend, text is shaped, rasterized and wrapped according to Unicode, and stories compile to bytecode that a virtual machine runs with rollback, saving and loading. Games get a stage with transitions, default screens including a gallery and a music room, localization, and the director, time, locations and schedules that sandbox novels are built from. The toolchain packs assets, checks a story and builds a game, the Webstuhl editor writes and previews one, and a game brings shaders and video of its own. A language server gives an editor the mistakes, the completion and the definitions of a story, and a game adds tags of its own to the markup of its texts. See roadmap.md.

Building

The build compiles the shaders in shaders/ with glslc, which ships with the Vulkan shader toolchain. Point the FadenShaderCompiler property at another path if it is not on the current path. When SDL_shadercross is installed as shadercross, or the FadenShaderCross property points at it, the build also translates them into DXIL for Direct3D 12 and MSL for Metal, which Windows builds that want Direct3D 12 and every macOS and iOS build need. Without it the engine runs on Vulkan only.

Packing a game encodes WAV and FLAC audio when ffmpeg is installed and ASTC textures for phones when astcenc is installed. Both are optional, as described in assets.md.

dotnet build
dotnet test
dotnet run --project samples/Faden.Sample.Desktop
dotnet run --project samples/Faden.Sample.Terminal
dotnet run --project samples/Faden.Sample.Stage
dotnet run --project samples/Faden.Sample.Novel
dotnet run --project samples/Faden.Sample.Sandbox

Building the novel and sandbox samples also builds their asset packs with nadel, the command line tool in src/Faden.Cli. dotnet run --project src/Faden.Cli -- help lists its commands.

Releasing

A tag that starts with v publishes. The workflow in .github/workflows/publish.yml reads the version out of the tag, builds and tests, packs every library together with nadel and Faden.Build, and writes a GitHub release. A tag with a suffix, such as v0.2.0-alpha.1, publishes a prerelease.

Every package is published unlisted: the workflow pushes it and then unlists it, which is what dotnet nuget delete does on nuget.org. A version that is unlisted installs for whoever names it and does not appear in searches or in the version list of the package, which is how these builds stay available without inviting anyone to pick them up.

Pushing to nuget.org uses trusted publishing rather than a long lived key: the workflow asks GitHub for a short lived token, NuGet/login exchanges it for a key that lasts an hour, and the push uses that. What this needs is a trusted publishing policy on nuget.org for the repository owner, the repository and the workflow file publish.yml, and the secret NUGET_USER holding the nuget.org profile name.

Documentation