arewegameyet: a hand-curated map of the Rust gamedev ecosystem

A catalogue of the Rust game development ecosystem, kept by hand

arewegameyet.rs tracks the state of the Rust ecosystem for game development. The README frames it as one of several community sites with the same purpose for different domains, naming arewewebyet.org for web development and arewelearningyet.com for learning as the sibling projects, and this one covers the game development corner.

The audience is broad. A Rust programmer deciding whether an engine or a rendering library exists at all reads it as a directory. A person picking between two candidate crates reads it as a shortlist. A maintainer of a game project reads it as a place to add their own work, and the README asks contributors to add themselves to USERS.md if they are using the project, and invites people who are evaluating it to open a discussion.

What the site is not is a package index. There is no version number in a typical entry, no download counter, and no indication of whether a listed project still builds. The value is discovery and description, and the cost of that choice is that accuracy depends on somebody remembering to update a file.

Each entry is a data.toml file inside a category folder

The data model is the interesting part of this repository, and it is deliberately dull. The top level of the repository contains a config.toml for the Zola site, a content directory, sass for the styles, static for assets, templates for the Zola templates, and a sort_data.py script. The README describes the contribution flow in three steps: navigate to the folder in /content that best fits your project, edit that folder's data.toml file in a plain text editor or through the GitHub editor, and create a new entry following the documented schema.

So the catalogue is not a database and not a build-time scraper of an external API. It is a set of TOML documents, grouped by category, that Zola renders. Each folder in content holds a data.toml with a list of item tables, and the site template reads that list. A record is added by appending a table to the file, and a record is corrected by editing one.

That structure has a direct consequence for a reader of the repository. A diff in content shows exactly what changed in a catalogue entry, and a pull request that adds a project touches a file rather than a database row. The same structure means the data can be reviewed in the same place it is written.

The item schema: two mandatory keys and a set of optional ones

The README documents the schema as a commented TOML template, and the comments mark clearly which fields matter. The name of the item is mandatory, and the categories the item should be assigned to are also mandatory. Everything else is optional, though a description is called strongly recommended, as is an image, with the comment noting that images are highly recommended for games.

[[items]]
name = "My crate" 
description = "My extremely cool Rust crate" 
categories = ["2drendering", "engines"]
image = "/assets/img/logo.png"
crate_url = "https://crates.io/crates/mycrate"
repository_url = "https://github.com/username/repo"
homepage_url = "https://mycrate.com"

Images are files checked in under /static/assets/img/, and the image path in the entry is absolute, starting with a slash. The link fields are separate rather than nested, so a crate can have a crates.io page, a VCS repository and a homepage without any of them being derived from another. The schema also has a gitter_url field for a chat link, which is one of the older entries in the template and one of the few fields in it that a modern entry is likely to leave empty.

External sources let Crates.io and GitHub fill the record in

A record does not have to spell everything out. The README shows a second form of entry where the site pulls data from an external source, using a source key alongside the name and the categories.

[[items]]
name = "mycratename"
source = "crates"
categories = ["mycategory"]

[[items]]
name = "username/repo"
source = "github"
categories = ["mycategory"]

The two forms differ in how much you write. A crates sourced entry names the crate and the categories, and the site fetches the rest from crates.io. A github sourced entry uses the owner and repository name as the identifier, and the site fetches from GitHub. The README also states that extra keys can be added to items pulled from external data, for example to add a homepage URL or to override some of the fetched values.

That last point is the practical one. A fetched record is not read only, since you can still attach a description or a logo to it, but the fetched fields are only as current as the build that rendered them. The naming convention also differs between the two forms, because a GitHub source is a slash separated path while a crates source is a bare crate name, and that difference has to be right for the fetch to resolve.

A CI check enforces alphabetical order, and sort_data.py fixes it

The contribution guide has one strict rule that is easy to trip over: all entries should be sorted alphabetically by the name field, ignoring case. The README says there is a CI check to ensure this is done correctly, and it names a script, sort_data.py, that can be used to automatically fix a file.

That is a small design decision with a large practical effect. A hand-curated list in one file per category is only reviewable if it stays ordered, otherwise every addition produces a diff that moves the surrounding lines and the reviewer has to look for the actual change. The alphabetical rule keeps each pull request to a single insertion, and the script exists so that a contributor who gets the order wrong does not have to sort the file by hand.

The script lives at the top level of the repository rather than in a tools directory, and the Makefile style tooling is not part of this project. Contributors are also told that if they are not comfortable with the process, they can open an issue requesting the addition of their project instead, which makes the review burden on the maintainers rather than on the contributor.

Styling is semantic-ui and the generator is Zola

The site itself is a static site generated by Zola, the Rust static site generator, and the README notes that Zola is integrated into the rust compiler toolchain, which makes the build a matter of running a tool that is already part of a Rust development machine. The styles come from semantic-ui, a CSS framework, and the sass directory in the repository holds the stylesheets.

A person who wants to work on the site itself is a different audience from a person adding an entry. The README asks that person to be comfortable with semantic-ui and Zola and to reach out through Issues with enhancement ideas, or to state a willingness to contribute. That is a narrow request, and it reflects a real property of the project: the data is decoupled from the presentation, so most contributions never touch the templates or the styles.

The templates directory holds the Zola templates, and the static directory holds the assets including the images referenced by entries. The repository topics list zola, which matches the toolchain the README describes. Nothing in the README documents a build command, a local preview server, or a deployment pipeline, so a contributor who wants to see the site rendered locally has to work that out from the Zola documentation rather than from this repository.

A static snapshot with no releases and a CC-BY-4.0 licence

The repository is licensed under CC-BY-4.0, which is a content licence rather than a software licence, and that choice fits a project whose main output is text. It also means the catalogue entries in the content directory are covered by that licence, so a project described there is described under terms that require attribution for reuse, and a maintainer thinking about copying an entry into their own site should look at the LICENSE file first. This is not legal advice, it is a reading of what the licence file covers.

On maintenance, the last push was on 2026-10-19, so the repository is receiving changes. The repository has no GitHub releases, which is normal for a site that deploys continuously from the default branch, master, but it also means there is no published snapshot of the catalogue that a reader can pin to. The state of the ecosystem on any given day is the state of the master branch at that moment, and the history of the site is the commit history rather than a release list.

The other limitation worth stating plainly is the one the project accepts in the README itself: "It's very likely there are mistakes around, if find one please file an issue." A hand-edited catalogue of third party projects accumulates stale entries, and the correction path is an issue rather than an automated check.

Editorial conclusion

arewegameyet earns a place in a Rust gamedev team's reading list, and it is the wrong tool for anyone who needs to install a crate, judge a release, or check whether a project still compiles, because the site records descriptions and links rather than versions or health. Before relying on it, open the data.toml file for the project you care about and confirm that the description, categories and links are still current, since each record is edited by hand and the site has no GitHub releases to mark a snapshot of what was true.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-4.0
3. Project website
4. README
5. rust-gamedev/arewegameyet on GitHub