opensourcegames: a curated catalogue of open source games with build notes

What the inclusion criteria actually are

OSGL, the open source games list, is a list of open source games, game frameworks and game creation tools, and the entry criteria are stated in one paragraph, which is rarer than it should be for a list like this.

The projects are at least in beta stage with a code basis that builds into an executable demo. The code must be under a FOSS licence that allows modification and sharing by others. And for each entry, relevant information is collected regarding code repositories, download possibilities and build instructions.

Those three criteria do a lot of work. The first one excludes a project that exists only as a design document, and the build requirement is the filter that makes the list different from a directory of game repositories. The licence requirement excludes the games that are open source in the source-available sense, which are common in this space.

The consequences for a user are worth spelling out. An entry here is a project you can compile, not a project you can download and run. The build instructions are part of the entry data, which means the list is as much a collection of build documentation as a collection of games.

The repository files reflect that emphasis. There is a template.md, which is the per-entry template, a definitions.md that presumably defines the metadata fields, a developers.md for the people behind the projects, an improvements.md, an inspirations.md, a statistics.md, and an entries/ directory with the content and the generated tables of contents. The primary language of the repository is Python, which is the tooling around the content.

The numbers, and the two ways to slice the catalogue

The README carries an autogenerated content block with the totals, and it is the fastest way to see the shape of the collection.

By kind, there are 1801 games, 48 tools, 66 frameworks and 16 libraries. So the overwhelming majority of what is listed is a game, with a small tail of tooling around them.

By category, the largest buckets are Remake at 706, Action at 357, Strategy at 342, Role playing at 251, Arcade at 222, Game engine at 202, Puzzle at 195, Simulation at 150, Platform at 83, Adventure at 66, Board at 28, Cards at 26, Sports at 28, Music at 18, Library at 16, Educational at 14, Visual novel at 9 and Tool at 48.

Remake being the largest category by a wide margin is the most interesting fact in the list, and it says something about the open source game world. Remakes are projects where a known game is reimplemented from scratch or with the original assets, and they are attractive to hobbyist contributors because the design is known and the work is bounded. A 706-entry category means the community's effort goes into reimplementations far more than into new designs.

By platform, Windows has 651 entries, Linux 600, macOS 346, Web 189, Android 176 and iOS 24. The platform numbers are not mutually exclusive, since a project can target several, but the shape is clear: desktop first, with iOS almost absent at 24.

The autogenerated block is marked with comment markers that say not to edit, and the entries live under entries/tocs/ with one file per category and one per platform. So the categorisation is a multi-axis index over the same entries rather than a set of separate lists, and the table of contents files are generated from the entry metadata rather than maintained by hand.

The stated purpose, which is not just a directory

The background section explains why the project exists, and the reasons are more specific than making a list.

The stated benefits are general information about open source games, the possibility of improving build instructions on the projects side, with the parenthetical that not all projects actually have build instructions, revival of abandoned games that do not build anymore, and conversion of old repository formats like CVS to Git.

Three of those four are about maintenance work rather than about browsing. The build instructions point at the idea that a game that used to build and no longer does is a documentation problem, and the list is a place where that problem can be noticed and fixed. The revival point is the same idea with a stronger outcome, a project brought back to life. And the CVS to Git conversion is a specific, mechanical task that a catalogue with structured repository metadata makes possible, because you can search for entries whose repository URL is dead and whose history needs migrating.

That framing also explains the emphasis on collecting download possibilities and build instructions for each entry. A list of names would be a directory, and directories go stale. A list that records how to build each project is a document that can be corrected, and the statistics and improvement notes are the feedback loop that keeps it honest.

The disclaimer is blunt about the result: no warranty whatsoever of the information presented for any purpose, and there can and will be errors. For a catalogue of volunteer-maintained build instructions, that is the honest statement, and a user should expect to hit a broken instruction and fix it rather than file a complaint.

The licence is deliberately generous, with one carve-out

The licensing is the part of this project that shows the most care, and it is worth reading in full because it does something unusual with the screenshots.

The work is dedicated to the public domain by waiving all rights to the work worldwide under copyright law, including all related and neighbouring rights, to the extent allowed by law. Additionally the content is multi-licensed under the WTFPL, CC-BY-3.0, GFDL 1.3, and given to the public domain wherever it exists and to the maximum possible extent. The stated hope is that this allows everyone to just use the content however they like.

The licence is recorded as CC0-1.0, the public domain dedication, and the multi-licensing is a belt-and-braces arrangement so that a downstream user who prefers a named licence can pick one.

The exception is the screenshots, in the entries/screenshots and docs/screenshots folders. They are taken from the respective projects and scaled down, acting as thumbnails, and their use is considered fair use. For that reason they are excluded from the content licence.

That exception is the detail that shows the author thought about it. Thumbnails of a game's own artwork are not the licence holder's to relicense, so they are carved out and the rest of the repository is given away as completely as a licence can allow. A team that wants to reuse the build instructions in their own tooling can do so without a licence negotiation.

The project also names its alternatives, which is unusual and useful: Open Source Clones, a list of games hosted on GitHub, the Wikipedia list of open-source video games, various Awesome Gaming lists, and the LibreGameWiki.

How the list is maintained and what a contributor does

The README directs contributors to the contribution guidelines, and the repository has a CONTRIBUTING.md, an AGENTS.md, and a code/ directory alongside the content.

The workflow is visible in the structure. template.md is the per-entry template, so every entry follows the same shape, which is what makes the generated tables of contents and the statistics possible. The entries/ directory holds the content and the per-category and per-platform table of contents under entries/tocs/, and the comment markers in the README say the content block is autogenerated and should not be edited, so a contributor edits an entry and a script regenerates the indices.

The content/ code/ split is the one detail to watch. There is a code/ directory at the top level separate from the content directories, which suggests the tooling that fetches and parses the entries is kept apart from the data it processes. With a list this size, and with a statistics.md and a development blog, the tooling is doing real work: gathering the metadata, producing the per-axis indices, and keeping the counts in the README in step with the entries.

For a contributor, the path is: find an entry that is missing or wrong, use template.md as the shape, fill in the repository, download and build instruction fields, and follow the guidelines in CONTRIBUTING.md. The improvements.md file at the top level is where the second class of contribution sits, the notes on what could be improved in existing entries, which is the revival and migration work the background section describes.

The development blog and the statistics page are the two places to look for the state of the project. The blog is on the author's own site under an osgames label, and statistics.md is linked from the README header. The last push was on 2026-10-10, the repository is not archived, and there are no published GitHub releases, which is consistent with a repository whose output is a website rather than a package.

Editorial conclusion

The OSGL list fits someone looking for a playable open source game they can build from source, and it fits a maintainer of a dormant project who wants the build instructions repaired or the repository migrated off CVS. It is a poor fit if you want a game to download and play without a toolchain, because the inclusion bar is a code basis that builds into an executable demo, and a poor fit if you need structured data to query, because the content is Markdown with a generated table of contents rather than a database. Before adding an entry, read the contribution guidelines, and if you are only after a list of games to install, the project names several alternatives including Open Source Clones and the Wikipedia list of open-source video games.

Frequently asked questions

Official sources

1. Issues
2. License: CC0-1.0
3. Project website
4. README
5. Trilarion/opensourcegames on GitHub