GitLab

The GameManager provides a way for systems to schedule a transition back
to the heaven.

Add a new method to the AngelShiftImpl trait which angel shifts use to
configure any shift-specific entities, resources, and ECS systems.

As a first implementation, properly implement this for the bottle angel
shift and move the `collect_bottledrops` systems here instead of it
being a generic system.

Doing it this way, each shift can decide which levels are compatible
with it and this way we don't require that each level supports all
possible shifts.

Generate a random shift for the player when entering the heaven.
Display all meta-data for this shift in the GUI.

A new module to contain the "logic" for all angel shifts.  As an
example/first shift, introduce a "Bottle Angel Shift".

Shifts are abstracted as a trait object which contains the actual shift
logic and is dynamically selected based on RNG.

Tell a player how many hours they'll gain by doing a certain shift.

Display a cound of collected angel hours and the amount of hours still
needed for getting a shirt (currently hard-coded to 30h).

Add the count of angel hours to the player component.

The player component hold information which should stay persistent
across the game-runs and thus needs to be passed through the different
game-states.  Do this by instanciating it in the heaven and then passing
it through the level-loading state into the in-game state.

Small cleanup so it is more obvious what the primary objective of the
heaven is.

Link to live game in README

See merge request !28

Rahix authored Dec 26, 2020 and neosam committed Dec 26, 2020

We're live now at

    https://engel-simulator.club

Rahix authored Dec 26, 2020 and neosam committed Dec 26, 2020

Go directly to heaven when building with `wasm-pack build --dev`.

See merge request !27

Hiding the `DIV` which stores the SVG level when it's loaded
in order to prevent it from popping up during the loading
screen.

See merge request !22

Closes #13

See merge request !25

The level loader verifies if the width and height attribute of
the SVG file matches its viewBox and fails with an error if
not.

See merge request !24

Simon Goller authored Dec 24, 2020 and neosam committed Dec 25, 2020

Sprites were loaded during the level_loading und the level images in
InGameState::new() but they were never cleaned up.  As soon as the
InGameState starts several times, this would lead to a memory leak.
This commit contains a separate treatment for sprites and the level
images:

Since sprites are stored as a global Enum, they will now be initialized
only once on the first loading state.  When loading the images, they
check if the ImageHandle is already registered on the renderer to
determine if loading is required.

Level foreground and background on the other hand are dynamically loaded
in the InGameState.  The InGameState got a new attribute
`registered_images: Vec<resources::ImageHandle>` which stores all
`ImageHandle` of dynamically loaded images.  On deinint, they
get deregistered from `Rendering`.

More features

Closes #16

See merge request !23

The previous code did not work properly when more than a single
collision is happening at the same time.  The two biggest issues were:

1. For optuse angles, the final velocity would actually point backwards
   from the intended movement direction, causing the entity to wiggle
   around.

2. For acute angles, the final velocity would still contain components
   pointing towards some of the normals, leading to the entity moving
   into some of the colliders.

To fix this, refactor the code such that we can, after calculating the
final velocity, check that it does not have any remaining components
towards any of the collision normals and that the final velocity is
still pointing somewhat towards the original movement direction.  If any
of those checks fail, no movement is performed at all.

I am not sure if this is the most efficient way to implement this but
I was not able to find a better solution.  If someone who is more
familiar with analytic geometry has a better idea, please share!  The
comments in this implementation should explain the conditions which must
be upheld.

Makes it a bit cleaner but more work still to go.

Support a simple `transform="rotate(x)"` rotation on rectangle colliders
by properly transforming it into our internal data format.

If a collider also has a rotation component, apply it to the collision
object as well.

Hopefully some people will accidentally click on it and start
contributing ;)

This is a temporary measure to provide some interactivity.  In the
future, we'd want to actually do something more useful here.

Add a proximity only sensor collider type for collectibles / obstacles.

Player and static colliders should go into different groups so static
colliders don't self-collide.

Using integer coordinates instead of floats means that the browser won't
have to perform subpixel rendering which would reduce the drawing speed.

The browser starts sending repearing keyDown events after a while.
Ignore them and only report a single event to the active state.