bevy-assets: the community directory behind the Bevy ecosystem

bevy-assets is a catalogue, not a crate

The first thing to get straight is what this repository is. It contains no Rust code and no library you can depend on. It is a collection of Bevy assets, plugins, learning resources and apps made by the community, and the way they are stored is as one toml file per entry.

That design is the whole idea. A registry of extensions for a game engine tends to fragment across a package index, a forum thread and a chat channel, and a newcomer has no single place to look. This repository provides that place and gives it a shape, and the site renders it.

The consequence for a reader is that the information here is deliberately thin. A single toml file names an asset, gives it one sentence, and points at where the real project lives. Nothing about the code, the API or the compatibility is duplicated here, which means the directory cannot go stale in the way a mirror of package metadata would, and it also means it cannot answer the questions you actually have when choosing a dependency.

The audience is therefore a developer in the middle of a project, looking for something that already exists, and a creator who wants their work listed. The project description invites submissions directly: submit a pull request, and feel free to create new categories where it makes sense.

One toml file per entry, with an optional icon

The entry format is documented in the project description and it is worth reading in full, because the fields are constrained and each constraint is a design decision.

# Name of your asset.
name = "My Cool Plugin"

# Description of your asset. It should be less than 100 characters and not contain formatting.
description = "A short and sweet description of My Cool Plugin"

# Where can your asset be found. It can be a link to crates.io, github, gitlab or similar.
link = "https://github.com/me/my_plugin"

# Optional image to showcase your asset.
# Should be a png/jpg/gif/webp located next to your toml file, less than 2 MB in size.
# We recommend using a 16:9 aspect ratio with a maximum width of 600 pixels.
image = "my_plugin_icon.png"

# Optional crate name on crates.io. If there's more than one crate, pick any one of them.
crate = "my_plugin"

The `name` and `description` are required, and the description has a hard limit of under 100 characters with no formatting. That limit is what makes the listing uniform: every entry gets one line of prose, so no single project can dominate the page with a paragraph.

The `link` field is where the actual project is, and it may point to crates.io, GitHub, GitLab or something similar. The optional `crate` field names the package on crates.io, and the guidance is that if there is more than one crate, any one of them will do. The optional `image` is a png, jpg, gif or webp sitting next to the toml file, under 2 MB, with a recommended 16:9 aspect ratio and a maximum width of 600 pixels. Those numbers exist because the same image is rendered in a grid at a fixed size.

Three categories, and the directory is the only place they are defined

Assets are organised into three categories, and the top level of the repository mirrors them exactly, with `Learning/`, `Assets/` and `Apps/` as the three directories alongside the README and a `.github/` folder.

Learning holds anything that can help someone learn Bevy. Assets holds crates and plugins that can be added to a Bevy project to provide additional functionality and content, and the category description points at the Bevy Plugin Guidelines for the practices a plugin should follow. Apps holds games and tools made with Bevy.

The split is by intent rather than by format, and that is what makes the three directories useful. A plugin and a tutorial are both things you consume before or during development, but they answer different questions, and a developer who knows which of the two they need can go straight to the right directory.

The plugin guidelines link is the only place where the directory offers a standard rather than a listing. It tells an author what a well-behaved plugin looks like in this ecosystem, which is a different kind of information from the catalogue itself. It is also a reminder that a listing is not an endorsement. Being in the directory means a pull request was merged, nothing more.

The website is the public face of the repository

The project documentation points out that the repository can be explored in the Bevy Asset website, and the homepage of this project is that site. The repository is therefore the source and the site is the interface, which is a useful distinction when you are reading the toml files.

Practically, this means a reader looking for a plugin has two routes. The site is the one to browse, with the icons, the categories and the one-line descriptions laid out for scanning. The repository is the one to read when you want the underlying record, for instance to see the exact link, to check whether an image is present, or to find the crate name for a project that publishes several packages.

It also means the entry format is a public contract. Any project that wants to be listed writes a toml file and opens a pull request, and the merged result becomes a row on a page that other developers read. That is a low bar for inclusion, which is a strength for coverage and a weakness for signal.

There is another practical consequence. Because the site renders the repository, a broken link or a missing image is visible to everyone immediately. A submission with an image filename that does not match the file in the directory will render as a missing icon, and the description limit means that a name written in a way that overflows is visible in the layout.

What the format leaves out is as important as what it keeps

The limits of this directory come directly from the format, and it is worth being explicit about them before anyone relies on it.

There is no version field. Nothing in the toml schema records which Bevy release an asset targets, and there is no compatibility data, so a listing tells you a project exists and nothing about whether it builds against the version you are using. There is no licence field either, which matters when you are choosing between two plugins for a commercial game. The repository itself carries no licence information in its metadata, so the terms of the catalogue as a whole are unclear from the repository metadata, and each listed project is under its own terms regardless.

There is no review rubric beyond a merged pull request, no health signal, and no indication of whether a project is abandoned. The toml has room for a name, a sentence, a link, an image and a crate name, and nothing else.

For that reason the directory is best treated as a discovery surface. It answers the question of what exists and where to find it, which is the question a newcomer has and which is expensive to answer by search. It does not answer whether to depend on it.

Why a curated list and not the package index

The alternative to a directory like this is the package index itself, and the difference is one of curation rather than coverage.

A package index is complete. Every published crate is there, searchable by keyword, with metadata the tooling derives automatically. What it does not do is classify. A plugin, a tutorial and a game all arrive in the same flat list, distinguished only by their names and their descriptions, and there is no way to ask the index for the beginner-friendly learning material or for the plugins rather than the games.

This directory inverts that. It is a small, human-curated set with three explicit categories, a written description in the author's own words rather than a derived one, and an icon. The cost is completeness and freshness. A project that exists but was never submitted is invisible, and a project that was submitted and then abandoned stays listed, because nothing in the format has a way to express that.

The plugin guidelines add a third layer that neither of the other two offers. A directory can hold conventions, and this one points authors at a standard for writing a plugin for the ecosystem, which means a listed plugin is at least nominally held to the same practices as the rest.

So the two approaches answer different questions. The index answers what exists. The directory answers what a person would suggest you look at first.

Editorial conclusion

bevy-assets suits a Bevy developer who wants a curated starting point for plugins, tutorials and example apps rather than an exhaustive index, and who is willing to check each entry's own repository before adopting it. It does not suit a team looking for a dependency resolver or a compatibility matrix, since the format has no field for version constraints. Verify first the crate name and the upstream link recorded in the toml file, and treat the category and the one-line description as editorial hints rather than as a statement that the project works with your Bevy version.

Frequently asked questions

Official sources

1. bevyengine/bevy-assets on GitHub
2. Issues
3. Project website
4. README