I'm looking into creating a CAD-like application (though extremely domain-specific). Is it possible to use some GUI framework like Qt or Gtk and host a view running the Bevy engine for visualization and manipulation? Or would I have to create all the UI in Bevy?
Hi,
I've been trying to wrap my head around everything related to BSN and bsn! since 0.19 released, but I'm still partially confused about how to use it in theory, and quite confused about to use it in practice.
Is there any example that connects DynamicWorld with the new BSN features, or is DynamicWorld bound to become legacy once an official bsn loader drops?
Is a bsn loader something that I will be able to patch into 0.19, or will I need to wait 2-5 months and migrate everything to 0.20 for that?
If I understand it correctly, Template and FromTemplate are intermediate formats between bsn! and spawned game "bundles", and for the most part, I don't need to write any code directly with Templates and don't need to manually implement FromTemplate?
Speaking of which, are bundles on their way out as the recommended way to spawn things? Or will they always be side by side with bsn! for some technical reasons? What are the cases that I shouldn't try to force bsn! into?
Why can I spawn `Mesh2d(asset_value(Rectangle::new(img.x, img.y)))` but `MeshMaterial2d(asset_value(ColorMaterial { ... })` does not work?
I can see the few small uses of bsn! in bevy_city and a lot of examples with UI, but is there any more comprehensive example that demonstrates this in a game, or otherwise a larger example that isn't just "spawn a button" "spawn a camera" but more along the lines of "spawn an NPC with a different shirt color and list of components based on some input"?
Is there any example that actually does persistence with BSN - is there something that simplifies my approach as it is now in 0.19, or is it still same as in 0.18 where I just have to query all my entities, save their information in a separate struct with serde::serializable on them, and save entity ids of parents and children separately so I can re-map them on load?
Both the release notes and bsn! / Scene / bevy_scene documentation are excellent and I don't want to make it sound like they're not, but I did not manage to wrap my head around it properly. The new beta Bevy Book is also excellent but it doesn't seem to have any information about Scenes yet either.
Hi,
I like the idea of Bevy. I like the idea of ECS. Convince me - why should I use Bevy?
I'd like to make a 3D game, an immersive sim. ECS is great for that.
So, convince me - give me an example of a Bevy game that proves it can handle such a project and I'll be sold.
Thanks!
Stellwerk is the first game I have released. Players take on the role of an interlocking operator, setting switches, sequencing trains, and ensuring that everything arrives at the correct destination on time. As the timetable becomes more crowded, small ordering errors can lead to gridlock — a problem that Zach games are designed to solve.
It was developed by a lone developer using Rust/Bevy. It's available on itch.io (https://tilcob.itch.io/stellwerk). I'm happy to answer any questions about the design or technology used. I would be grateful if you could leave a comment on my Itch page telling me what you think of the game.
Hey All,
I am fairly new to Rust and extremely new to Bevy. I was wondering if people had tips, tricks, or tools they recommend for Rust and Bevy development. I am using cargo and VS code and seeing what Claude Code can do. Any insights would be cool. Happy Coding!
Every few weeks someone here posts a version of "imagine a Draw Steel video game." I couldn't get it out of my head, so I spent the last year building one in my spare time - LOTS of time.
It's a tactics roguelike. You build a party, drop onto a grid, and fight on the actual Draw Steel math, which was the whole point: the power rolls and tiers, edges and banes, all behaving the way they do at the table. Forced movement carries real weight, and yes, sliding something into a wall or hazard kills it the way you'd hope. Heroic resources and enemy malice are both in, so a fight builds and turns instead of just trading hits. Four classes so far: Fury, Censor, Shadow, and Troubadour. I'm going to try to add more before EA release, but at a minimum these 4 will be polished.
At it's core, it's full sandbox of the tabletop game alongside the roguelike on top. You can build your own party, pick one of the encounters it ships with or edit your own map and enemies, and just run the combat. Pick a party, drop them in, hit go. If you've ever wanted to see how an encounter or a homebrew statblock actually plays before it hits your table, that is what it's for. The enemies behave as close to their roles as possible too, but I will be tweaking that and hopefully adding a GM mode so you can run the monsters too.
A couple of things I figured this crowd would care about: none of the art is AI-generated (that's a line I'm not crossing, not a marketing bullet point), and it runs natively on Linux and the Steam Deck, not just Windows. I'm going to try to get Mac out at some point too, if possible.
It's an unofficial fan project made under MCDM's Creator License (Powered by Draw Steel, not affiliated with or endorsed by them). I backed the game originally during the OGL debacle and have been really enjoying it :)
There's no demo yet (look out for Steam Next Fest) and I'm still deep in it. I've been running tabletop games for years, so a video game feeling faithful instead of a generic tactics game with the name slapped on matters to me more than anything. Mostly I want to hear from the people who actually run this system: what would make a Draw Steel video game feel right to you? You're the people who'd spot where I got it wrong.
If you want to follow along, it's up on Steam now and you can wishlist it here.
Building a tank game called Overmatch, which will be a spiritual successor to War Thunder. I'm building it in Bevy, and I'm having a blast!
I want to show off my current best track model. This is much more. complex than it seems! so many forces come into play, and it's very difficult to make it feel natural without actually modeling every single track link and bogie as Avian rigid bodies
Still building a low-poly castle-defense / exploration /rts game in Bevy 0.19, and most of the "look" is a stack of custom post passes layered on the built-ins.
I've kind of run out of obvious things to improve, so I figured I'd share it here. If anyone wants to just play it, or is curious to poke at the code / contribute, you're very welcome — it's all open source.
Code: https://github.com/miskibin/warbell
Play / downloads: https://miskibin.github.io/warbell/
Bevy Constellation shows what crates people are using across different versions. It scrapes project data daily to stay up to date. It also links back to the repos so you can find code demonstrating how crates are used together.
A while ago I posted my progress on Velyst, on rendering Typst in realtime game engine bevy. This time I want to show you something I made using it, combined with motiongfx, my motion graphics engine!
Link to YouTube (if u care to like & subscribe!): https://youtu.be/\_OGOaunoqMU?si=FdNhB16KqYBXJEqE
Hi everyone!
I'm excited to announce the v0.3.0 release of univis_ui! For those who aren't familiar with the project, it is a high-performance, SDF-based hybrid world-space and screen-space UI framework for the Bevy game engine. It acts as a powerful alternative to bevy_ui, designed to work seamlessly across 3D, 2D, and screenspace (HUD).
Unlike traditional UI setups, univis_ui uses Signed Distance Fields (SDF) to render crisp, pixelation-free UI components even at close range or under heavy camera zoom in 3D space.
Here is what's new in this major stable release:
🚀 What's New in v0.3.0?
Workspace Modularization (Crate Split): We have refactored the project from a monolithic crate into a clean Cargo Workspace split into 5 responsibility-led crates: univis_ui_style, univis_ui_engine, univis_ui_interaction, univis_ui_widgets, and the univis_ui facade. This keeps compile times low and code clean.
Unified Roots (URootUi): Replaced legacy root wrappers with a unified URootUi model. It supports viewport-bound HUD (URootUi::screen()), fixed world canvases (world_2d/world_3d), and content-driven auto-resizing world UIs (world_2d_fit_content).
Frontier-Based Incremental Layout Solver: Massive performance improvements. Layout calculations now run through a bounded settlement loop that tracks dirty node frontiers. Instead of walking the whole UI tree, it only resolves modified branches. It also caches and reuses layout meshes by logical size.
Advanced Sizing Constraints: Added native support for min_width, max_width, min_height, max_height, and intrinsic sizing states like UVal::MinContent and UVal::MaxContent.
SDF Text & Intelligent Ellipsis (Bidi Support): Font rendering now supports grapheme-safe truncation, bidi-aware text segment isolation (for right-to-left and mixed languages like Arabic + English), and Middle/Start/End ellipsis truncation.
Bento Grid Showcase: Added a brand new Bento Grid example (examples/grid/bento.rs) demonstrating how to build complex interlocking, masonry-style layouts using our CSS-like grid layout engine.
Ready-to-Use Widgets: Shipped interactive widgets out-of-the-box, including USeekBar, UDragValue, UCheckBox, UToggle, URadioButton, UScrollView, USelect (dropdowns), and UTextField.
GitHub Repository: github.com/univiseditor/univis_ui
Crates.io Facade: crates.io/crates/univis_ui
Bento Example Source: grid/bento.rs
Wanted to show this off. I'm building a realistic tank game, called overmatch.
I realized the penetration mechanics are an incredibly complex world, so I built a dedicated world for testing and iterating on it.
Bevy 0.19 Overview - BSN, Area Lights, Shadows: https://youtu.be/Vejo4U7k3nQ
This chapter helps builds a navigable 3D viewport from scratch in Bevy 0.19, starting with the three essentials of any scene (a camera, a light, and a mesh).
We'll be working on more features in the upcoming chapters, stay tuned :)
Alright hello everyone, I made a standalone visual explanation of the Separating Axis Theorem for collision detection.
My first one so this, took an embarrassing amount of time but I feel like it has decent animations and narration at this point.
It covers:
The video is engine- and language-independent, and is aimed at people interested in implementing collision detection or understanding how narrow-phase algorithms work.
I’m also working on videos covering general collision detection, broad phase versus narrow phase, and GJK.
