Asteroids in Rust with the Bevy Game Engine

Asteroids in Rust with the Bevy Game Engine - Let's Code!

Рет қаралды 5,278

4 ай бұрын

An Asteroids implementation I built on the plane to and from RustNation UK. Using Bevy, Rust, and bevy_xpbd_2d.
Code shown in this video (git tag yt-2024-04-01): github.com/rust-adventure/asteroids/tree/yt-2024-04-01
Rust Adventure Discord: discord.gg/3BeM3Y6fNJ
# Chapters
00:00 Asteroids Overview
00:42 Cargo.toml
01:32 bevy_xpbd_2d debug-plugin
01:59 main.rs
04:30 lib.rs
07:24 laser_meteor_collision
08:36 assets and custom assets
09:52 bevy_plugin_kenney_spritesheets
16:14 The types have the functions
16:51 Resource based Pause system
19:07 with_children vs add_child
20:17 player ship movement
22:43 MovementPlugin
24:49 SpawnButton
25:20 Player Ship
25:53 examples
26:22 Asteroids!

Пікірлер: 10

@MaximilienCruz 4 ай бұрын

Great coverage of how you made it with Bevy. I learned a lot from your custom resource loader and how you store handles in resources from it! Thanks

@ajinkyax 4 ай бұрын

Great video. Can you please do a small video on particles if I'm not asking too much. I loved your Bevy 2048 video course. Learnt about Array manipulation

@chrisbiscardi 4 ай бұрын

Anything about particles in particular? I have a couple videos on bevy_hanabi but its probably time to do an updated one. I filed an issue to add them to the Asteroids game -- github.com/rust-adventure/asteroids/issues/2 Glad you enjoyed 2048!

@ajinkyax 4 ай бұрын

@@chrisbiscardi thanks. Particles, when we collide or maybe something like fireworks.

@toonspex 4 ай бұрын

Great video! Nice to see how you structure things and hear some reasoning behind it. Just one question: Why use a resource for the Pausable instead of another app state? I think you can have multiple, right?

@chrisbiscardi 4 ай бұрын

You can have multiple states and it works just fine. In fact, there's an open PR[0] that looks like its about to merge which takes this a step further and introduces SubStates (states that only exist within other states) so it looks like I'll be revisiting this in 0.14 anyway. In this case, using Resources was an experiment. My first thought was to use SubStates but I was already aware of the above PR so I went with Resources. In the back of my mind I was curious about the design space that a bevy_plugin_pausable would require and the APIs it could offer. For example: is sending an event to pause a better API for a plugin like that? or letting people have manual control over a State/Resource. Would that plugin require additional data stored in the Resource? `.run_if(not(paused))` is kind of nice. etc. [0]: github.com/bevyengine/bevy/pull/11426 [1]: docs.rs/bevy/0.13.1/bevy/ecs/schedule/common_conditions/index.html

@notgate2624 2 ай бұрын

For the pause system I've been doing this and giving it an input_just_pressed run condition: fn toggle_pause_game( state: Res, mut next_state: ResMut, ) { match state.get() { GameState::Paused => next_state.set(GameState::Running), GameState::Running => next_state.set(GameState::Paused), } } Then using OnEnter/OnExit for the setup/teardown stuff. This would be equivalent to yours, right?

@chrisbiscardi 2 ай бұрын

yeah pretty equivalent. Although the state-based approach is likely to win out in the long run. Bevy 0.14 is going to have ComputedStates and SubStates which allow you to derive states from other states, or have states that only exist inside other states.