ZQuest Classic is an open source engine for NES-era Zelda-style quests, and it is still shipping weekly prereleases

What it is, and what it is not

ZQuest Classic is described as a free, open source engine for making games similar to the original NES Zelda, and the pitch has two halves: choose from hundreds of quests, or create your own.

That second half is the part that makes it an engine rather than a game. A repository of quests would be a collection. An engine that ships an editor, an asset pipeline and a build system, alongside hundreds of quests built with it, is a development environment with a demonstration attached.

The website is zquestclassic.com, with separate pages for the latest releases, for how to play, and for the web build. There is also a Discord link. The primary language is C++, and the topics name c-plus-plus, game-development, game-engine, open-source and zelda-like.

The framing in the README is worth noticing because it is specific about the reference point. The original NES Zelda is a particular game with particular constraints: a top-down view, grid-based movement, room-to-room transitions, a small colour palette, and a screen that fits in one tile-map viewport. An engine that targets that has a very different job from a general 2D engine, because the target defines what the engine must do and what it can leave out.

The licence is GPLv3, stated plainly with a link to the LICENSE file. The default branch is main, the repository is not archived, and the last push was on 2026-10-20.

The repository layout shows how much is actually in the tree. There is src/ for the engine source, include/ for headers, modules/ for what are presumably optional subsystems, resources/ and resources-extra/ for the game data, third_party/ for vendored dependencies, timidity/ which is the MIDI synthesiser, api_server/ for a server component, vscode-extension/ for an editor extension, web/ for the web build, infra/ for infrastructure definitions, packaging/ for installers, scripts/, tests/, docs/ and docs-www/ for documentation, changelogs/, cmake/ and CMakeLists.txt for the build.

Platforms, and the web build that is still experimental

The support statement is one line and has four parts: Windows, Win7+, OSX, 12+, and Linux. There is also an experimental web version that can also be played on mobile devices.

The word experimental on the web build is doing real work in that sentence. A web build of a game engine is a much harder proposition than a desktop one, because the engine is a C++ program and a browser sandbox is not a place where a C++ program runs. Whatever approach is being used to get the engine into the browser, it is not the same arrangement as the desktop builds, and the README is clear that it is the least settled part of the project.

The mobile point is worth separating out. The web version can be played on mobile devices, which means the games themselves are playable on a phone browser, which is a considerably more useful capability than an editor in a browser. For a quest format that is compact, tile-based and keyboard-driven, that is a plausible delivery route.

The Windows 7 and macOS 12 floors are also informative. Windows 7 is a very old baseline, which suggests the engine still builds and runs on older toolchains and that the project does not push its users toward a recent compiler. macOS 12 is more recent but still several years back at the time of writing. Both are the sort of floor that comes from supporting a range of build environments rather than from a deliberate policy, but either way they mean the build instructions in docs/building.md are the thing to read rather than anything you can infer.

The images section of the README shows what the project actually produces. There is a screenshot labelled Editor, and then three quest screenshots: Joel's SOTW 785, Twilight Knight's SOTW 778 and Architect Abdiel's SOTW 793. SOTW is the quest of the week, and the numbering is in the high seven hundreds, which is a useful measure of the scale of the community output. Three different quest authors, three different visual styles, which is what an engine with a permissive licence and an asset pipeline produces.

The release cadence, and why the version numbers are unusual

The release naming is the first thing a potential user will notice, and it is worth understanding rather than guessing at.

The recent releases are 3.0.0-prerelease.230+2026-10-18, 3.0.0-prerelease.229+2026-10-13 and 3.0.0-prerelease.228+2026-10-11. Read that as a base version, a prerelease marker, a build counter and a build date.

The build counter is what matters. It went from 228 to 229 to 230, and the dates run 2026-10-11, 2026-10-13 and 2026-10-18. So the project is producing a numbered prerelease roughly every two days and a half, with the numbers incrementing on each one. The 3.0.0 base has not been released as final.

That is a coherent scheme for a project in a long prerelease phase, and it gives users something a plain nightly tag would not: an ordered list of builds where you can tell exactly which one you have and whether it is newer than another. The counter is the ordering key and the date is the human-readable part.

The practical consequence is that there is no stable version to pin. A project that depends on ZQuest Classic as a library or as a build target has nothing to say in its own dependency manifest other than a specific prerelease build, and that is a real cost for anything long-lived. For the majority of users, who download a quest and play it, the cadence is a benefit: a fix to an engine bug reaches every player within days rather than waiting for a release cycle.

The releases are distributed through the project's own website rather than through GitHub Releases, since the README links zquestclassic.com/releases/ as the latest releases page. That is a normal choice for a game project that wants to serve a built artifact rather than a source tarball.

The changelogs/ directory at the repository root suggests the changes are tracked in files rather than only in commit messages, which is the sort of thing that matters when the release notes live on the website.

The repository as a working example of a C++ project with modern tooling

The top-level entries are worth reading as a description of how the project is organised, because a game engine repository is usually a mix of very old code and very new tooling.

The build is CMake, with a CMakeLists.txt at the root and a cmake/ directory for the modules. The docs are two directories, docs/ and docs-www/, which suggests two audiences: developer documentation and the user-facing website documentation. And the Python side is substantial, with a pyproject.toml, a requirements.txt, an api_server/ directory and a scripts/ directory.

The requirements.txt reveals what the Python is for. It includes Sphinx 8.1.3 and sphinxcontrib extensions for documentation, pydata-sphinx-theme for the theme, myst-parser for Markdown notebooks, and rinohtype with four rinoh-typeface packages, which is a Python-based PDF typesetting engine. So a large part of the Python dependency set exists to produce documentation, including printable PDFs.

Beyond that there is a documentation and tooling stack with some heavier pieces: PyGithub for working with the GitHub API, likely for the changelog or release tooling, discord.py for the community bot, Flask and aiohttp for the API server, boto3 for object storage, PyJWT and PyNaCl for signing, lxml and beautifulsoup4 for HTML processing, pytest for the tests, gcovr for coverage, and cutie and readchar for terminal interaction. The presence of PyJWT and PyNaCl together is a hint that the project signs something, plausibly the downloads.

The pyproject.toml is small and only configures formatting, with skip-string-normalization for Black and the isort profile set to black with a line between types and combined as imports. So the C++ codebase is not formatted by clang-format but the Python is, and the two tools are kept consistent with each other.

There is a codecov.yml at the root, a .git-blame-ignore-ignore-revs file, which is the mechanism for excluding large formatting commits from the blame of a file, and a .mailmap. Those two are small details that say a lot: a project that excludes formatting commits from blame has had a formatting sweep, and a project with a mailmap has had contributors change their names or addresses.

The top-level entries also include an AGENTS.md file and a .claude/ directory, plus a .vscode/ directory and a separate vscode-extension/ directory, so the repository carries both instructions for AI coding tools and a first-class editor extension.

Where ZQuest Classic is the wrong choice

Three limits, and the first is about the size of the commitment.

The first is the size of the engine you are adopting. This is a full game engine with an editor, an asset pipeline, a MIDI synthesiser bundled in, a packaging directory for installers, a web build, a VS Code extension and an API server. Adopting it as a base for your own game means working inside that structure rather than picking a few pieces from it, and the GPLv3 licence means the result has to carry that licence.

The second is the licensing constraint for a commercial project. GPLv3 is not unusual for a game engine and it is not a problem for a hobbyist or for an open-source game, but it is a serious constraint for a closed-source commercial title built on this engine, and the README states the licence without any dual-licensing offer. The alternative, if you want a proprietary game, is to write your own engine or to use one with a permissive licence, and the cost of that is the whole pipeline the ZQuest Classic team maintains for you.

The third is the absence of a stable release, which for a game engine is worse than it is for a library. If you are building a game on this engine and something breaks in prerelease build 231, you have no stable version to fall back to. The counter-based scheme gives you ordering, which is valuable, but it also tells you that every version is provisional. For a player downloading a quest, that is fine. For a studio shipping a title, it is a problem you would solve by pinning a build and freezing your own release around it, which means you are maintaining a fork of the engine's dependency set.

The alternative approach for making a Zelda-style game is to use a general 2D engine with a tilemap system, which gives you a supported stable release, a documentation ecosystem and, in the commercial cases, a licence that permits a proprietary title. The difference in approach is that ZQuest Classic gives you a specific and battle-tested answer to the exact problem of an NES-style quest, with hundreds of examples of what the answer looks like and an editor tuned for it, while a general engine gives you a wider toolset and a vendor behind it. If your project is one more room-and-puzzle quest in that idiom, the specificity is worth a great deal. If it needs anything outside that idiom, the general engine will be less work.

Editorial conclusion

Adopt ZQuest Classic if you want to make a Zelda-style quest or want to read how a mature 2D engine is put together, because the repository carries the engine, the editor, the assets, the packaging and the community process side by side. Do not adopt it if you need a stable tagged release, because the recent releases are all 3.0.0-prerelease builds with a build number and a date, so there is no version string to pin against a long-lived project. Verify first that the platform you want is supported, since the README states Windows 7 and later, macOS 12 and later and Linux with the web version marked experimental, that you read docs/building.md before attempting a build, and that you read docs/ai.md if you plan to use AI tooling on the project, since the repository points at it specifically for that question.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. ZQuestClassic/ZQuestClassic on GitHub