HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
bevyengine
bevy
Rust2020–2026
bevyengine / bevy

bevy

A refreshingly simple data-driven game engine built in Rust

55Distinct people
82Mentions
1Explicit recommenders
49.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A refreshingly simple data-driven game engine built in Rust

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

We don't have a "complete" official example of those things, although the "game menu" example has some of that: https://github.com/bevyengine/bevy/blob/main/examples/games/...…

_cart used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:04:58 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year82 dated mentions

Observed mentions: 2020-08-11 18:08:23 UTC to 2026-10-21 14:04:51 UTC.

051015202020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 8 mentions; 2 submissions, 6 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 12 mentions; 1 submissions, 11 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 22 mentions; 1 submissions, 21 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 18 mentions; 0 submissions, 18 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 12 mentions; 3 submissions, 9 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC826
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC12111
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC606
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC22121
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC18018
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC1239
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC413

What Hacker News says

6 sources
I wrote a thesis for my bachelor's regarding the development of an agent-based simulation framework in Rust where I managed the visualization side. The project takes inspiration from other frameworks such as MASON (in particular for the architecture), NetLogo, Agent.jl and others. I initially developed the visualization subsystem with Amethyst, after my thesis Amethyst was discontinued and, since I was already following Bevy since it went public and it looked like it was gaining a lot of momentum, I refactored our framework to switch to Bevy. Our project is open source: https://github.com/krABMaga/krABMaga . Being my first approach to Rust and my first serious greenfield project, I think there are a lot of parts which can be improved, but I was able to get by with my extremely limited knowledge of both Rust and Bevy and obtain decent resu
Read the rest
lts. The things I loved the most of Bevy was the low amount of boilerplate code needed, the WASM+WebGL support which allowed me to easily let guests run simulations from our github.io site (https://krabmaga.github.io/) at near native (sequential) performance and, just like the whole Rust ecosystem, the friendliness of the community. Even though I bothered quite a bit on the Discord server since the documentation wasn't the clearest for me back when I started (Bevy 0.5), both the team members and users always led me a hand. I also think the ECS approach is extremely useful for our usecase, by defining agents as entities with the Agent component, along with a system which acts as an event loop by executing a simulation step and triggering the agents' behaviour rules. I also noticed the Bevy team might be interested in the simulation field (https://github.com/bevyengine/bevy/discussions/1678), I am sure more projects of this kind would be hugely appreciated!
In Bevy 0.8: data oriented game engine built in Rust
> Cannot make a type in a foreign package implement an interface I would only push back on this point, and this point alone. Sure, it would be very convenient for me, an author to be able to just extend the implementation of anything that I import. However, when I am not an author and am instead a reader of code, doing this is the number-one way to causally make code totally unreadable. By allowing anyone to extend a type anywhere, it makes it impossible to just read the code. If the package that declares a type is the sole controller of that type, then reading code is easier. "Where is the definition of this method?" Answer: It's next to everything else for that type, in the package where that type is defined. However, if anyone can extend any other type, figuring out what methods even exist for a type becomes so difficult that you are f
Read the rest
orced to use a language-server (with all related dependencies installed) in order to use "go-to-definition". If someone wants to understand the code, requiring them to have a full-fledged IDE and/or development environment is pretty awful and quite onerous, and makes codebases tough to get into. For example, take this line[0] from a tutorial[1] on creating a simple snake game using the Bevvy engine in Rust. The main() function wires up loads of entities, including a `snake_eating()` function. But it also calls a mysterious `.after()` method of the snake_eating() function. If you do a ctrl-f on the file, you won't find an .after() method defined for the function snake_eating(). Just reading the code in that file, the only file in the program, you'll never find what the `.after()` method does or where it comes from. Only by opening that code in an IDE with go-to-definition will you learn that it's set via an automatic macro in the bevvy library[2] which causes all functions of certain signatures to implement the System trait. Which... is pretty tough to get into, and means just reading code without computer aid is effectively impossible. In your languages, please don't allow packages to extend the interfaces/traits/types of other packages. [0] - https://github.com/marcusbuffett/bevy_snake/blob/0.7/src/mai... [1] - https://mbuffett.com/posts/bevy-snake-tutorial/ [2] - https://github.com/bevyengine/bevy/discussions/1137
In Experience Report: 6 months of Go
A change I find interesting in this release is the addition of `Deref`/`DerefMut` derives[0]. It addresses a very real pain point in bevy, due to `#[derive(Component)]`'s interaction with the orphan rules requiring newtypes[^1]. But it's potentially not idiomatic within the Rust language, at least at the moment (as mentioned in the OP). However, I think that the tide is likely to turn on that; for example, in the api-guidelines repo, there's a PR[2] to remove this advice. This appears to have stalled, although that appears to be not for reasons of it being controversial, just lack of reviews; the discussion had broad support. We have discussed (in Discord[3]) a kind of 'internal' `Deref`, which would use lenses to do automatic unwrapping for queries. See #4413 [4] for an example of what this would look like. I'm not sure how necessary tha
Read the rest
t is if we can just use `Deref[Mut]`, but it's definitely another angle we could go down long-term. [0]: https://bevyengine.org/news/bevy-0-7/#deref-derefmut-derives [^1]: This newtype requirement isn't a negative for bevy, since it makes it much easier to avoid interoperability headaches between different crates. [2]: https://github.com/rust-lang/api-guidelines/pull/251 [3]: https://discord.gg/bevy [4]: https://github.com/bevyengine/bevy/pull/4413
In Bevy 0.7: data oriented game engine built in Rust
I'm doing this role over at Bevy[0]. Docs, project management, and mentorship (plus my technical contributions). It's incredibly valuable for the project, and has allowed us to scale up to hundreds of active contributors in less than two years. We do our best to welcome and encourage other folks in the same sort of role; there's always more PR reviews, issue management and community building to be done. Incidentally, this work has led to an official role with the project, tons of professional experience and contacts, and some well-paid consulting gigs. I have a very strange and spotty resume due to health issues, so it's been frankly life-changing. [0]: https://github.com/bevyengine/bevy
In The burden of an Open Source maintainer
> What do you mean by single screen? There's no technical reason for that to be the case I've programmed on v0.5, and SystemSet, which is the base for state management, was very immature - it didn't even work with FixedTimeStamp (because they will compete on RunCriteria); I think it's this one: https://github.com/bevyengine/bevy/issues/2233. I've tried implementing multiple states in a game, and it just didn't work. And I don't even know if it was a bug in my code or in Bevy, because state support is not stable, and the documentation is lacking. Without proper state management, you'll end up running either a large amount systems, or fewer systems, with code for all the cases inside. Due to the problematic RunCriteria design, even synchronous assets loading is problematic. There is a plugin for that, but what if another plugin causes RunCr
Read the rest
iteria conflicts? Who knows. > Why do you need opengl when you have support for D3D, Vulkan Because Vulkan may be broken for one reason or another, and then one ends up with a system where OpenGL is not supported, and Vulkan doesn't work. My (modern) system is such case.
In Bevy game engine 0.6

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.