Bevy 0.17 introduces this idea of "Messages" which mostly replace the
previous usage of "Events." The old events still exist, but are meant
more for targetted actions -- something happening and immediately
triggering a function call on an observer.
Bevy 0.17 is out and I'm going to get started on an upgrade. Upgrading
dependencies will be it's own commit, as will many of the fixes. This
way I can cherry-pick anything, if need be.
The Alsa and Udev system dependencies are only required on Linux. The
WASM/WASI build doesn't use them, so they don't need to exist in the
build container.
I have figured out the `.dockerignore` file so I don't have to do manual
context size management like before.
The Dockerfile now uses the Makefile to ensure image builds contain the
same thing non-image builds would.
Variables that a package consumer might want to adjust should be placed
at the top of the file so they are immediately visible. Any constants
shall live below those (just the SRC folder, really).
Bevy creates it's own canvas element by default, but the custom page
defines its own. This makes Bevy go find that one.
The window sizing still works -- it simply resizes the canvas upon
starting. I'm not sure if I'll change that or remove the size from the
HTML. That's a tomorrow problem.
When the player gets a game-over, the debris is spawned and then frozen
in place as the physics system gets turned off. I can make sure it never
appears by writing the state change and returning early from the
function.
This means the asteroid despawning needs to happen before that point,
otherwise the asteroids would be left on screen.
I'm stealing the thruster mesh, which itself is actually the ship's
mesh, to draw the debris particles. I'll come back and make the scatter
a bit better at some point, but for now it's passable.
I'll be using this to make a sparkling effect on the debris field left
behind from a destroyed ship.
It can also be used to do the temporary invincibility effect when
(re)spawning the player.
Closes#23: Main menu's start button doesn't run the get-ready timer
I made the start button go directly to `GameState::Playing`, which is
not actually the right state for beginning a new game. Swap the states
and everything works again.
There is now a `Weapon` component which is just a timer for the gun's
fire rate. It is ticked every frame, clamping at the "ready" state (0
time remaining).
The ship spawns with this thing, and the `input_ship_shoot` system has
been updated to use it.
Now it works!... but it runs every single frame, probably causing a
bunch of unnecessary text rendering and UI layout operations. I'll have
to come back and make it event-based at some point.
The `rand` crate eventually depends on `getrandom` which requires a
different feature set when running in the browser. WASM has no OS, and
so no RNG provider... but the browser, specifically, has one that the
JavaScript runtime can touch. Enabling the "wasm_js" feature on
`getrandom` allowes it to use this backend.
An extra config option must *also* be passed to `rustc`. THis can be set
through the environment, or the config.toml. I've chosen the latter so I
don't need to think about it very often.
I marked 0.2 at some point, so I guess I should keep incrementing this
during development. The menus are finished, which is as good a
checkpoint as any.
