The card itself is transparent, but it still has a size of 30% of the
viewport because the bar is based on the size of it's container.
The start bar and text can still be green and red, respectively, but the
light blue was completely out of place.
Page visitors may be surprised by the sounds and not know how to turn
them off. The answer is "you don't", but practically the browser tab can
be muted instead.
The canvas element no longer exists in the page source. Instead, there
is a div styled to look similar and contain a button. The button is
styled to match the ones in the Bevy app. When pressed, the button
creates the canvas element, replaces the fake canvas div, and loads the
WASM to do it's thing.
This will ensure the user has interacted with the page before the game
starts, thus allowing the sound to play correctly.
It doesn't re-load the game if the user quits. I'd like to figure out
how to do that.
The need to push the button isn't immediately obvious. It should be over
top (or in place of) the canvas to best convey that the user must start
the game.
I did the thing againnnnn. The Makefile thinks the sound assets are
constantly out-of-date because the folder that contains them technically
changes any time a file is added or removed from the folder.
1. "out/assets" is created, it is up-to-date
2. "out/assets/example.ogg" is created, it is up-to-date
3. Parent folder "out/assets" has it's mtime updated because it's
contents have changed. It is newer than it was at step 1, and newer
than the .ogg file in step 2.
4. run `make` again
5. "out/assets" is up-to-date, nothing changes
6. "out/assets/example.ogg" is OLDER than one of it's dependencies
("out/assets/"), and is rebuilt.
7. "out/assets" got new contents, so it's mtime was updated again.
The cycle isn't infinite, but it will always try to rebuild the sound
files. The fix is to consider the containing folder to only be an
ordering dependency rather than a substantive dependency. The former
only needs the dependency to be made first, where the latter considers
the dependency to be part of the target file. The containing folder is
not part of the sound files, so "rebuilding" the sound files when the
folder changes is complete nonsense.
Makefiles are pretty strange things.
There is a new wildcard target which will copy any .ogg file from
"assets/" into "out/assets". On it's own, it does nothing -- it only
knows how to create the output file by copying the input one.
To drive this, a list of output assets must be created and depended upon
by the main build target(s). I don't want to manually maintain an asset
manifest in a Makefile, so I've achived this by wildcard matching
anything in the "assets/" folder, then rewriting the prefix to be
"out/assets/". This list is in a variable, which is now part of the
dependency list for the main build target(s). All files will be
installed, but only when they are out-of-date. Excellent.
The asteroid circles have been replaced with polylines. I was going to
do a regular triangle mesh, but I don't want to figure out GLTF
loading or manually chunking the points into convex hulls.
Asteroid materials are now all populated and their GameAsset getters are
indexed correctly. I'm not sold on the size based color selection.
Later, I think I'll either remove the extra colors or let each of them
randomly apply to any asteroid.
The bullet is now a short line segment. Apparently I already wired in
the rotation logic, so pointing it correctly out of the ship already
works.
The player's Ship now has an AudioPlayer component constantly looping a
thruster sound effect. It starts paused and is only resumed when the
player fires the thruster.
As noted in the TODO comment at the top of the input_ship_thruster(...)
system, I need to figure out if I want to start using the `Single<>`
query parameter instead of a `Query<>` and then doing my own
null-ability checks (like what it does now).
Firing the weapon now makes a sound. I've implemented this by spawning
the playback component on the bullet rather than the gun. This seemed
easier than figuring out how to reset a playback component that lives on
the ship entity -- although thats probably better for memory access
patterns.
I started to work on weapon fire sounds and realized I don't know if the
entity and/or component get removed after playback ends. It turns out
that they DO NOT!... unless told to do so, like this.
There hasn't been a README this whole time... I guess there hasn't been
anything I need to immediately communicate to someone looking at the
source repository.
There is now a README so I have somewhere to record the extra licensing
information (for the Kenney asset).
It's a simple one-shot sound clip that gets dispatched as one more part
of the ship impact routine.
The GameAssets struct has been updated to have an array of handles for
audio assets (just the one, for now).
This sound file, and the next several, are all from Kenney
(www.kenney.nl).
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.
