When it reaches version 0.3x, by an old Rust tradition, it will be abandoned and users will be referred to some new awesome project.

@@OlegLecinsky That's a tradition that other languages have had with projects for a long time. Wouldn't say it's just rust.

@@user-wg2eh3iy5r Other languages also have a tradition of having complete, finished products.

​@@OlegLecinskyI don't think that's the case with this one. Cart started an organization to support the engine and they have some cash to pay for devs from what I've seen. Ofc everything can happen but fingers crossed this is an exception to the rule 😞

​@@da7e I don't have my fingers crossed because I don't care after my experience with Rust. Ash v 0.37 to 0.38 - breaking changes. RawWindowHandle has versions 0.4 0.5 0.6 - breaking changes. Winit some versions ago - breaking changes, and they already have Winit Next in their Github repo list. And those aren't some small side projects but are supposed to be foundational frameworks for anyone writing cross-platform Vulkan code. Who in their right mind (aside from a handful of cultists, of course) would ever use a never ending rolling release platform which gives zero sh1t to backwards compatibility for development of something like games that tend to be supported for many years, and sometimes - decades?

its still incomplete as a visual engine, but yep, its got everything that runs games under the hood

the fact the best bevy game curently (Tiny Glade) uses a custom renderer should be a massive wake up call to bevy contributors.

​@@thegoldenatlas753 It is important to know that Tiny Glade is a two person team, one of which is Tomasz Stachowiak. He previously worked at Embark, where he worked on their in-house render engine, and open sourced an experimental GI renderer called Kajiya. He has said on X that Tiny Glade's renderer is a sort of lite-Kajiya. So he basically is a rendering god, and has more to gain from writing his own custom stuff. There is a Kajiya plugin for bevy but it's not really in working condition. Bevy is also trying to create a basic universal renderer first. Being flexible and universal means it can't be as custom tailored as in Tiny Glade. They will add more options for global illumination in the future.

@@thegoldenatlas753That wasn’t really what I was saying but I hope they sort this out.

​@@thegoldenatlas753Tiny Glade uses a custom renderer because its made by one of the top graphics programmer in the world. They would have used a custom renderer in pretty much any engine. They didn't do it because of bevy's renderer lack of features. In fact we even use the tonemapper created by them and they frequently help us improve the renderer. I don't know what wake up call you think we need

@@thegoldenatlas753 god forbid the people working on a project on their free time doesn't do everything perfectly.

The game looks amazing, how much experience did you have with rust before starting the project?

@@ViktorEvil I did not have any experience in gamedev, but I started programming back in highschool around 2006-2007, so roughly 16-17 years

comfy engine sounds like the one to satisfy the "i just want to make a game"

Hello Rika

I’d recommend Raylib if you’re a beginner

I think the editor can be external and the components can just reflect to it over socket what it is they need of the editor to be able to edit.

This is literally not true. Bevy can very much add/remove components at runtime, with the type only known at runtime. It has always been possible: look at the Bevy scene format (which has existed since forever). It is a RON text file where the components are declared with their values. The type name is a string parsed at runtime. At compile time, Rust knows nothing about what might be in a scene file when it gets loaded. If you can do that from an asset file, you can also do it from a network protocol, from an editor, or from a scripting environment. Bevy ECS has dynamic (based on `ComponentId`) management of components and entities, and Reflection allows you to make the metadata (like type names and struct fields) from the Rust source code available at runtime (to be used by scenes, editors, etc.). The technical foundations for what you are describing have been in Bevy since at least 0.3, 3 years ago. I have personally built (game-specific) level editors for Bevy, that have done exactly that, and it worked just fine. So I am speaking from experience. Also see github.com/kaosat-dev/Blender_bevy_components_workflow . It's a Blender plugin that can use Reflection metadata from Bevy to allow you to put arbitrary/custom Bevy ECS components into GLTF files. None of this is "hardcoded" or "type checked at compile time". A scripting environment needs more than an editor, though. One of the last major pieces that was missing was dynamic queries, and that has now landed in 0.13.

bevy uses "wgpu" which has multiple graphics backends: Vulkan, Metal, WebGL, WebGPU and more note: wgpu is a rust graphics abstraction. webgpu is the browser graphics thing.

​@@laundmo I really wish they didn't rely on wgpu It slows down bevy's development waiting for upstream features for the various graphics api's

@@thegoldenatlas753 What are they waiting on?

@@thegoldenatlas753 bevy would not be as far as it is without wgpu. too much time would have been wasted working on individual graphics backends.

As someone who has worked a bit with graphics programming... Yeah, wgpu makes the most sense.

i have no idea why the video is so choppy. on any hardware which you can expect to run modern games on high settings (what this scene effectively is), people get 60+fps.

Generally it boils down to renderers often not playing nice with video capture software.

@@gamefromscratch it does feel kinda disingenous to have video THIS choppy on screen without mentioning that its that bad due to capture software. makes people think this is the normal performance.

There's no "default" present mode in vulkan, there's just a single mandatory one: FIFO.

@@SupinePandora bevy offers a Mailbox / Immediate present mode, not only Fifo

Were you using dynamic linking? With Mold (linker) and dynamic linking I had very reasonable compilation times after the first cold run.

On linux with dynamic linking and mold linker it's super fast. On my windows it's freaken slow to the point of being unusable. But maybe it can be optimized there as well, I only use windows to build it for windows users

On my computer (not so good, not so bad) it takes only 1-3s with dynamic linking enabled, the problem generally comes when I make other crate in the project so everything needs to be compiled again, but generally not a problem because most of the development time is iterating with the code itself.

Once you've done the initial compile it's no different time-wise than using Unity/Unreal/Godot.

@@retticle actually I would say it's faster than unity

One of the UI developers here. Yes, we are. We have been planning it for a long and took carefull steps towards it. It's our main focus now and all of Bevy's development power is now focused on making an editor.

@@idedaryhappy to hear it! best of luck

Dogfooding Bevy's editor has been the plan since day 1. The first ever public announcement of Bevy 0.1, which outlined the project's philosophy, said it. The past 3 years have been spent building all the tech needed, and it has always been a design priority for all of it to eventually be dogfooded by building a full fledged Bevy editor in Bevy itself.

At least everyone is basically in agreement the renderer is overdo for an overhaul and many of the main contributors are in favor of overhauling it.

40mb seems like a surprisingly large binary. did you build in release and with stripping debug symbols?

@laundmo in release. I didn't use any size optimization, though. Maybe I'll check again soon.

@@yds6268 yeah it should be more like 15mb at most, if you disable stuff the cube doesnt need like audio or asset loaders it should be less again

@@yds6268 Even with just `strip = true` you'll see a pretty significant improvement with size. You can also use lto, codegen-units, and disabling unused Bevy features.

Just learn rust first. Bevy makes a mess of all the nice compiler errors. I suggest the channel No Boilerplate, great videos on rust.

@@thegoldenatlas753 'nice compiler errors' Don't I just love it when I'm learning beginner rust and I see 'blah blah mutable reference immutable reference blah blah lifetime `1' when i'm nowhere near learning about lifetimes. it gets really annoying after the first few times

Ikr the docs are terrible and the cheatbook is just barely enough.

i actually found the docs to be quite comprehensive. i dont mean "the bevy book" which is indeed bad and needs updating. the rustdoc docs though are surprisingly comprehensive with lots of details about implementations and doctested examples

docs, cheatbook, updates changing syntax, all very very trash. all those things with occlusion raytracimng stuff has been done 70years ago same as there game examples with that 2D block moving has been programmed less complex and less lines 70 years ago.

@@davidsilverfinger777 ah, i see, a very nuanced opinion. surely it must be incredibly unbiased and genuine. what a paragon of honesty we have here.

​@@davidsilverfinger777I don't think you have any ideas what programming was like 70 years ago

No, we take inspiration from godot with the idea of using our own ui solution to build the editor just like they did but bevy is a pure rust project and there is no plan to use a third party editor. A huge part of bevy's editor will be about the ECS which is not a feature of godot at all.

FFI bindings? Those are the ones updated regularly, but I don't like introducing C memory errors into my Rust :)

@@yds6268 lol fair

Why?

i use raylib but with bevy_ecs for ecs and bevy_app for the game loop

😂 nice joke

He was force fed foliage as a child. Maybe he'll recover someday.

Why? Rust is super fast, reliable and safe language so why would they need Godot when they can just use Rust?

that makes no sense.

That makes no sense. If anything the editor should be made in bevy or in egui.

@@thegoldenatlas753 the plan is using the editor to dogfood bevy ui

Guys, it was a joke 😂. Good one though 😊.

What do you mean?

It's feedback to the developers, who often watch these videos. Releasing on a weekend is literally the second worst time they can do a release if they want people to actually notice the release. Releasing on a Friday afternoon being the worst option. If they want to utmost exposure to their project and their releases, they would do well to heed the feedback.

yeah, thats such a entitled take. bevy doesnt even have a legal structure yet (its in the works), people work on it in their free time (besides cart, who is sponsored enough to be fulltime) no shit they're gonna release on a sunday because thats when people have time to do so

@@gamefromscratch so they should release on days where most people are either at work or tired from work? so that most people wont have the time to check it out?

@@gamefromscratch say it once at the beginning or the end as an FYI ... I am pretty sure you mentioned it at least 3 times ... I am watching this while working and all it stuck was release date lol ... in any case I am grateful you did an overview was just annoyed that is all lol

He only mentioned 1 time and it was for 10 seconds. Why are you so angry?

I wouldnt say its overhyped its just the best option from a flexibility point of view. everything can be replaced with a custom option (like the renderer) Tiny Glade is a good example as they use bevy ecs but a custom renderer

Do you have a single fact to back that up?

@@Ghostal What fact do you need? The fact that there is no editor and no one know how it will look like? The biggest part of my comment are subjective thoughts

re: noone knows yet, there are big games running on ECS, like Overwatch

@@Koteal They don't use it for everything in there unlike Bevy (eg. UI)

Say what? Rust is now supported by the Linux kernel team, also it is now pushed up by Google, Amazon and (ta daaaa) Microsoft. Rust is going to be the C++ for the next 15-20 years.

@@EduardKaresli exactly. better toolchain, better package managment, better compiles, memory safe, the list goes on. Rust is what you should be building new projects in for sure.

@@thegoldenatlas753 It has a package manager and is memory safe. Big deal. If people don't like to use it, they won't use it. Rust still has too many shortcomings to fully replace anything.

@@v01d_r34l1ty what short comings? From everything ive seen the only short coming is it doesn't have the benefit of having a decade plus of legacy code and libs backing it. And its not that is *has* a package manager, its that it has the single best package manager for coding that also acts as your build toolchain and testing environment and everything else you need. Rust is literally the most loved language and that's for a reason.

​@@v01d_r34l1tyexcept it is replacing a bunch of things and is now shipped in a bunch of things you probably use daily. Like, there's rust in windows now

theres several editors you can use atm and an active work to design and plan the official one. bevy hasnt even hit 1.0 version yet while unity hit it 19 years ago. Bevy also has different priorities such as modularity and the ability to replace entire chunks if you so choose such as the renderer.