Regarding events remaining in the queue for two Updates at 7:14 Does it mean if a function checks for the event it can happen that it activates twice? Once in update A after the event happened and once in update B before the event gets removed from the queue? Or is there some internal logic that prevents that?
Great question! A single system won't process (i.e. read) the same event more than once. EventReaders keep track of the events consumed internally on a per-system basis. Therefore, an EventReader associated with a particular system will never read the same event twice.
I want to thank you for your efforts. Your videos have been very helpful in understanding bevy engine over the past few days. I appreciate your kindness 💐❤
So happy to see a new video! Appreciate you all taking to time to teach while still working on a fully fledged game. I wish you the best on your game’s development and release!
Absolutely the best Bevy tutorial that exists. I know there are already breaking changes in Bevy 0.13 for some aspects of this series, but even having this as a reference to go back to has been tremendous. I've watched each video at least twice and your timeline breakpoints are so highly appreciated.
Working on a game whilst producing educational content takes a lot of time and effort for sure! Take your time! Also hope to see some talks or discussion videos about your game development journey to discuss pros and cons, struggles whilst developing and making when making the game. When it is done and published of course so that is a ways away.
Dude, i really need to thank for for the fantastic work you're doing with this youtube channel, i'm enjoying all your videos, i've tried many game engines (Unity, Godot, Pygame) but none of them have a workflow like bevy does and i've been searching for a place to learn more about it, and here i am
Awesome series! I appreciate the effort you put in to create this gem. Hopefully you'll find time and energy to continue it. Good luck with your game-development!
Another fantastic episode in the series. Just found this series in the last couple of days and greatly enjoyed watching all the videos so far. Much respect for creating such clear, polished, high quality content. I hope the game development is going well. Definitely take your time with these and hopefully find some way to monetise it all so you can keep going.
Another great video ! Huge thank you for keeping on this series. If I may give one suggestion however : It's hard to read your code when you are too low on the the screen (ex: 24:06). If you're not on fullscreen, the UA-cam overlay comes in front of your code. And if (like me) you activate subtitles, they can override your code too (even if I can move them, but I like to have them at the bottom as it's the more common).
Thanks for making these. This is definitely the highest quality Bevy tutorial series, in terms of explaining necessary concepts in sufficient depth. Watching these has helped me get rubber to hit the road on my own Bevy projects. And good luck with your game! You should put a link to wherever it will be available on release, if you have one -- I'd like to be able to bookmark it so I can keep up to date directly.
I'm following along using bevy 0.13. So far it's all been good, apart from a few renames that I had to figure out. However, I can't get the systems to stop running when moving to a state that is not InGame. I have tried printing out the state at every frame and it changes correctly, but the systems that should not be running, keep doing so. Anyone else having similar problems? note: add_state() has been renamed to init_state() in 0.13. I am using init_state()
Im having the same problem but I experimented some and discovered that the problem is only happening in the configure_sets func, but it works fine everywhere else.
Another note after an evening of head-scratching. I was looking to overlay some bevy_ui bits and pieces on this. However, my initial efforts would display a text-box only for the first frame or so of the game - until the assets had loaded, effectively - then disappear. After a great deal of debugging I realised that *almost everything* has a Transform component - in particular, the bevy_ui nodes do; furthermore, these might use different coordinate systems, meaning the Translation will fall foul of the tests in despawn_entities. Working with a UI, the despawn_far_away_entities was blowing away my UI! I note in your git repo you've added a `With` to that system, but this didn't make the cut for the video. Worth calling out if people are following along.
question on collision handling: why indirect the collision event sending via a handle_collisions, rather than emit the events directly in the "physics" layer - that is, the collision_detection system?
Partially answering my own question here: there are tag components (asteroid, etc) on entities that're used to winnow out intra-type collisions (asteroid/asteroid etc), leaving only the inter-type (missile/asteroid etc) ones to forward to the event system.
The only improvement for this tutorial series that I can think of is to change the default fps to 30 max. That way I can watch the videos on any older hardware and even on my big TV in high resolution (while following the tutorial on my laptop). Anything over 30fps does not make sense on youtube if there are no fast movements. On UA-cam, high resolution is almost always more important than framerate (and sound is often more important than video quality but you are already doing well there).
I might have missed something, but isn't there a bug? spawn_spaceship could happen before destroy_all_entities therefore it would destroy our spaceship. Yes, then we would enter respawn_spaceship, but, on occasion, we would wait several cycles for spaceship to spawn after all entities are destroyed
There isn't a bug. There's a schedule called StateTransition (which is run before Update) where all the systems with schedules of OnEnter(State), OnExit(State), etc. run. Both the spawn_spaceship and despawn_all_entities systems run during this schedule, specifically during OnEnter(GameState::GameOver). The despawn_all_entities system gets a query full of all of the existing entities at the time of entering the GameOver state, and individually queues a command to despawn each one of them. The spawn_spaceship system gets run during that same schedule (possibly before, during, or after despawn_all_entities), and queues one command to spawn a new entity (our spaceship). For the despawn_all_entities system to despawn our newly spawned spaceship, it would have to both run after the spawn_spaceship system (which very much can happen), AND the queued command to spawn the spaceship would have to execute before despawn_all_entities is run (which DOESN'T happen because there's no flush point between the two systems). So with this setup, despawn_all_entities will never despawn our newly spawned spaceship.
Regarding events remaining in the queue for two Updates at 7:14
Does it mean if a function checks for the event it can happen that it activates twice? Once in update A after the event happened and once in update B before the event gets removed from the queue?
Or is there some internal logic that prevents that?
Great question! A single system won't process (i.e. read) the same event more than once. EventReaders keep track of the events consumed internally on a per-system basis. Therefore, an EventReader associated with a particular system will never read the same event twice.
Ok that's nice, thanks! @@ZymartuGames
I want to thank you for your efforts. Your videos have been very helpful in understanding bevy engine over the past few days. I appreciate your kindness 💐❤
I hope you eventually find the time to continue this series. It's been a great help and really sets the standard for bevy tutorials.
please finish the tutorial, you have covered almost all basics of the engine and you have done a great job
Started the day with a cup of freshly brewed coffee, and when I opened my computer I was greeted with a new tutorial. A perfect start of the day!
Haha. Glad to hear!
This is such a good playlist. Keep us updated on the game you guys are making.
This is simply the best bevy tutorial available on youtube
This is the most exciting announcement for me today!
Haha that's awesome to hear!
Yay! I've been looking forward to the next video in the series. Thanks @ZymartuGames for continuing to publish these.
So happy to see a new video! Appreciate you all taking to time to teach while still working on a fully fledged game. I wish you the best on your game’s development and release!
Thanks!!
Thanks for uploading!! I was afraid you would let this fade away, but I imagined developing your game would take all your time!
Can't wait to play it!
Absolutely the best Bevy tutorial that exists. I know there are already breaking changes in Bevy 0.13 for some aspects of this series, but even having this as a reference to go back to has been tremendous. I've watched each video at least twice and your timeline breakpoints are so highly appreciated.
we miss youuuu
Working on a game whilst producing educational content takes a lot of time and effort for sure! Take your time! Also hope to see some talks or discussion videos about your game development journey to discuss pros and cons, struggles whilst developing and making when making the game. When it is done and published of course so that is a ways away.
Dude, i really need to thank for for the fantastic work you're doing with this youtube channel, i'm enjoying all your videos, i've tried many game engines (Unity, Godot, Pygame) but none of them have a workflow like bevy does and i've been searching for a place to learn more about it, and here i am
This one showed how to use events like events and not like some resource. So you can make system to be run only if event was sent!
Great tutorials! Hope to see new episodes soon😅
As always, I really apriciate your videos, thank you for the wonderful work you do for the community.
I hope your tutorials will be updated all the time
Oh wow the timing of this episode is perfect for me! =)
Glad to hear!
Hey keep em coming! Your videos are great
New episodes will come? Really your explanation is great
Good work sir. Can't wait for Ep6.
In bevy version 0.13, add_state was changed to init_state.
Was about to comment this
Happy to see a new video!
Enjoy!
Thank you for the effort you put in here, it's really given me a great perspective on the mechanics of game dev.
Awesome series! I appreciate the effort you put in to create this gem. Hopefully you'll find time and energy to continue it. Good luck with your game-development!
Another fantastic episode in the series. Just found this series in the last couple of days and greatly enjoyed watching all the videos so far. Much respect for creating such clear, polished, high quality content. I hope the game development is going well. Definitely take your time with these and hopefully find some way to monetise it all so you can keep going.
Thank you so much for these videos, they have helped me tremendously to get started with the framework.
discovered this channel only a few weeks ago, and was looking forward to this one - thanks!
they're incredibly helpful
Another great video ! Huge thank you for keeping on this series.
If I may give one suggestion however : It's hard to read your code when you are too low on the the screen (ex: 24:06). If you're not on fullscreen, the UA-cam overlay comes in front of your code. And if (like me) you activate subtitles, they can override your code too (even if I can move them, but I like to have them at the bottom as it's the more common).
Noted! Thanks for the feedback!
I am very happy that you are back!
Glad to hear you are still watching!
Thanks for making these. This is definitely the highest quality Bevy tutorial series, in terms of explaining necessary concepts in sufficient depth. Watching these has helped me get rubber to hit the road on my own Bevy projects.
And good luck with your game! You should put a link to wherever it will be available on release, if you have one -- I'd like to be able to bookmark it so I can keep up to date directly.
Finally.... a new video..... thanks.
oh!! Our friend Zymartu! I waited for you!
Thanks for sticking around!
If you are using Bevy >= 0.13 then add_state is renamed to init_state.
Thank you for your tutorials! Its great!
Glad you continue to enjoy them!
Amazing. Hope you will find capacity to record more videos any time soon
This series has been a HUGE help. Thank you so much!
Thanks. you are really helping me get in to Bevy. I hope you keep making more quality videos for us
Welcome back!!!
Thanks! Glad you are still watching.
Great job, I learned a lot from this video, appreciate so much.
I'm following along using bevy 0.13. So far it's all been good, apart from a few renames that I had to figure out. However, I can't get the systems to stop running when moving to a state that is not InGame. I have tried printing out the state at every frame and it changes correctly, but the systems that should not be running, keep doing so.
Anyone else having similar problems?
note: add_state() has been renamed to init_state() in 0.13. I am using init_state()
Im having the same problem but I experimented some and discovered that the problem is only happening in the configure_sets func, but it works fine everywhere else.
Another note after an evening of head-scratching.
I was looking to overlay some bevy_ui bits and pieces on this. However, my initial efforts would display a text-box only for the first frame or so of the game - until the assets had loaded, effectively - then disappear.
After a great deal of debugging I realised that *almost everything* has a Transform component - in particular, the bevy_ui nodes do; furthermore, these might use different coordinate systems, meaning the Translation will fall foul of the tests in despawn_entities.
Working with a UI, the despawn_far_away_entities was blowing away my UI! I note in your git repo you've added a `With` to that system, but this didn't make the cut for the video. Worth calling out if people are following along.
Good job.
New video, cool!
Hope you enjoy it!
Finally, you are great 😸
Haha, thank you! Glad to hear you are still watching!😸
Continue The Series Please.
Thanks, your videos are very helpful.
wonderful tutorial series, and i hope your game is coming along nicely too!
In Bevy 0.13, add_state is renamed to init_state
Thank you!
You're welcome!
question on collision handling: why indirect the collision event sending via a handle_collisions, rather than emit the events directly in the "physics" layer - that is, the collision_detection system?
Partially answering my own question here: there are tag components (asteroid, etc) on entities that're used to winnow out intra-type collisions (asteroid/asteroid etc), leaving only the inter-type (missile/asteroid etc) ones to forward to the event system.
The only improvement for this tutorial series that I can think of is to change the default fps to 30 max. That way I can watch the videos on any older hardware and even on my big TV in high resolution (while following the tutorial on my laptop). Anything over 30fps does not make sense on youtube if there are no fast movements. On UA-cam, high resolution is almost always more important than framerate (and sound is often more important than video quality but you are already doing well there).
🎉🎉
Please upload more tutorials 🥺
How is your game development going?
I might have missed something, but isn't there a bug? spawn_spaceship could happen before destroy_all_entities therefore it would destroy our spaceship. Yes, then we would enter respawn_spaceship, but, on occasion, we would wait several cycles for spaceship to spawn after all entities are destroyed
There isn't a bug. There's a schedule called StateTransition (which is run before Update) where all the systems with schedules of OnEnter(State), OnExit(State), etc. run. Both the spawn_spaceship and despawn_all_entities systems run during this schedule, specifically during OnEnter(GameState::GameOver). The despawn_all_entities system gets a query full of all of the existing entities at the time of entering the GameOver state, and individually queues a command to despawn each one of them. The spawn_spaceship system gets run during that same schedule (possibly before, during, or after despawn_all_entities), and queues one command to spawn a new entity (our spaceship). For the despawn_all_entities system to despawn our newly spawned spaceship, it would have to both run after the spawn_spaceship system (which very much can happen), AND the queued command to spawn the spaceship would have to execute before despawn_all_entities is run (which DOESN'T happen because there's no flush point between the two systems). So with this setup, despawn_all_entities will never despawn our newly spawned spaceship.
I've extended my query like this `Query` to prevent that from happening. Works fine
the voice audio was better in the previous episodes
Ok, the silence is weird.. . what's wrong with Bevy, man?
bevy 0.13 is out, redo the whole series