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.
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.
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.
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.
I've taken a lot directly from the Bevy UI button example.
(https://bevy.org/examples/ui-user-interface/button/)
I'll make it look better later. For now, it just needs to exist. Onward
to the UI operation system!
I want the different "scenes" to be their own plugins for ease of setup
and reading.
The main menu plugin has been renamed to have "Plugin" first. This is so
the lexical sort in the docs places all the plugins next to each other.
The "get-ready" plugin has been given an empty struct and an
`impl Plugin` to match the main menu plugin. I've started the game over
scene, but left it unimplemented.
Closes#16
Bevy provides Deref and DerefMut derives, so that's nice. I'm not sure
it makes any sense to keep the field private since those derefs expose
the Vec2 anyway. I added an `impl Default` anyway, though.
The non-gameplay scenes are really just a bunch of widgets. I'm going to
put them all together and then bundle the functionality with some
exported plugin builders.
I'm not sold on the name, but anyway.
This module will hold the systems that power the main game mechanics, as
well as a few extra items to support that (in particular, the Lifetime
component).
The player will be respawned, their lives decreased, and the board
cleared. The UI doesn't update, and the sudden snap to a freshly reset
board is quite jarring. The state transition to GameOver stops the game,
but there isn't anything else running in that state so it just looks
frozen.
Basically, there's a ton left to do, but technically I have handled
player ship destruction!
The spacebar fires the gun, bullets are spawned on top of the ship with
a velocity that sends them forward (relative to the ship).
I still need a despawn mechanism, and a fire rate control. To despawn
things, I'm already planning a `Lifetime` component. For rate of fire,
an additional component will be created and attached to the player ship.
The ship in Asteroids isn't expected to spin up while holding a steering
direction, but that's exactly what I just made it do.
Fix that problem by assigning, not accumulating, the angular velocity
for the ship.
The rotation component is also redundant with Bevy's transform
component.
This new component and system fill the physics role, but the input
handling code needs to be updated.
Player steering still functions because it uses the `Rotation` component
to direct the force vector. The force is correctly applied to the linear
velocity vector. An improvement would be to have a force/impulse
accumulator so I could account for mass, but I'm not going to do that
right now.
The position component is redundant with the built-in Bevy Transform.
I've updated the velocity integrator to use the transform directly.
Physics still works, but things still set their initial locations
through the Position component. I'll need to fix all those call sites.
The physics sim bits (that aren't Rapier2d) are now in their own
submodule. I've included the `Wrapping` marker component because it
doesn't really have anywhere else to live, and it's kinda sorta related
to the physics. It controls the motion of objects... that's physics. :p
There are name collisions between Rapier2d's `Velocity` and my own, but
that's a problem for later. I've used more specific type paths where
necessary to maintain the previous behavior.
The `physics::Position` component can go away completely. It's just an
extra copy of some of the built-in `Transform` data. I'm pretty sure it
only exists because I didn't realize I could rely on directly
manipulating the transform when I started this project.
