Awesome work! I love how it feels so easy to make a system (I'm actually digging your crates wondering how the hell did you achieve that Trait Extension).
I just hope that the `Turtles All The Way Down` philosophy won't hinder game devs from supporting scripting language of their choice. Because at some point someone is going to need domain specific language somewhere.
Great start here and a very compelling intro post. A couple of things I wondered about and didn't see answers to:
1. How ambitious is Bevy as an engine? Do you see it as aimed squarely at the casual-game space like ggez, or do you think it could eventually compete with Godot, growing more advanced features like GI? (I appreciate that competing with Unreal is probably, well, Unrealistic for the forseeable future.)
2. You talk a lot about keeping the build light, which is great to hear. Does this extend to deployment too? What kind of binary filesizes are you looking at for a "hello, world" game?
1. I want to be ambitious while also being realistic. AAA studios won't even consider using Bevy until it has more features and has stood the test of time. So in the short term our market is essentially "indies and enthusiasts". I want Bevy to cater to those people, but with an eye toward larger projects. We don't want to design ourselves into a "locally optimal" corner that prevents us from appealing to large studio. That being said, even in the short term I am extremely interested in advanced rendering techniques and will be investing a good portion of my time on adding things like GI and PBR.
2. Small binaries is absolutely something I care about. Last time I checked we could produce a "hello world" game with windowing + rendering thats just a little bit over 1 MB. I think we could probably make that smaller with some effort.
edit for some additional clarity: this involved running a post-processing "strip" process on the binary.
As someone who may be tinkering with a game this decade, one big factor which favors “use prebuilt engine” in my thinking is that some of them abstract away the work required to port between different systems. Is this really a very big hurdle in your opinion? And do you see console ports being part of this engine in the future?
The API looks great in any case, and I’ll try it out, at least as a starting point to get back into Rust and ECS. Nice work!
You can't just port something to work on Sony / MS / Nintendo platform, only them manage the toolchain and they just don't usually support things outside of C++ / C#.
Console adoption and porting essentially require a game or games that need to be ported. Typically this happens through third party companies for games built on open source projects.
Some don't, some do. Users living out in the sticks with poor satellite connectivity care about binary size. The HTML5 platform, which I see becoming increasingly important as things like wasm and webgpu mature, cares about binary size because you're potentially downloading it every time you play. It's slightly surreal poking about on itch.io where practically every game is 50 MB, even when most of them are simpler than a 4k demo.
I would expect that for most games the vast majority of bytes will be assets (textures, models, sounds, etc.), not code. Even reducing the code size to 0 is unlikely to make much of a difference in the total size.
For AAA titles, sure, but there's a long tail of indies, game jam entries etc. For something retro-styled like Dwarf Fortress or Baba Is You, I can absolutely believe that asset size is relatively minor compared to e.g. a Unity baseline footprint.
Harking back to ancient history for a moment, Frontier: Elite II was a AAA title for its day and was basically all code.
Sure they do, when targeting consoles and mobile devices.
Their overlords always stress on developer conferences how install size is the number one reason for users to remove applications and games from their devices.
It does a bit when you have 8GB of shared memory between the graphics card, OS and your game. Download size isn't the only memory constraint affected by binary size.
How much control do you have over rendering without having to discard Bevy's renderer and asset server entirely? A big problem I had with Amethyst (and, honestly, other big engines like Unity and Godot) is that you have very little ability to use custom formats that have prebaked visibility, lighting and so forth because there’s no good way to efficiently control how the renderer gets called. You can only convert your scene to their format, usually discarding useful information. I want to use BSP as the level format in my games because I’m familiar with it and it allows for modders to easily create content, but no engine with a pre-built renderer allows you to render them anywhere close to efficiently. This isn’t just being able to have custom file format loaders and render pipelines, you need to be able to have a single vertex buffer while creating a number of index buffers based on various precalculated visibility clusters, and then be able to choose the index buffer to be rendered based on the camera's location.
Hi _cart, creator of Planimeter's Grid Engine (a Lua game engine) here. Congratulations on your phenomenal work! I'm very familiar with the fact that posts like these on HN that help drive adoption, so thanks to adamnemecek as well.
I'm quite excited to give this a try. I'd just point out that I'm seeming to run into errors, even on the examples. I love debugging just as much as the next developer and will probably figure this out, but I thought I would suggest that you get a forum like Stack Exchange or something custom. Most people develop via Google or DuckDuckGo and not being able to Google an error code or make a post is a serious hindrance to development. (Discord is great but not a replacement)
The error that I am currently facing (if you're curious):
EDIT: This is because I was using Rust 1.40 rather than 1.45. Oops.
$ cargo run --example breakout
Compiling glam v0.9.3
Compiling same-file v1.0.6
Compiling anyhow v1.0.32
Compiling once_cell v1.4.0
Compiling adler32 v1.2.0
Compiling anymap v0.12.1
Compiling crc32fast v1.2.0
Compiling remove_dir_all v0.5.3
Compiling pin-project-internal v0.4.23
error[E0599]: no method named `map_or` found for type `std::result::Result<std::string::String, std::env::VarError>` in the current scope
--> /home/myname/.cargo/registry/src/github.com-1ecc6299db9ec823/glam-0.9.3/build.rs:7:10
|
7 | .map_or(false, |cfg| cfg.split(',').find(|&f| f == "sse2").is_some());
| ^^^^^^ help: there is a method with a similar name: `map_err`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0599`.
error: could not compile `glam`.
warning: build failed, waiting for other jobs to finish...
error: build failed
I hope you don't mind a piece of constructive criticism about the web page but: the syntax coloring scheme you're using makes the comments nearly invisible. Code comments are useful, and therefore should be easily readable, IMHO.
Wow! What great timing. I've been working on CRDTs for the last couple years and realized the structure we're settling on is similar to ECS. Last week, I figured I'd dive into ECS and also scratch my game-making itch by trying out Amethyst. I've had a suspicion that the API could be a bit simpler, and well, you nailed it! After an afternoon of playing around, Bevy has been a pleasure! Really great work!
Everything is beautiful so far, the website is nice looking, the overview is self-explanitory. If I wasn't so in love with Godot I would use this. I think one thing that would sell this would be an editor like Godot has, it's one of the strongest selling points with Godot for me.
That's what I figure, I saw that Bevy does support UIs, which is how Godot makes their own UI, and how RPG In a Box[0] was born from Godot itself (I'm not affiliated with RPG In a Box nor Godot, just someone who is learning Godot). I think it's going to be wonderful to see a spawn of powerful and open source game engines in the coming years.
Bevy even mentions Godot as an inspiration for building the editor using Bevy itself. The creator of Bevy has a lot of experience with Godot, so I'd assume we're going to see bits and pieces resembling how Godot works.
I realized that recently, the author is working on a game in Godot as you said. It makes a lot of sense. Godot is a good standard to look up to. I can't wait to see this project as it matures.
For anyone curious this is the game from the author:
The integrated code editor in Godot is actually something I don't like. The text editor doesn't support the usual Mac keyboard shortcuts, scrolling isn't always responsive and it can't be used to view text files such as json files.
I hope that Bevy users won't be forced to use the Bevy editor for coding. VS Code, vim, emacs and other editors have lots of extensions and work well for coding. I'd rather see some kind of project builder UI for Bevy, which would allow using existing code editors.
You're technically allowed to edit code elsewhere I thought? The editor for Godot is there out of convenience. It's also Open Source and I'm sure you could raise issues about these problems. If they're not voiced in the proper channels they might not get resolved.
I have to say the API seems to be very pleasant and simple at a glance. Kudos to the author!
> Being able to use Rust functions directly as systems might feel like magic, but I promise it's not! You may have noticed that we do this when registering systems in our App (...)
> (...) This works because we implement the IntoQuerySystem trait for all functions that match a certain set of function signatures.
This pattern is a great example of how Rust achieves to be both very ergonomic or dynamic (in the sense of expressiveness) and type safe at the same time.
That's pretty cool! Is there any material you'd recommend me reading that gives examples of these kinds of ergonomics with traits as they pertain to, say, vanilla web development?
I merely a beginner and learn the language on the side.
Things that come to mind are (incomplete list):
- From trait
- derive
- traits you can implement to convert a data structure into a iterator
- Deref, Drop traits, MutexGuard
These things appear magical at first but make for very expressive abstractions.
In regards to web-dev: a framework that makes heavy use of traits and macros is Rocket.
As for material: when I’m learning I typically have The Book, Rust by Example and some tabs of the standard library open. Then just go by curiosity. Perhaps not the best approach?
This might be the killer app that finally gets me to use Rust. I've tried so many engine libs/frameworks in so many languages now, and none of them look nearly as complete and ergonomic as this.
I don't really want to have to write my own 3d renderer or ECS because the engine's one is bad or nonexistent... this really scratches an itch for me.
Not only that, but the way it is written draws you in. It tells you its scope, function and methodology right from the start. I kept reading but I know little of Rust.
There are multiple projects which show significant promise to deliver this. In addition to Druid, I've been impressed by Iced, and there are several others that are seeing some development.
MIT License, well done! It's so refreshing to see things released with no strings attached. Yes there is value being created, and the creator should be compensated. But, it's such a breathe of fresh air as a potential end user to not have to worry about intricacies of GPL etc. inclusion.
This is amazing. Seriously: I had a look at nearly every game engine/GUI solution in Rust and this is by far the most thought out, ergonomic and complete thing I found.
I've tried using Amethyst a few times but never finished anything. Upon each attempt I ended up moving to another language/framework due to the frustration of horrible compile times. Also, while there are lots of comprehensive docs, but the docs were written for a variety of versions so there was a lot of friction to get something simple started. It has been several months since my last attempt, so perhaps Amethyst has improved since then. I do love the promises Amethyst makes and for the same reason I'm very interested in Bevy.
I gave Amethyst a serious try about a year ago. I even joined the Gitter intending to contribute, as I needed some more dynamic rendering features, and read the foundational research on the wiki that seemed to inspire the project.
I found the application of the research -- the execution -- too early in development for my needs. I have the feeling it will grow into something more flexible with time, but at least back then, I wasn't able to render to a texture being applied to a mesh. Not being able to get around the deeply integrated ECS was hard, as well.
I tried Amethyst but found the API had quite rough edges in practise, and there was too much boilerplate for my taste. I certainly had the feeling they did certain things in certain ways not because it was the best solution, but because they didn't find a better way.
This was a while ago so it might not be fair as things probably improved since then and one should definitely give it a try as well.
That being said the whole bevy way of doing things looks very well considered indeed — maybe both projects can profit from each others existence?
Got the chance of running the examples and glance over the code. Also checked the book and docs. As I mentioned in another post about Bevy, it looks incredibly elegant and clean. Almost feels like this could make engine development fun again. And custom engines feasible.
Contrary to popular belief, the need to build your own engine is real for a significant amount of projects. I look forward to being able to quickly put together a few building blocks, customize the renderer and experiment with new systems.
Basically an ECS is not really a secret easy pattern to cache coherent data access. This benchmark shows its fast for the easy cases but says nothing about typical game requirements.
So? That has nothing to do with the performance of an implementation which is what I commented on. Data oriented design is about managing data organisation to match access patterns in order to best exploit the hardware cache. That requires more design than simply using the ECS pattern. Which is why a lot of generic engines introduce other concepts like Grouping and Archetypes to try to alleviate this. And even if you do use a generic ECS engine with performance sensitive features it’s still perfectly feasible to end up thrashing.
Also as a claim I also find this highly doubtful particularly as I’ve been working as a game developer for many years and not really seen it used on a single project in that time. There’s a reason why there are dozens of hobby implementations but no full scale games written using them.
Looking at that it has way more in common with an OOPish inheritance/composition approach to entities than the ECS view of an entity being a primary key into a data store of components with a pipeline of systems acting in a component centric manner to update the game state.
Just a note that data-driven is not the same as data-oriented-design [1].
I was trying to see how Bevy embraced data-orientation, but I think it doesn't necessarily do so, since data orientation is more about reducing indirection, for ex., reducing or removing excessive data hierarchies. I think dod is also related to "mechanical sympathy" [2].
Edit: maybe the ECS part is the dod part? I saw the tree demo and it did not look very ECS to me. Maybe it is just the UI? :-)
Yes, ECS' usually give you at least a good default that is data oriented. At a glance it seems like it does[0]. Notice how some systems (functions) iterate over components rather than entities, which implies a "struct of arrays" layout that benefits caching.
I'm getting security warnings visiting the site, on both Firefox and Chrome (though chrome's could be due to an external check, redirects me to malware.opendns.com). "Error code: SEC_ERROR_UNKNOWN_ISSUER" on FF at least.
edit: and seems like I'm not the only one, as there's at least one upvote already. probably worth checking!
It's working today! Did you have to make a change, or did some caches just get flushed or something? I've seen a couple other github-hosted-page issues like this, but I have no idea what the cause or fix is.
From my limited experience (doing Amethyst's Pong tutorial and glancing through Bevy's home page), Amethyst is more mature and also seems more complex (and presumably more powerful). There's quite a bit of boilerplate to get started, but it gives you very fine-grained control over everything like how assets are loaded, how components are laid out in memory, etc. It seems like it's aiming more for the "real game studio" market than for enthusiasts, although last I checked it's also mainly focused on 2D for the time being.
It's funny, I've been doing something similar in Rust. A GUI framework that renders to Vulkan, and at the bottom is an ECS system(multiple systems) for rendering, layout, animation. But this one is very far ahead and looks very polished.
I think they mean that people keep coming along and saying "the existing N competing standards suck, let's make a new one everyone can use" and now there's N+1 competing standards.
There are many reasons, but to name a few important to me: rust gives performance on the level of C++, but with the memory safety of a garbage-collected language. It also provides protection against data races so that you can use concurrency with less chance of hard-to-debug issues.
For some, theoretically it's easier to train new Rust developers than it is to fix the bugs of new C/C++ programmers. Folks are trying to move the cost to training and dev bringup time instead of bug-fixing time.
Rust has other more technical advantages. But if you want to know why management is choosing it, it's because getting good C/C++ developers is a painful process nowadays.
Getting good developers is painful process no matter what, usually those are the ones that don't answer headhunters, search for their own gigs via their own contact network, and don't get to change jobs just for a couple of more coins.
Having spent a good deal of time working in a dogmatic data driven entity component system very similar to this one, I'd like to point out that while it's very aesthetically pleasing to write code like that, it's not necessarily more productive or pleasant than a more conventional 'entity's behavior lives on the entity' approach.
The original link posted here (the homepage) doesn't really get in to what makes Bevy interesting, I would recommend this great blog post instead that introduces it: https://bevyengine.org/news/introducing-bevy/
I'm not sure if that is an answer or an additional question. If an indie game maker wanted to make a game, why would they use Bevy over the Unreal Engine? It it just because it's different or are there advantages?
Rust, ECS-core, slimmer abstractions, less tooling (less to learn, but also less pre-built), less complex as a general rule since its less featureful, which also means less cruft/bloat; unreal engine also has a general preference towards "realistic graphics & FPS gaming", to whatever detriment this means for any other type of game (e.g. afaik 2D games are not well-supported or tooled, and probably never will be; graphics tooling can be dramatically overcomplicated when you're chasing something stupidly simple, like replicating King's Field style billboard-3D graphics), etc
The big three specifically, which is pretty close to the reasoning for choosing any game engine thats not Unreal/Unity probably would be:
Sorry, the sentence has a question mark at the end because basically everything is different.
Size: Bevy is probably thousands of times smaller than UE. That is either a feature or a bug, depending on your needs.
Complexity/feature set: Bevy is a lot simpler because it's simply smaller. This of course means it's less capable. Again, feature or bug, depending on needs.
Language: UE is written in C++, so you can make games in C++ and its own language UnrealScript. Bevy is written in rust. Feature/bug depending on needs.
License: UE has a source-available commercial license, while bevy is FOSS (MIT license). A more open license is obviously better, but the commercial licenses generally come with support.
That said, I'm not a professional game developer, but am currently experimenting with the Godot engine (Also an indie FOSS engine, but a little older). I don't really like GDScript, but I can just use C++ bindings anyways.
I'm happy to answer whatever questions people have!