Some people will say the final result is weird.... They are right. To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/Fredyy . You’ll also get 20% off an annual premium subscription.
Let's see, if we consider... - New to Rust, which requires you to do some things differently - New to Bevy and ECS, which is a paradigm shift - Bevy changing quickly so information may already be outdated - Bevy not having an official editor (yet! It's being worked on... ) so it's hard to quickly see what's happening - No use of video tutorials Yeah, you did great! ... Crotch bullets~!
@@salysPRO thanks! Yeah, I found a few outdated pages and posts, but the compiler does a good job telling you something is deprecated. I also looked at multiple pages every time I needed something, so I would compare one page to another and see what changed...
@@FredyyDevI can tell you from experience it’s a recipe for disaster learning all those things at once. Once I got over the rust hurdle and came back to Bevy, learning about the Plugin paradigm it encourages, a lot of things clicked into place. (And I’m a AAA game engine dev - getting my head around this humbled me for a short minute).
IMHO, editors are often what makes or break the engine for a casual user. My game engine has a tilemap and sprite layout editor, and many don't like the fact that tiles are displayed by name+tileID rather than the tiles themselves (and so are sprites), and in the next editor version I'll be revisiting that, but first I need to solve some dumb build issues, and get libevdev (RawInput for Linux) working.
@@FredyyDev im new to programming and love to see people doing stuff like this, no i don't need cryptolike guys who tell they were ex faang programmers and talk about all they stuff they know without ever record them aktual doing some coding. coding sucks in a way you will never master it, it always changes and seing someone trying something knew and show a more realistic site of the job is always fun to watch -and hearing your thoughtprocess is more worth than watching the 10. python tutorial and copying it 1 to 1.
hey, making a game in bevy while being new to bevy AND rust at the same time is insanety. good job nonetheless, it really impressive given the context. also, props to you for your methods of gathering info
I actually did that. The only advantage I had was long programming experience. So no Rust knowledge, no game dev knowledge (me trying to achieve some rendering effect in Bevy was a torture because I knew nothing about shaders et al). Honestly, the Rust was and after many months still is a killer for me. I envision some architecture, then I cannot simply implement it because of millions of rust caveats that all make sense, but are very hard to circumvent, leading to a clusterfuck of code instead mostly declarative style. That being said I quite enjoyed bevy itself.
Quick note about 22:52 It's not that rust won't let you declare uninitialized variables, but rather the compiler can't guarantee that the variable will be initialized before access. For example if there are no player components, the for loop will never execute and the variable will be undefined. A way to simplify a lot of code for getting the player would be to use the .single() (or the non panicking version .get_single()) to declare and instantiate the variables in one line.
"I don't know if this is good practice but..." That's me all the time with Bevy. It's a very interesting experience with Rust being so strict but Bevy being so loosey goosey at the same time.
FYI, ECS has been an idea in development since 2002, if not earlier. It was implemented for Dungeon Siege and described in a 2002 GDC talk by Scott Bilas, which you can find on UA-cam. It didn't get the name "ECS" until later, around 2007 or so, as more and more articles and implementations of the idea started to emerge. But it's been a thing for decades. I don't bring this up just to be pedantic, but rather because "Wow look at our new ECS idea" has been used in the marketing for things like Unity, and the fact that ECS is older than Unity, not to mention all these younger engines, should be more widely known so that people aren't susceptible to that kind of marketing.
@@delphicdescant That's interesting... Good to know! Indeed I see people pitching ECS as the ultimate paradigm. I don't know, maybe it didn't click for me yet...
@@FredyyDev To be fair, I do actually like ECS, so I'm not saying that people or engine creators *shouldn't* tout it as a good thing. I just don't like it when companies or groups try to take credit for "inventing" it, if that makes sense. I think the thing that usually makes the value of ECS "click" for people is having previously tried to write a game using a bunch of inheritance structures or other object-oriented programming practices that let them paint themselves into a corner, in some way or other. So when they later read about ECS, they think "wow all those problems just don't exist if I do things this way instead."
@@FredyyDev ECS is great when you start to share concept between entities. Let's say you make a "Lootable" component. Which basically create a "looting" feature in your game. Whenever you spawn a entity, you can attach a Lootable, and voila, you can loot every mobs you create. It's also easily extendable, let's say you want different UI for corpse/chest/containers looting, Just make a "loot" systems with differents queries for Corpse, Chest or Container. It's that simple. In a more "object oriented" SDK, you would have to inherit from Lootable, which also inherit from something else, etc, you'll ends up with a "tower" of inheriance. Each layers adding feature, and complexity.. and worse thing, would be that a childs mutate a protected attributs of a parents, and your on for weeks of debugging. However, ECS are not the magic recipe for making games. As an example, I think it's actually terrible when making small game, like tetris/flappy bird/etc this sort of small things. Because the "component" have no real meaning here. It's also terrible for voxels, because you cannot spawn an entity per voxel, or it will just clutter the whole engine. But when it comes to Open world /RPG/ city building or RTS games. There is shine like a beacon. Because adding generic feature to the entire game will just be about adding more component to the entities. As every plugin make its own house keeping, it's also more simple to debug, just enabling/disabling entire part of the game is just matters of commenting out a plugin. Want to loot corpse/chest/container ? Add a "Lootable" component Want to make building produce mobs ? Add a "MobProducer" component Want to make enemy shoot at you ? Add a Mob component and a "shoot_at_player" system which spawn Bullet. Want to make mobs shoot at each other ? Add a shoot_at_nearby system and Friend/Foe component. It's really organic in the way the dev will improve the game by adding more system/component, and I personnally really like it.
@@delphicdescant And they indeed don't exist if you do things this way. You have other problems, you just need to find if the paradigm is what you want or not.
@@carafe576It’s Composition and DoD (Data-oriented design) fundamentally (as opposed to Object-oriented design), it’s just that ECS is how that’s manifested in gamdev, it’ll have other names and other concepts in other industries. ECS itself is just an easy way to get general DoD in a general way for most games, but nothing stops you from applying the same DoD or Composition principles to non-ECS games 👍
when i saw that you hadn’t installed rust yet i knew it was going to be interesting. i really like the way that you learn stuff. thinking of doing it myself
The best thing about Rust for me is that you can easily refactor your program. This really helps me in learning Rust. For example, when I used one concept and then learned another, I have no problem reworking the code because the compiler shows me where I need to fix it. This also works great with adding new features.
By the way, if you check out the repository, it includes dozens of examples that show how to use the engine. Each example is a single file so you can easily play around with them and grab what you need.
theres a lot of shenanigans under the hood for sure. If you want to isolate the core of how bevy works, start with the bevy_ecs crate since everything else is practically built around it, like how a pc build is centered around the cpu/gpu. Ask for help as well, there is a lot of seemingly contrived design choices unless youve used it in depth, and understand how a lot of it works.
@@thisguy.-. well I also mean on how exactly it's handling dynamically calling those functions that are put into the update and everything. I guess it just takes a Fn with any amount of arguments?
@@griffinmartin6356 It uses some pattern matching trait magic, you can find it at the Bevy repo at path crates/bevy_ecs/system/function_system,rs (youtube moderation doesn't like links atm iirc) at the bottom of the file if you're interested, though it's sorta hidden behind a macro I don't think you can take a Fn with any amount of arguments in rust, you have to use traits for this kind of thing
Dude... HOW did you grasp all those concepts so quickly!? I had such a tough time getting started (I also didn't/don't know rust), what you did in a mere couple of hours took me days. I would you LOVE to see you continue this or even make it into a series!
because the part in computing that gets faster at the slowest rate over time is "copying data from ram to cpu/gpu", that then gets slower and slower over time (relatively), and your programming style+language needs t optimize for that slowest-speed-bottleneck. object oriented programming does not optimize for this. it is going to become a relict. data oriented programming (with entity component systems) does optimize for this. it is becoming the default. data oriented means, all modifiable data is in long uniform lists, to optimize for the process of copying to cpu-cache. entities (anything that moves by modyfying data, like a sim in a sims game, have "components" that point at "data" of such lists. data oriented programming shines where ever you have large populations of very similar moving/changing objects. with data oriented programming you may have 100x to 10.000x as many of the same sims/projectiles on the same hardware. data oriented programming may not be worth the overhead-extra-cost on simpler games with less moving parts.
For being new to Bevy and Rust your project was pretty awesome! I have been watching lots of basic bevy tutorials on yt very nice to see The Freddy himself tackle bevy! Your fn shoot I would make a singe change, a Query Might have your entities or might not depending have any entities that match the query components , The code isn't wrong but will still run with zero players, by changing player_transform to be just the query transform value. for player_transform in &player{ "the rest of your code" } This way only if a player exists it runs, and if any players doesn't exist the query will be empty thus the for loop will not run! Any extra players will also run the loop! Now the player can control a firing squad!!
I presume that they add an update function either way because that's its purpose. If you don't have an engine, you should probably code that yourself, so it does make sense that there's a module that adds that in. Stuff only happens if there's code for it. We're just spoiled and treat an update function with a time step variable for granted
I gave it a go too, its just a waste of time compared to using godot or raylib, for composing behaviour just use a fat entity system, for performance just use smaller structs and batch simulate.
You know this video was actually rather interesting, especially since I actually use bevy a bit on my own as a hobbyist. I'll say you did a rather good job considering the restrictions you put on yourself, plus a lack of knowledge about Rust. There are a few things I would do differently, but broadly you did what most people would do for their first ECS project, especially with your experience with a more 'traditional' OOP approach.
Amazing first try with you being new to a lot of things. I am sure there are alot of explaination videos about Rust and ECS. If you would like to know the history of the rise in popularity and where ECS principles stems from, I recommend watching Mike Acton's talk about Data Oriented Design and C++ and he was the VP for unity engine architecture and spear headed Unity DOTS at some point. Anyway just a interesting mention ifnyou'd like to check it out would like to see a video what you think about it if not another video about you leveling up your bevy and rust skills. Good luck and enjoy the journey.
Game engines started out without UI, so I wouldn't say its the future. Game engines with UI like Godot are much easier and make the process faster, no UI is definitely not an advancement, or the future. My first language was Python and I coded games in it for 4 years, and even published a game on steam made in Python, and I never knew what I was missing until I tried Godot. Regardless, great video, you did an amazing job!
I'd regret learning a rust hame engine before learning Rust just as Rust. That's the problem with low level languages and games. I'm pretty sure at one point or another indie game devs think "man, I wish I just wrote this game in scripts instead of using all this". You know like lua or javascript or whatever.
i mean kinda, for me I just studied the Rust Book and *then* just dived into game dev, because thats what I like to do. And the thing is that there is more than just bevy. I started with Coffee, drppped it because its depreciated, and picked up ggez. And I still use it today in conjunction with MonoGame, with ggez being used as a tool for building custom specific mesh data. And I dont exactly regret not learning Rust more, since it was really easy to pick up the rest along the way. I suppose if you havent read the book, then youre going to struggle, but the book is so quintessential to anyone who learned to code in rust, and is so easy to find and access that Id wager not going through it and at least picking up the core concepts is just being ignorant of what makes Rust its own language and just trying it, expecting success when that very success depends on you being able to tough out the stupidly difficult learning curve. which is why I dont reccomend bevy or ggez to anyone who hasnt at least shown interest in reading about how to code in rust.
I appreciate that there are developers out there that still care about optimization and see the benefits of ECS, but I don't see a reason for anyone to try to make fully fleshed out games in it. If you have to build everything from the ground up, why use a game engine at all?
Performance isn't the only benefit. Composition is another big advantage. About the engine, yeah, it's a very low-level framework, but doing it from scratch is a whole other beast.
bevy is... a challenge, for sure. I prefer ggez for rust since its a lot easier to hit the ground running, and has much easier canvas drawing without directly forcing ECS upon you while still leaving the option open. I wouldnt reccomend bevy until someone uses an engine that gives complete control flow to the user, so they can figure out the patterns that actually make ECS and modularity so useful. Otherwise, it will just seem like inserting complexity for complexities sake, and I would rather people at least know why using App's and System's and Bundle's helps in the not-very-visible long run
how long was the cycle of rebuilding the program? Gamedev is something with lots of trial and error, i've seen people livestream Bevy and the long build times stopped me into trying it.
@@pietraderdetective8953 usually around 10 seconds for me. I didn't do all the steps for optimizing this recommended in the "getting started" section tho
even if the compile times are fast, you still have to account for the fact that your development speed is gonna be floored by the insane learning curve, so only try it if you have the commitment to go the distance. otherwise, just keep a minimal amount of extra libraries that dont serve a massively important role, and your compile times will be fine enough.
I like bevy's library but compiling for up to 1 minute after adding println!(...) kills it for me. also rust analyzer takes 700mb of my ram, no one ever mentions that.
What i don't like about rust and bevy is that it seems to think you are both a genius and have infinite time. The compiler is super strict and at times VERY criptic. Option inflates the length of the code just like mut before even optimizing the thing. Systems like this iterate over a big list and waste more memory to internally optimize, you might as well make your OWN system and use this one just for rendering which wastes more time. Static variables are restricted and using the intended workarounds makes your code very ugly. I know it's to prevent the pre-initialization order nightmare but I only use it for lonely individual CORE objects so it never bothered me and it never will.
This "engine" lacks: 1). Scene editor 2). Occlusion culling 3). It's own global illumination system (except baked lighting exported from Blender). 4). Even it's virtual geometry is still in beta and requires tedious preprocessing with manual adding methods in your own code. That's the future you like? But it's written in *Rust* ! You don't understand! It's very *safe* , the borrow checker for game is more neccessary than first class features everyone uses! Rust evangelists are always like this. Just take a look for their leaders and how they look like.
@@chanku18 Godot is also very open about development, yet it still can't compete even with Unity. 3D part still being unfinished for 10 years, especially about performance. I believe only in what has happened, not what was promised, because I have very bitter experience with such declamations.
Bro those are valid points but calm down. It's just a video testing an engine, I'm clearly not preaching bevy or anything, and bevy seems harmless so far, let them cook. We will see how this engine evolves over time! Right now it isn't complete enough to be used in production, I agree. And Godot is also a good project, with a bright future. Cheers bro!
rust has huuge boons that are never going to be found in another engine. need a mesh editor that can handle all of the fuckiest shenanigans you can physically cram into cpu time? how about a game with several complex systems that need to be run in particular orders? want to develop without the bloat of unnecessary editor ui and instead have access to egui, which is much more customizable and useful? even if you may get by with other particular engines, (monogame my beloved, never gonna take my control flow away) you will never find success as easily without running into a load of crap that makes you wish youd rather had gone cold turkey while you had the chance and are now stuck with a node tree which just will not work for what you want, or a game that is bug ridden or just flat and relies entirely on the non-coding related aspects to take it to success.
@@triducal the "safe" language doesn't have strict specification, unlike Ada. It only has one compiler with no guarantees to backwards compatibility in the future. The whole "unsafe" thing can and *WILL* be exploited in practical applications. Rust is also infamous for its long compilation times, much worse than C/C++. In fact, NASA, SpaceX and automobile manufacturers still use C/C++ for dangerous tasks, because in fact language "safety" doesn't matter as much as performance, reliable testing process and having alternative tech stack (and, well, C/C++ do that perfectly). I do agree that safety matters, but Ada and many functional language do it much better than Rust. Whole "niche" of Rust is fanatism-driven.
Some people will say the final result is weird.... They are right.
To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/Fredyy . You’ll also get 20% off an annual premium subscription.
Let's see, if we consider...
- New to Rust, which requires you to do some things differently
- New to Bevy and ECS, which is a paradigm shift
- Bevy changing quickly so information may already be outdated
- Bevy not having an official editor (yet! It's being worked on... ) so it's hard to quickly see what's happening
- No use of video tutorials
Yeah, you did great!
...
Crotch bullets~!
@@salysPRO thanks! Yeah, I found a few outdated pages and posts, but the compiler does a good job telling you something is deprecated. I also looked at multiple pages every time I needed something, so I would compare one page to another and see what changed...
@@FredyyDevI can tell you from experience it’s a recipe for disaster learning all those things at once. Once I got over the rust hurdle and came back to Bevy, learning about the Plugin paradigm it encourages, a lot of things clicked into place.
(And I’m a AAA game engine dev - getting my head around this humbled me for a short minute).
IMHO, editors are often what makes or break the engine for a casual user. My game engine has a tilemap and sprite layout editor, and many don't like the fact that tiles are displayed by name+tileID rather than the tiles themselves (and so are sprites), and in the next editor version I'll be revisiting that, but first I need to solve some dumb build issues, and get libevdev (RawInput for Linux) working.
@@FredyyDev im new to programming and love to see people doing stuff like this, no i don't need cryptolike guys who tell they were ex faang programmers and talk about all they stuff they know without ever record them aktual doing some coding.
coding sucks in a way you will never master it, it always changes and seing someone trying something knew and show a more realistic site of the job is always fun to watch -and hearing your thoughtprocess is more worth than watching the 10. python tutorial and copying it 1 to 1.
hey, making a game in bevy while being new to bevy AND rust at the same time is insanety. good job nonetheless, it really impressive given the context. also, props to you for your methods of gathering info
@@justanotheruser7843 thanks, that's motivating!
Imagine being new to Rust, Bevy, ECS and game development in general 😂
@@Alex5000148 that would be torture
The video turned out to be a good intro to Bevy. Thanks! :3
I actually did that. The only advantage I had was long programming experience. So no Rust knowledge, no game dev knowledge (me trying to achieve some rendering effect in Bevy was a torture because I knew nothing about shaders et al). Honestly, the Rust was and after many months still is a killer for me. I envision some architecture, then I cannot simply implement it because of millions of rust caveats that all make sense, but are very hard to circumvent, leading to a clusterfuck of code instead mostly declarative style. That being said I quite enjoyed bevy itself.
Quick note about 22:52
It's not that rust won't let you declare uninitialized variables, but rather the compiler can't guarantee that the variable will be initialized before access. For example if there are no player components, the for loop will never execute and the variable will be undefined. A way to simplify a lot of code for getting the player would be to use the .single() (or the non panicking version .get_single()) to declare and instantiate the variables in one line.
"I don't know if this is good practice but..."
That's me all the time with Bevy. It's a very interesting experience with Rust being so strict but Bevy being so loosey goosey at the same time.
FYI, ECS has been an idea in development since 2002, if not earlier. It was implemented for Dungeon Siege and described in a 2002 GDC talk by Scott Bilas, which you can find on UA-cam.
It didn't get the name "ECS" until later, around 2007 or so, as more and more articles and implementations of the idea started to emerge. But it's been a thing for decades.
I don't bring this up just to be pedantic, but rather because "Wow look at our new ECS idea" has been used in the marketing for things like Unity, and the fact that ECS is older than Unity, not to mention all these younger engines, should be more widely known so that people aren't susceptible to that kind of marketing.
@@delphicdescant That's interesting... Good to know! Indeed I see people pitching ECS as the ultimate paradigm. I don't know, maybe it didn't click for me yet...
@@FredyyDev To be fair, I do actually like ECS, so I'm not saying that people or engine creators *shouldn't* tout it as a good thing. I just don't like it when companies or groups try to take credit for "inventing" it, if that makes sense.
I think the thing that usually makes the value of ECS "click" for people is having previously tried to write a game using a bunch of inheritance structures or other object-oriented programming practices that let them paint themselves into a corner, in some way or other.
So when they later read about ECS, they think "wow all those problems just don't exist if I do things this way instead."
@@FredyyDev ECS is great when you start to share concept between entities.
Let's say you make a "Lootable" component. Which basically create a "looting" feature in your game.
Whenever you spawn a entity, you can attach a Lootable, and voila, you can loot every mobs you create.
It's also easily extendable, let's say you want different UI for corpse/chest/containers looting,
Just make a "loot" systems with differents queries for Corpse, Chest or Container.
It's that simple.
In a more "object oriented" SDK, you would have to inherit from Lootable, which also inherit from something else, etc, you'll ends up with a "tower" of inheriance.
Each layers adding feature, and complexity.. and worse thing, would be that a childs mutate a protected attributs of a parents, and your on for weeks of debugging.
However, ECS are not the magic recipe for making games. As an example, I think it's actually terrible when making small game, like tetris/flappy bird/etc this sort of small things.
Because the "component" have no real meaning here. It's also terrible for voxels, because you cannot spawn an entity per voxel, or it will just clutter the whole engine.
But when it comes to Open world /RPG/ city building or RTS games. There is shine like a beacon. Because adding generic feature to the entire game will just be about adding more component to the entities. As every plugin make its own house keeping, it's also more simple to debug, just enabling/disabling entire part of the game is just matters of commenting out a plugin.
Want to loot corpse/chest/container ? Add a "Lootable" component
Want to make building produce mobs ? Add a "MobProducer" component
Want to make enemy shoot at you ? Add a Mob component and a "shoot_at_player" system which spawn Bullet.
Want to make mobs shoot at each other ? Add a shoot_at_nearby system and Friend/Foe component.
It's really organic in the way the dev will improve the game by adding more system/component, and I personnally really like it.
@@delphicdescant
And they indeed don't exist if you do things this way. You have other problems, you just need to find if the paradigm is what you want or not.
@@carafe576It’s Composition and DoD (Data-oriented design) fundamentally (as opposed to Object-oriented design), it’s just that ECS is how that’s manifested in gamdev, it’ll have other names and other concepts in other industries. ECS itself is just an easy way to get general DoD in a general way for most games, but nothing stops you from applying the same DoD or Composition principles to non-ECS games 👍
when i saw that you hadn’t installed rust yet i knew it was going to be interesting. i really like the way that you learn stuff. thinking of doing it myself
The best thing about Rust for me is that you can easily refactor your program. This really helps me in learning Rust. For example, when I used one concept and then learned another, I have no problem reworking the code because the compiler shows me where I need to fix it.
This also works great with adding new features.
This is EXACTLY my experience as well but with a rogue like game. Good luck with RUST and Bevy! Also your keyboard sounds good.
"it's always my fault isn't it?" Debugging in a nutshell
By the way, if you check out the repository, it includes dozens of examples that show how to use the engine. Each example is a single file so you can easily play around with them and grab what you need.
actually a very good look at bevy.
This also makes me wonder how they do a lot of it in the backend as I'm newer to rust
theres a lot of shenanigans under the hood for sure. If you want to isolate the core of how bevy works, start with the bevy_ecs crate since everything else is practically built around it, like how a pc build is centered around the cpu/gpu. Ask for help as well, there is a lot of seemingly contrived design choices unless youve used it in depth, and understand how a lot of it works.
@@thisguy.-. well I also mean on how exactly it's handling dynamically calling those functions that are put into the update and everything. I guess it just takes a Fn with any amount of arguments?
@@griffinmartin6356 It uses some pattern matching trait magic, you can find it at the Bevy repo at path crates/bevy_ecs/system/function_system,rs (youtube moderation doesn't like links atm iirc) at the bottom of the file if you're interested, though it's sorta hidden behind a macro
I don't think you can take a Fn with any amount of arguments in rust, you have to use traits for this kind of thing
I've watched this entire thing verbally saying "huuuuuuuuuuuuuuuuuuhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh"
pretty good video my brain melted!
Dude... HOW did you grasp all those concepts so quickly!? I had such a tough time getting started (I also didn't/don't know rust), what you did in a mere couple of hours took me days. I would you LOVE to see you continue this or even make it into a series!
I learned many libraries and frameworks so I know I should Google 90% of my questions lol
Now I learned most of rust by interacting with gpt for my dumb questions, but I have to say, you mastered this brilliantly.
because the part in computing that gets faster at the slowest rate over time is "copying data from ram to cpu/gpu", that then gets slower and slower over time (relatively), and your programming style+language needs t optimize for that slowest-speed-bottleneck.
object oriented programming does not optimize for this. it is going to become a relict.
data oriented programming (with entity component systems) does optimize for this. it is becoming the default.
data oriented means, all modifiable data is in long uniform lists, to optimize for the process of copying to cpu-cache.
entities (anything that moves by modyfying data, like a sim in a sims game, have "components" that point at "data" of such lists.
data oriented programming shines where ever you have large populations of very similar moving/changing objects.
with data oriented programming you may have 100x to 10.000x as many of the same sims/projectiles on the same hardware.
data oriented programming may not be worth the overhead-extra-cost on simpler games with less moving parts.
For being new to Bevy and Rust your project was pretty awesome! I have been watching lots of basic bevy tutorials on yt very nice to see The Freddy himself tackle bevy! Your fn shoot I would make a singe change, a Query Might have your entities or might not depending have any entities that match the query components , The code isn't wrong but will still run with zero players, by changing player_transform to be just the query transform value.
for player_transform in &player{
"the rest of your code"
}
This way only if a player exists it runs, and if any players doesn't exist the query will be empty thus the for loop will not run! Any extra players will also run the loop! Now the player can control a firing squad!!
@@Mint25pop thank you, it's still very confusing for me but I'll get the hang of it.
I presume that they add an update function either way because that's its purpose. If you don't have an engine, you should probably code that yourself, so it does make sense that there's a module that adds that in. Stuff only happens if there's code for it. We're just spoiled and treat an update function with a time step variable for granted
I gave it a go too, its just a waste of time compared to using godot or raylib, for composing behaviour just use a fat entity system, for performance just use smaller structs and batch simulate.
Rust is a beginner monster on itself, so you did great!
Freddy bevy?
You know this video was actually rather interesting, especially since I actually use bevy a bit on my own as a hobbyist. I'll say you did a rather good job considering the restrictions you put on yourself, plus a lack of knowledge about Rust. There are a few things I would do differently, but broadly you did what most people would do for their first ECS project, especially with your experience with a more 'traditional' OOP approach.
Amazing first try with you being new to a lot of things. I am sure there are alot of explaination videos about Rust and ECS. If you would like to know the history of the rise in popularity and where ECS principles stems from, I recommend watching Mike Acton's talk about Data Oriented Design and C++ and he was the VP for unity engine architecture and spear headed Unity DOTS at some point. Anyway just a interesting mention ifnyou'd like to check it out would like to see a video what you think about it if not another video about you leveling up your bevy and rust skills. Good luck and enjoy the journey.
Game engines started out without UI, so I wouldn't say its the future. Game engines with UI like Godot are much easier and make the process faster, no UI is definitely not an advancement, or the future. My first language was Python and I coded games in it for 4 years, and even published a game on steam made in Python, and I never knew what I was missing until I tried Godot. Regardless, great video, you did an amazing job!
@@Bloxd.io-Bros ECS is the part people say will be the future tho! Bevy is getting UI some time in the near future. Thanks for the compliment!
@@FredyyDev Oh I see. I might check it out then
I like no UI, except you'd need a level editor, you can code one yourself but that's a bunch of extra work.
@@EverRusting exactly, i prefer UI though, because it is so much easier to navigate assets in my project.
I'd regret learning a rust hame engine before learning Rust just as Rust. That's the problem with low level languages and games. I'm pretty sure at one point or another indie game devs think "man, I wish I just wrote this game in scripts instead of using all this".
You know like lua or javascript or whatever.
i mean kinda, for me I just studied the Rust Book and *then* just dived into game dev, because thats what I like to do. And the thing is that there is more than just bevy. I started with Coffee, drppped it because its depreciated, and picked up ggez. And I still use it today in conjunction with MonoGame, with ggez being used as a tool for building custom specific mesh data. And I dont exactly regret not learning Rust more, since it was really easy to pick up the rest along the way. I suppose if you havent read the book, then youre going to struggle, but the book is so quintessential to anyone who learned to code in rust, and is so easy to find and access that Id wager not going through it and at least picking up the core concepts is just being ignorant of what makes Rust its own language and just trying it, expecting success when that very success depends on you being able to tough out the stupidly difficult learning curve. which is why I dont reccomend bevy or ggez to anyone who hasnt at least shown interest in reading about how to code in rust.
JavaScript is a wild take
hey, love your videos! keep doing them plz
@@oihandeshayes6751 thanks!
really good video I hope you continue to learn rust/bevy if you liked it
I'm using bevy next
I appreciate that there are developers out there that still care about optimization and see the benefits of ECS, but I don't see a reason for anyone to try to make fully fleshed out games in it. If you have to build everything from the ground up, why use a game engine at all?
Definetly has it's place
Performance isn't the only benefit. Composition is another big advantage. About the engine, yeah, it's a very low-level framework, but doing it from scratch is a whole other beast.
bevy is... a challenge, for sure. I prefer ggez for rust since its a lot easier to hit the ground running, and has much easier canvas drawing without directly forcing ECS upon you while still leaving the option open. I wouldnt reccomend bevy until someone uses an engine that gives complete control flow to the user, so they can figure out the patterns that actually make ECS and modularity so useful. Otherwise, it will just seem like inserting complexity for complexities sake, and I would rather people at least know why using App's and System's and Bundle's helps in the not-very-visible long run
how long was the cycle of rebuilding the program? Gamedev is something with lots of trial and error, i've seen people livestream Bevy and the long build times stopped me into trying it.
@@pietraderdetective8953 usually around 10 seconds for me. I didn't do all the steps for optimizing this recommended in the "getting started" section tho
even if the compile times are fast, you still have to account for the fact that your development speed is gonna be floored by the insane learning curve, so only try it if you have the commitment to go the distance. otherwise, just keep a minimal amount of extra libraries that dont serve a massively important role, and your compile times will be fine enough.
I think ECS existed decades before Bevy was even a thing, i wouldn't call it a pioneer
I like bevy's library but compiling for up to 1 minute after adding println!(...) kills it for me. also rust analyzer takes 700mb of my ram, no one ever mentions that.
lmao this was very enjoyable to watch and relatable
ecs is pretty good
What keyboard are you using?
@@AndrasBuzas1908 Ajazz AK820.
❤
masochist
What i don't like about rust and bevy is that it seems to think you are both a genius and have infinite time.
The compiler is super strict and at times VERY criptic. Option inflates the length of the code just like mut before even optimizing the thing.
Systems like this iterate over a big list and waste more memory to internally optimize, you might as well make your OWN system and use this one just for rendering which wastes more time.
Static variables are restricted and using the intended workarounds makes your code very ugly. I know it's to prevent the pre-initialization order nightmare but I only use it for lonely individual CORE objects so it never bothered me and it never will.
Eeey Cey Ess sounds a bit long. How about ecis? I would call it ecis, or essys.
I bet you can't code
Vrasil
@@cvabds ué mano kkkkkk
@@diadetediotedio6918 sim, esse cara também pelo visto kkkkk
This "engine" lacks:
1). Scene editor
2). Occlusion culling
3). It's own global illumination system (except baked lighting exported from Blender).
4). Even it's virtual geometry is still in beta and requires tedious preprocessing with manual adding methods in your own code. That's the future you like?
But it's written in *Rust* ! You don't understand! It's very *safe* , the borrow checker for game is more neccessary than first class features everyone uses!
Rust evangelists are always like this. Just take a look for their leaders and how they look like.
I mean, the Bevy is very open about being under development (it's not even at 1.0) and is actively working on those things.
@@chanku18 Godot is also very open about development, yet it still can't compete even with Unity. 3D part still being unfinished for 10 years, especially about performance.
I believe only in what has happened, not what was promised, because I have very bitter experience with such declamations.
Bro those are valid points but calm down. It's just a video testing an engine, I'm clearly not preaching bevy or anything, and bevy seems harmless so far, let them cook. We will see how this engine evolves over time! Right now it isn't complete enough to be used in production, I agree.
And Godot is also a good project, with a bright future. Cheers bro!
@@Capewearer why are you comparing bevy to godot when it's barely 4 years old and rapidly improving
@@FredyyDevand yet the the title and thumbnail…
Ey boss for the future can you please switch to redot?
@@Riael I might check it out but I don't see a point... I don't like politics but Godot (the engine itself) is still good
@@FredyyDevcongratulations wokie, you will now go brokie.
@@FredyyDevredot is uselss
who tf actually cares about the drama lol 💀💀
@@split987 Since you don't feel free to be quiet about it ^^
Using rust for gamedev 🤮
You have been psyoped into thinking rust is good.
@@RichardLofty well I like it for now
and why don't you like rust? are you just saying this becuase everyone else says this?
rust has huuge boons that are never going to be found in another engine. need a mesh editor that can handle all of the fuckiest shenanigans you can physically cram into cpu time? how about a game with several complex systems that need to be run in particular orders? want to develop without the bloat of unnecessary editor ui and instead have access to egui, which is much more customizable and useful?
even if you may get by with other particular engines, (monogame my beloved, never gonna take my control flow away) you will never find success as easily without running into a load of crap that makes you wish youd rather had gone cold turkey while you had the chance and are now stuck with a node tree which just will not work for what you want, or a game that is bug ridden or just flat and relies entirely on the non-coding related aspects to take it to success.
@@triducal the "safe" language doesn't have strict specification, unlike Ada. It only has one compiler with no guarantees to backwards compatibility in the future. The whole "unsafe" thing can and *WILL* be exploited in practical applications. Rust is also infamous for its long compilation times, much worse than C/C++.
In fact, NASA, SpaceX and automobile manufacturers still use C/C++ for dangerous tasks, because in fact language "safety" doesn't matter as much as performance, reliable testing process and having alternative tech stack (and, well, C/C++ do that perfectly).
I do agree that safety matters, but Ada and many functional language do it much better than Rust. Whole "niche" of Rust is fanatism-driven.
8:27 Literally me,watching every tutorial...😅🤌