public_source_engines, a reading list where the code is the point

A repository with no code, only a table of engines

Open the repository and you will find two top level entries, README.md and logos/. That is the entire project. There is no package, no build script, no test suite and no release history. What you get is a Markdown document that points at other people's repositories.

The author describes the intent plainly: a non-exhaustive list of game engines whose source code you can freely inspect, compile, run and learn from. The stated habit behind it is reading other people's solutions to problems, and the author mentions downloading repositories, compiling and tinkering with what other teams have built, including smaller engines alongside the well known ones.

So the unit of value here is the pointer, not the code. For an engineer deciding what to learn from, a hand-curated set with screenshots and direct links saves the work of filtering a search result. It does not tell you which engine is right for a project, and it does not make any claim about quality. Read it as a bookmark file that happens to be organised by how much code you are being asked to swallow.

The author's definition of game engine sets the entry criteria

Most lists of open source graphics work mix renderers, physics libraries and full editors into one bucket. The project explicitly refuses that. The author says that by game engine he means a conglomerate of technologies that generally has an editor, a scene description, and input and output, and that a narrower scope would be a rendering engine or a physics engine instead.

That definition is doing real work. An editor plus a scene description plus input handling is roughly what you need before a game is a game rather than a viewport. It also means the list is deliberately not a list of rendering libraries, so a reader looking for a rasteriser or a solver will not find one here even if the underlying project is public.

The scope caveat is stated up front rather than buried, which is unusual for a community list and makes the boundary easy to check. When you use the index, judge each entry against that definition yourself. If a project only offers the narrow half of the stack, its absence from the list is a scope decision and not a judgement about the code.

Public source is not a licence grant

The second note in the project is the one to read twice. The author points out that he says public source and not open or free or anything that suggests you can arbitrarily make use of the code, and that every entry in the list has its own licensing terms, commercial options or conditions that you need to abide by.

This is the practical difference between a curated list and a package index. Public source means the implementation is visible. It says nothing about whether a commercial product built on it is permitted, whether you may ship it, or whether a royalty applies. The Unreal Engine entry in the team table, for example, points at a GitHub repository under EpicGames, while the CryEngine entry points at a repository named CRYENGINE_ReadMe under CRYTEK, so the rows are not all pointing at the same kind of tree.

The index therefore does not remove the licensing work from a project. It front-loads the discovery step and leaves the terms where they have to be read, on the licence file of the engine you actually want. Any adoption decision still starts there, and the project is explicit that the list carries no permission of its own.

Team engines and solo engines are two different reading lists

The document is split into two tables with different meanings. Team Engines are described as engines being developed by teams of individuals, generally well established and with commercial products behind them. Solo Engines covers engines developed generally by a single individual or at most a handful, and the note says some of those are commercial products while others are often either experimental or toy pieces of tech.

Twenty entries sit in the team table, including Unreal Engine, Godot, CryEngine, The Forge, Torque 3D, Flax Engine, Panda 3D, Armory 3D, NeoAxis Engine, U3D, PlayCanvas Engine, Lumberyard, O3DE, ezEngine, Defold, Cocos Creator, Stride, Dagor, Range Engine and IOLITE Voxel. Six sit in the solo table: Raylib, Wicked Engine, Hazel, Spartan Engine, Pax Engine and Acid Engine.

The split tells you what kind of reading each entry gives you. A team engine with a commercial product behind it is a codebase shaped by an organisation, with layers built for a pipeline and a release cadence. A solo table entry can be a compact, opinionated implementation where a single author's decisions are legible in a way a large codebase never is. Neither is better. They fail differently, and the category heading tells you which one you are about to open.

Every row is a logo, a link and a screenshot

The table format is fixed for each entry: an engine name, a source link, and a screenshot image, with a small logo beside the name. The logos live in the logos/ directory at the repository root, named after the engine with a 64px suffix, and the screenshots are hosted externally, most of them on GitHub raw URLs, some on Steam CDN paths, one on a Wikipedia upload, one on a Twitter image host and one on the Range Engine site.

That gives the document a consistent shape you can scan in seconds, which is its main practical virtue. It also introduces a property to keep in mind: the list is assembled by hand, so it can only be as current as its author's last pass. A row can point at a repository that has since changed ownership, changed licence, been archived or stopped building, and the table itself will not tell you. The project has no GitHub releases and its last push was on 2026-08-23, so freshness is a per link question rather than something the repository guarantees.

Two rows also point at something other than an engine source tree. Range Engine is linked to a rangeengine.github.io repository, and IOLITE Voxel to MissingDeadlines/iolite. Whatever you find there is what the row offers.

There is nothing to install, so the tutorial is reading the index

This project gives no install steps, no configuration and no example code, and the honest tutorial is therefore about how to use the list rather than how to run it.

Start by cloning the repository or opening README.md in a browser, then pick the table that matches your interest: team engines for how a shipping organisation structures a full engine, solo engines for a compact implementation you can hold in your head. From there, open the source link of the entry that interests you, clone that repository, compile it and read the subsystem you care about. That sequence, downloading, compiling and tinkering, is exactly the workflow the author describes doing.

Two practical constraints follow from the format. First, none of the compile steps are provided here, so expect to follow each engine's own build documentation, and note that a team engine may pull in a large dependency graph that you did not intend to take on. Second, if you are using the list to pick a production engine, the index answers none of the operational questions: no version numbers, no support windows, no release notes, none of which a table of links and screenshots can carry.

A single Markdown file with an open question about scope

Maintenance of this project is trivial and that is both its strength and its limit. The last push was on 2026-08-23, the repository is not archived, and the default branch is master. The licence for the list itself is not stated in the project files, so treat the terms of the curated content as unconfirmed.

Because the whole artefact is one file, adding an engine means editing one Markdown table row, adding a logo image to logos/ and linking a screenshot. There is no contribution guide, no code of conduct file and no issue templates in the repository listing, so a new entry follows whatever pattern the existing rows set. That low friction is exactly why the author describes the list as non-exhaustive.

The open question is coverage rather than code. The list deliberately excludes rendering engines and physics engines, and it includes entries whose source link is a readme repository rather than a full tree. Any decision to rely on it should treat it as a starting index that a reader is expected to verify entry by entry, checking the current state and terms of each engine's own repository rather than trusting the row.

Editorial conclusion

Use this repository as a reading list, not as a dependency. It suits a developer who wants to see how a shipping engine solves a specific subsystem and who is willing to read the licence of that engine before copying anything. It does not suit a team that needs a supported engine with an API contract, because the project ships no code, no releases and no support path. Before bookmarking an entry, open its source link and check the licence terms and commercial options listed there, since that is where the project's own caveat points you.

Frequently asked questions

Official sources

1. Issues
2. README
3. redorav/public_source_engines on GitHub