# The Escoria demo game is the framework's test bed, not a standalone game

> escoria-demo-game is a Godot project that exercises the Escoria point and click framework, and it doubles as the reference implementation for the framework's data driven script format. It is MIT licensed, ships with third party art and fonts that carry their own terms, and its releases track a framework still in beta.

**godot-escoria/escoria-demo-game** — Game example for the point'n'click adventure framework Escoria

- Repository: https://github.com/godot-escoria/escoria-demo-game
- Stars: 855 · Forks: 132
- Language: GDScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/godot-escoria-escoria-demo-game

## A testing ground for the framework, not a finished adventure

escoria-demo-game is described as the demo game that acts as a testing ground for future Escoria development and as a general demonstration of the framework's features. That framing tells you how to read the repository. The adventure inside it is a vehicle, and the interesting content is the machinery the framework provides.

Escoria itself is described as a libre framework for creating point and click adventure games with the Godot Engine, and the README points to the Escoria documentation, specifically the Getting Started Guide, for further details. Contribution to the framework itself happens in a separate organisation, with contribution guidelines in the godot-escoria/.github repository. The demo game and the framework are separate projects that move together, which is why the demo is where new framework work gets exercised.

The primary language of the repository is GDScript, and the top level tree shows the shape of a Godot project with the Escoria core under addons/, the game content under game/, tools, saves, and a set of framework specific configuration files at the root.

## Escoria switches esc_item.gd for you between Godot 4.6 and 4.7

The one piece of real engineering in the README concerns Godot Engine versions. Escoria is meant to work with both Godot Engine 4.6.x and 4.7.x, but API changes between those versions that Escoria uses force a tweak in a single script, located at res://addons/escoria-core/game/core-scripts/esc_item.gd.

The mechanism is a launch time check. Escoria detects on launch whether that script needs to be replaced with the version matching the Godot Engine you are running, and it does the swap for you. The two variants differ in one method, _get_configuration_warnings(), which returns the scene warnings in a different shape depending on the engine version.

```gdscript
return "\n".join(_scene_warnings)
```

That is the 4.6 form. On 4.7 the method returns the warnings list directly.

```gdscript
return _scene_warnings
```

The README also warns about the edge case. If you have modified these files in your own build of Escoria, the automatic replacement may not give you what you want, and you may need to apply the change yourself. In practice that means a fork of the framework needs a manual step after every upgrade, and the demo game alone cannot tell you which variant you should keep.

This is the sharpest illustration of the framework's central constraint: Escoria is coupled to specific Godot releases, and the coupling is expressed as a patch to a file inside the addons directory.

## The tree shows a data driven adventure: .esc files, a wizard config and export presets

The root of the repository is more informative than the prose. There is action_defaults.esc, which by name holds the default actions available to the adventure script, and default_env.tres, a Godot resource for the default environment. There is project.godot and export_presets.cfg for building the project, and escoria-wizard.conf, a configuration file for the Escoria wizard, the tool that helps set a project up.

The remaining files tell you how the project is maintained. A .gdlintrc configures the GDScript linter, and the tools/ directory holds that linting setup. A .release-it.cjs script drives release automation, which matches the tagged releases the repository publishes. build_escoria_docs.sh builds the documentation, and CHANGELOG.md tracks what changed. TESTING.md describes how the demo is exercised, which is the other half of its role as a test bed. A saves/ directory is where save game data lives, and the .tmp directory suggests scratch space used by tooling.

Taken together, this is a project that expects to be opened in the Godot editor rather than run from a command line. There is no binary in the tree and no documented headless command, so the demo is something you open, play and edit.

## Running the demo means opening it in Godot and reading the getting started guide

There is no installation script in this repository, and the README does not give a command line for building or running the demo. The path the documentation points to is the Escoria documentation site and its Getting Started Guide, which covers installation and setup for the framework, with this project serving as the example you look at afterwards.

Practically, the flow is a Godot flow. You clone the repository, open the project in the Godot Engine version you intend to use, and the Escoria addons under addons/ are what supply the adventure commands to the game content. The export_presets.cfg file is there for producing a build once the project is set up the way you want it.

Two things to expect on the first run. The first is the version check described above, which may rewrite esc_item.gd in your working copy the moment the project starts. The second is that the demo and the framework have to match: the code under addons/ is the framework itself, and mixing a demo written against one Escoria version with a different framework checkout is the kind of mismatch that produces confusing errors rather than clear ones.

Because the project is public and MIT licensed, you can also treat the demo purely as a reading exercise, opening the .esc files and the game scripts to see how a room, an item and an interaction are wired together.

## The MIT code licence does not cover the art, the sounds or the fonts

The repository itself is MIT licensed, and the README is careful about the rest of what ships with it. That care is worth reading closely, because the assets carry terms that differ from one another.

Most of the art is CC0. Mark, the character spritesheet, is by Marco Giorgini under a CC0 licence with talk animations added by Julian Murgia, and the worker spritesheet is based on it. The generic items and the animal pack redux are by Kenney, also CC0. The cursor pointers are by yd, CC0, edited by Julian Murgia. Most of the sound effects are CC0 as well, including the concrete footstep from Kenney and the ambient bird sounds.

Two sounds are not. Game Menu Looping and Mystical Ocean Puzzle Game, the latter by Eric Matyas, are under CC-BY 4.0, which means attribution is required if you redistribute them.

The fonts carry the most restrictive terms. Caslon Antique is free for personal and commercial use, and Onesize is free for personal use only. The README says plainly that these fonts are provided as an example and that you should check the licence before redistributing with your game. One size is the font used in The Secret of Monkey Island and Monkey Island 2, and Caslon Antique is the one used in Curse of Monkey Island.

So the code is permissive, the bulk of the art is public domain, and the fonts and two music tracks are not. Anyone shipping a commercial game built on this demo inherits that distinction, and the README is the only place it is written down.

## Releases track a framework that is still in beta

The tag history shows where the framework stands. The newest release is v4.0.0-beta.2 dated 2026-08-18, before v4.0.0-beta.1 on 2026-03-08 and v4.0.0-alpha.319 on 2026-03-01. The last push to the repository was on 2026-10-19, so the tree moves faster than the tags, which is the usual pattern for a framework that tags milestones rather than every change.

Beta status has a concrete meaning for anyone building on this. Interface changes between beta versions are likely, and the Escoria addons live inside the project itself, so a framework upgrade is a source level change in your game project rather than a dependency bump you can defer.

The repository layout also suggests where the real work of verifying the framework happens. TESTING.md at the root, plus the changelog and the release automation script, means the demo is expected to be exercised and kept honest. That is a positive sign for a project whose purpose is to be a test bed, and it is also a signal that you should expect the demo project layout to shift between versions.

For licensing, the MIT terms on the code are straightforward, and the asset licences described above are the part to take seriously.

## When a framework demo is the wrong foundation for your game

The alternative approach is to build the adventure directly in GDScript in Godot, with your own scene system and your own interaction code. The difference in approach is fundamental. Escoria moves the adventure logic into data: actions, conditions and dialogue live in .esc files that the framework interprets, so a designer changes content without touching engine code. Hand written GDScript keeps logic in code, which is more verbose to author and far easier to debug with the engine's own tools.

The cost of the data driven route is the dependency on the framework's interpretation rules and its coupling to specific Godot versions, which is exactly what the esc_item.gd patch is about. If your project needs a control scheme, an interaction model or a scene structure that Escoria does not model, you will end up writing custom GDScript inside the framework anyway, and you inherit both systems.

This demo is also not a good starting point if you want a shipped game rather than a learning example. It contains no distribution pipeline beyond export_presets.cfg, no localisation setup and no difficulty or progression design. It is a test bed first.

Where it does earn its place is as a working reference. A developer evaluating Escoria can open a complete project, see how a room script, an item and an action default are put together, and then judge whether that model matches the adventure they want to ship.

## Conclusion

escoria-demo-game is the right starting point for a developer who wants to see how the Escoria framework expresses a point and click adventure in data rather than in GDScript, and for a Godot user who wants a complete project that opens and runs. It is not a foundation to fork for a commercial game without reading the asset licences, because the bundled fonts include one licensed for personal use only and the sound set includes CC-BY 4.0 tracks that require attribution. Before building on it, note that Escoria targets Godot Engine 4.6.x and 4.7.x, that esc_item.gd is patched on launch depending on your Godot version, and that the newest framework tag is v4.0.0-beta.2 dated 2026-08-18.

## FAQ

### What is escoria-demo-game used for?

The README describes it as the demo game that acts as a testing ground for future Escoria development and a general demonstration of the framework's features. Escoria itself is a framework for point and click adventure games built with the Godot Engine.

### Which Godot Engine versions does Escoria support?

Escoria is meant to work with both Godot Engine 4.6.x and 4.7.x. Because of API changes between those versions, Escoria detects on launch whether res://addons/escoria-core/game/core-scripts/esc_item.gd needs to be replaced with the version for your engine.

### Can I use the art, sounds and fonts from the Escoria demo in my own game?

Most of the art and many sounds are CC0, but Game Menu Looping and Mystical Ocean Puzzle Game are CC-BY 4.0, the Onesize font is free for personal use only, and Caslon Antique is free for personal and commercial use. The README asks you to check each licence before redistributing the assets with your game.

### How do I run the Escoria demo game?

The README gives no install or run command and points to the Escoria documentation and its Getting Started Guide instead. The project is a standard Godot project with project.godot at the root, so you open it in the Godot Engine and use export_presets.cfg to build it.

### What is the latest release of escoria-demo-game?

The newest tag is v4.0.0-beta.2 dated 2026-08-18, before v4.0.0-beta.1 on 2026-03-08 and v4.0.0-alpha.319 on 2026-03-01. The last push to the repository was on 2026-10-19, so the tree moves ahead of the tagged releases.

## Sources

- [godot-escoria/escoria-demo-game on GitHub](https://github.com/godot-escoria/escoria-demo-game)
- [Issues](https://github.com/godot-escoria/escoria-demo-game/issues)
- [License: MIT](https://github.com/godot-escoria/escoria-demo-game/blob/main/LICENSE)
- [README](https://github.com/godot-escoria/escoria-demo-game/blob/main/README.md)
- [Releases](https://github.com/godot-escoria/escoria-demo-game/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/godot-escoria-escoria-demo-game