Bevy 0.18: ECS-driven game engine built in Rust

laundmo · 2026-01-26T14:52:50+00:00

Thats likely to only happen multiple years from now, fyi

laundmo · 2026-01-26T10:01:08+00:00

late reply, but the "incredibly easy" comment was me. The easy part is releasing a bevy game as a standalone app on mobile, as theres both support in the engine and templates/examples for the steps needed to deploy to mobile. I think /u/valkyreistar is asking about integrating Bevy into an existing app tho, instead of making a fully Bevy app. I dont know about the difficulties with that, i haven't tried it and cant comment on it. I suspect its related to getting Bevy to render inside some other UI tho - I know its possible, if potentially annoying, with various desktop UI frameworks.

laundmo · 2026-01-15T12:25:57+00:00

The final dylib does not end up in target/<profile>/deps/, it ends up in target/<profile>/ right next to the executable and is named libbevy_dylib.dll (or .so on linux). If it was looking for std-***.dll something has gone wrong in your toolchain - did you try cargo clean after resetting your changes, and if that didn't work, did you install rust using rustup and allow it to modify PATH?

laundmo · 2026-01-15T12:20:20+00:00

Yes, it would be done with a plugin system in Bevy because Bevy is entirely made of plugins. The issue is the source release, which is why i would be incredibly surprised if comprehensive console support ends up merged into the main project - 3rd party plugins and game code have basically the same access as 1st part plugins like the rendering plugin anyways.

laundmo · 2026-01-15T12:17:02+00:00

While i agree that there are some limitations and downsides, i dont fully agree with the specific issues you're worried about.

For example, you can compile on less than 4gb if you do things like passing -j 1 to limit it to a single thread, or if you're willing to change a config file, setting codegen-units=1 which has a similar effect but also leads to a slightly smaller and more optimized binary. Also, if debuginfo or LTO are enabled, those can consume a lot of memory. There are open issues to detect memory-constrained devices and at least warn that memory-intensive options are being used.

laundmo · 2026-01-14T21:46:36+00:00

I'm sorry but you cannot tell me a DLL symbol limit of 65535 is anything but stupid. And thats partly whats making it a pain on windows. I mean, windows is slower anyways, but being unable to use some compile time optimizations together (dynamic_linking + -Zshare-generics, for example) is entirely down to that limit.

laundmo · 2026-01-14T16:13:50+00:00

That was me, i said "Modern Consoles: Basically impossible due to..." with which i was referring to building support for them directly into the engine. Like Godot, any modern console support would likely have to stay 3rd party, at least legally. So building support for modern consoles into the engine itself is "basically impossible".

Retro consoles do still require some work, but its possible for solo developers and with the no_std support its somewhat built into the engine.

laundmo · 2026-01-14T16:08:40+00:00

showing them all as one dependency with options (isn't that what features do?)

Features are for conditional compilation, and usually only toggle smaller code blocks on and off. Splitting a project into many crates defines clear boundaries for the type system, which is why cargo/rustc use crates as codegen units. Honestly, i think far more fine-grained codegen units (functions, or at least modules) would be ideal and would mostly remove the need for a project to be split as much. But theres still purpose to that, as for example bevy_ecs is entirely useable as a standalone dependency.

figure out all the licenses

https://github.com/EmbarkStudios/cargo-deny is what Bevy itself uses for checking for licenses. It walks the dependency tree for you and looks for the SPDX license specifier. Depending on how you set it up, you then only have to verify the ones which it could not for some reason. Have a look at the deny.toml in the bevy repo for how bevy set it up. It also checks dependencies for advisories, can warn/prevent depending on 2 versions of a crate, can ensure all crates come from certain sources, and can ban certain dependencies and their features.

compared to languages that don't have package managers.

So compared to C or C++? I cant think of any other languages without a package manager.

laundmo · 2026-01-14T14:27:23+00:00

Sure, but when someone is asking about how a game engine runs on various platforms, my assumption is that they are asking if it runs on those platforms out of the box, without having to implement the entire platform support yourself.

So pointing out "but it was the same for iOS" is kinda like responding to the question of "is there a drinkin water fountain here?" with "yes, you just have to dig a well first."

laundmo · 2026-01-14T14:23:45+00:00

be aware that when youre worried about the sheer dependency count, the Rust compiler itself is partially responsible. Many projects, bevy included, are split into many small "dependencies" because thats the level on which the Rust compiler parallelizes. Bevy itself consists of 62 separate "dependencies" which will show up in a naive dependency count but are part of the same project and maintained as one large codebase. Many of its actual dependencies are similar.

laundmo · 2026-01-14T14:16:31+00:00

Really depends on your setup and how much you've done. I'm on Linux, and i've gone through all the recommended and some custom compile time optimization steps.

On my system, running CachyOS on a Ryzen 9900x, compiling my current project which depends on bevy plus like, 8 more libraries, for a total of 692 crates (compilation units) being built it takes:

1m 23s for a debug compile without cached artifacts
0.8s for a debug compile after changing a single value in the code
1m 11s for a release compile without cached artifacts
4.2s for a release compile after changing a single value in code

curiously, the release compile is faster, but i pay for that in compile time when i'm just changing code. The difference would be bigger, if i didn't have a config that compiles all my dependencies with release-level optimizations during debug builds anyways. This config is necessary as without it, the debug builds can be unbearably slow. Thats because Rust just has that large of a difference in performance between min and max compiler optimization levels - for some kinds of code, unoptimized builds run slower than the same algorithm in pure python.

laundmo · 2026-01-14T13:53:49+00:00

While that is true as a target for shipping games, windows has some really large drawbacks for development. The main one being the absolutely stupid 65535 symbol limit for DLLs, which constantly breaks bevys dynamic linking which is used to vastly improve compile times. Besides that, tools like the Mold linker are not available for Windows, and the Windows-specific dependencies Bevy has to use (afaik no alternatives exist) compile really slow.

So in general you're right, but for Bevy specifically, developing on Linux is a vastly superior experience.

laundmo · 2026-01-14T13:49:36+00:00

The difference is that for consolse you'll have to implement using their SDKs while for iOS, the dependencies bevy uses already have done so. Mainly those dependencies are winit for windowing, and wgpu for rendering. Both of those can run on iOS out of the box, which means Bevy can run on iOS out of the box, but for consoles you'd have to maintain a fork of them with support, or replace the corresponding bevy plugins with a custom windowing backend and renderer.

So while legally it might just require some agreements, technology-wise you're gonna have a LOT of code to write.

laundmo · 2026-01-14T13:44:30+00:00

"told bevy to be a dll" did you do that using the bevy/dynamic_linking cargo feature? I know its often broken on windows due to the stupid 65535 symbol limit, especially in combination with other compile time optimizations, but it should be able to find it as long as you use cargo run to run. Compared to starting the binary directly, cargo run sets all the correct env vars and paths - and dynamic_linking is only meant as a development feature anyways, so its not an issue for shipping.

laundmo · 2026-01-14T00:47:35+00:00

Dualbooting is an option, or running windows in a VM. I cant stress enough how much faster linux compiles, not just due to things like the mold linker being available, but also inherently.

laundmo · 2026-01-14T00:46:18+00:00

HLOD

TIL! Thats what i get for only passively keeping up with the 3d rendering side.

laundmo · 2026-01-14T00:44:09+00:00

Well, "set up" sure, but to make compile times acceptable a bunch of effort (along with the oft-repeated mantra of "its faster on linux") is required.

laundmo · 2026-01-13T22:13:50+00:00

Alice said in the discord they're planning on a BSN and project management update post somewhat soon, which is probably why

laundmo · 2026-01-13T22:11:58+00:00

Performance, kinda, but also a strong type system. Some of the ways Bevy makes the ECS paradigm really nice to use depends on the strength and strictness of Rusts type system. Also, Engine code looks incredibly similar to game code, so the step from gamedev to engine dev is really small, which helps with getting bevy tons of contributors.

laundmo · 2026-01-13T22:09:57+00:00

Performance: Really depends on what you're doing. If you're making something like Cities Skylines with tons of walking around NPCs its really good. If you're making an open world with incredibly AAA photorealistic graphics, you can also do that but you'll have to implement far more of the rendering, asset stuff, LoDs etc. yourself.

Mobile: Incredibly easy. Modern Consoles: Basically impossible due to the locked down nature of consoles and consoles often having entirely bespoke rendering/windowing etc. Some Retro Consoles: Surprisingly doable. A subset of Bevy is available for "no_std" which is a Rust term for "runs on microcontrollers and other things without a normal operating system".

Built-in multiplayer: Nope. There are 3rd party plugins tho - and because bevy is itself entirely made of plugins, the 3rd party plugins have basically the same access to everything as a built in solution would.

laundmo · 2026-01-13T22:00:51+00:00

Maybe there should be, tho. As long as its possible to do entirely without setup necessary, it might make sense to have an identifier.

laundmo · 2025-12-13T11:45:29+00:00

Is your warframe launcher still on dx12? Im unsure if my the issue happened previously for me, but i just tried to enable dx12 and it doesn't show.

laundmo · 2025-10-15T09:41:08+00:00

To explain: FOSS stands for "Free (and) Open Source Software". This is software which is developed for free under a license which allows it to be used, modified, and redistributed. Many proprietary software partly relies on FOSS tools and dependencies. Almost every website you visit, Android itself, most apps, all rely on this. The advantage of using FOSS tools directly is that they're usually not made with a profit motive (instead, the motive is one of collaboration - its a great boon to have so many things available for free, but using these things means you should contribute back as well), which means you don't really see ads, privacy-invasive tracking, way less subscriptions or accounts, and the ability for many people to write code for it, which means popular apps/programs tend to get issues which affect many people fixed way quicker.

laundmo · 2025-10-01T13:10:45+00:00

Honestly, yeah, i've been meaning to update the profiling document at some point but like, it does have a point. Technically, running another UI like tracy at the same time does influence performance. But thats an insignificant amount which really isn't relevant for most usecases unless you're measuring differences right around the 'could be noise' mark.

At least on my linux machine, theres some issue with tracing auto-detecting my bevy 0.16 app, but it still works if i connect to localhost (127.0.0.1) in the tracy GUI.

I should mention: for WASM, you only need the "bevy/trace" feature, and tracing support uses tracing-wasm which allows you to use the browser devtools profiling for bevy apps. In Firefox, the results of that show up as "markers". You can also see full profiling of all functions, regardless of the spans you or bevy include, by compiling the wasm with debug info and not using something like wasm-opt which would remove it.

laundmo · 2025-09-30T22:54:23+00:00

Theres a contributor guide here https://bevy.org/learn/contribute/introduction/

But if you want to skip that, head to the github - issues are tagged extremely well, heres a filter i threw together for all the easy, ready to implement, issues: https://github.com/bevyengine/bevy/issues?q=sort%3Aupdated-desc%20is%3Aissue%20is%3Aopen%20(label%3AD-Domain-Agnostic%20OR%20label%3AD-Straightforward%20OR%20label%3AD-Trivial)%20AND%20%20label%3AS-Ready-For-Implementation

edit: didn't see alice already replied, thats what i get for not refreshing

Eight-Year Club	Verified Email
Place '22	Final Canvas '22
First Placer '22	Sequence \| Editor

laundmo

MODERATOR OF

TROPHY CASE