To my understanding, env vars cannot be passed to spec files because they run on browser. But with karma-env-preprocessor they can be written in.

Separated from PR #31 to reduce scope and because it's not necessary for the tests to function. Assess whether this will actually provide a performance boost.

Split from #31 . Not slowing the build down significantly but may be worth looking into whether this step can be cached.

Right now, moving platforms check for hardcoded values of -100 for left side and 600 for right side to determine when to reverse direction. Fix this by instead checking for game width + offset on right side and 0 + offset on left side, where offset is the displacement of the camera from 0 on the x-axis.

Test scenes such as lava scenes load extremely quickly, making the test suite fail completely since they end up starting before the onTestStart handler can add the test case-specific objects to the suite. I tried making the preload function async and that didn't appear to work either.

Investigate into how the test scenes can be initialized in a more predictable fashion. (ie. test cases should ALWAYS run AFTER the scene has loaded completely)

This appears to be more of an issue on the headless integration tests, but if the delta were to spike really high, then the player will jump and fall much faster than they are supposed to. The delta is there to keep the movement calculations synced with render speed (e.g. if render speed becomes half of what it usually is, then simulation will calculate movements using twice as large delta to compensate), but it should not be higher when it's not supposed to.

Study up on these resources:

• https://gafferongames.com/post/fix_your_timestep/
• https://gafferongames.com/post/integration_basics/

Assess whether this issue can be fixed using Phaser engine features, or if a makeshift solution with a numerical accumulator needs to be baked into scene update. Also, if this is only an issue that happens in integration tests, then possibly close this if frame rate can be mocked with a fixed value without performance/correctness issues.

https://www.npmjs.com/package/karma-typescript-mock

Leaving this here while working on #47. To be closed when that issue is complete.

Collision detection does not take into account fast moving objects. With the issue in integration tests right now (#37), if the player goes too fast due to delta spike, then the player will go past the ground.

All collision detection should take into account speed. If object is on one side of another object on the first frame but will be on the other side of the object on the second frame, then the object should be pushed back on the second frame.

Tests to be added (list to be updated, and issues can be created in the future for cases I've missed):

Integration Tests

Player

• Player bounces from surface
• Player falls down faster if space is held
• Player can move left
• Player can move right
• Player can stick to ground when fast falling
• Jump height is increased when player fast falls and releases when on ground
• Player eventually falls to ground after charged jump
• Player can collect pickup
• Player is knocked back when hitting falling obstacle
• Player cannot move past horizontal boundaries will be covered under Level

Background

• Background scrolls down as player goes up
• Background loads new tile if scrolled down past threshold

Lava

• Lava moves up
• Lava can be sped up
• Lava can be slowed down temporarily
• Lava speed is increased when further away from player

Moving Blocks

• Block can move horizontally
• Block's horizontal speed is reversed when hitting side of game's dimensions

Block Chunks

• Blocks can be generated from chunk
• Different chunk types can be selected when creating chunk
• Chunk despawns when all blocks in chunk pass bottom of camera by theshold

Falling Obstacles

• Obstacle can fall down
• Obstacle despawns when it passes bottom of camera by threshold
• Obstacle spawns above top of camera

Score System

• Score can be updated
• Score update is triggered when player moves up past threshold
• High score is updated when score surpasses high score
• High score is saved to local storage

Game Over

• Displays "Game Over" text
• If user beats high score, high score message appears
• If user does not beat high score, high score message won't appear
• Displays button to play again
• Game is able to restart when play again button is clicked

Level

• Player cannot move past left bounds
• Player cannot move past right bounds

Unit Tests

ChunkHelper

randomOffset

• Returns lowest offset
• Returns highest offset
• Returns an offset between lowest and highest offsets

randomSpeed

• Returns lowest speed
• Returns highest speed
• Returns a speed between lowest and highest speed
• Returns negative speed if sign is flipped

Remainder of classes TDB since the rest of them rely on Phaser constructs, and it's not certain how difficult it'll be to mock out Phaser functionality to be worth it.

A platform that breaks when player steps on it.

If player held down space for more than a certain time threshold, then that may indicate that the player deliberately held down space and is aware of the hold down mechanic. There would be no need to show the space bar graphic in this case.

Right now it's not easy for the player to see where the lava is.

Two ideas:

• Modify screen dimensions to be narrower and wider - still keep the game world the same size but there will just be more to see.
• Add a UI marker at the bottom of the screen that will appear when the lava gets close but not close enough to appear on the screen - to signify to the player that's it's getting close

Once it's decided which ideas to go with, make separate issues for each.

Two parts to this:

1. Consider refining the test plan for Lava tests specifically, as I did not clearly define how the lava was to behave when I originally developed the feature, but ideally it should be more clearly defined.
2. Lava speed up after 10 seconds test is flaky, example output from one of the CI runs:

1) should be able to speed up after 10 seconds
 
     Lava
 
15 06 2020 05:49:13.577:WARN [reporter]: SourceMap position not found for trace: AssertionError: expected 45.08331750021165 to be above 45.670042499482946
 
    at Object.<anonymous> (base/test/Lava.spec.js?59f07e7a040ef901a70b8b4962f0802e56e327b5:44:58)
 
    at Generator.next (<anonymous>)
 
    at fulfilled (base/test/Lava.spec.js?59f07e7a040ef901a70b8b4962f0802e56e327b5:4:58)
 
     AssertionError: expected 45.08331750021165 to be above 45.670042499482946
 
    at Object.<anonymous> (test/Lava.spec.ts:41:51 <- test/Lava.spec.js:44:58)
 
    at Generator.next (<anonymous>)
 
    at fulfilled (test/Lava.spec.js:4:58)

Don't really have any good guesses right now as to why it did not speed up as expected. Look into whether this is a problem with my test code, if there's a problem with the specification of Lava behaviour, or if there's a bug.

https://prettier.io/docs/en/rationale.html

Add test coverage with codecov and https://istanbul.js.org/ or some other combination of tools.

Due to increased complexity of #29, remaining work has been added as a new issue to work on.

List has been carried over from #29, and will be updated:

Integration Tests

Player

• Player bounces from surface
• Player falls down faster if space is held
• Player can move left
• Player can move right
• Player can stick to ground when fast falling
• Jump height is increased when player fast falls and releases when on ground
• Player eventually falls to ground after charged jump
• Player can collect pickup
• Player is knocked back when hitting falling obstacle
• Player cannot move past horizontal boundaries will be covered under Level

Background

• Background scrolls down as player goes up
• Background loads new tile if scrolled down past threshold

Lava

• Lava moves up
• Lava can be sped up
• Lava can be slowed down temporarily
• Lava speed is increased when further away from player

Moving Blocks

• Block can move horizontally
• Block's horizontal speed is reversed when hitting side of game's dimensions

Block Chunks

• Blocks can be generated from chunk
• Different chunk types can be selected when creating chunk
• Chunk despawns when all blocks in chunk pass bottom of camera by theshold

Falling Obstacles

• Obstacle can fall down
• Obstacle despawns when it passes bottom of camera by threshold
• Obstacle spawns above top of camera

Score System

• Score can be updated
• Score update is triggered when player moves up past threshold
• High score is updated when score surpasses high score
• High score is saved to local storage

Game Over

• Displays "Game Over" text
• If user beats high score, high score message appears
• If user does not beat high score, high score message won't appear
• Displays button to play again
• Game is able to restart when play again button is clicked

Level

• Player cannot move past left bounds
• Player cannot move past right bounds

Unit Tests

ChunkHelper

randomOffset

• Returns lowest offset
• Returns highest offset
• Returns an offset between lowest and highest offsets

randomSpeed

• Returns lowest speed
• Returns highest speed
• Returns a speed between lowest and highest speed
• Returns negative speed if sign is flipped

Remainder of classes TDB since the rest of them rely on Phaser constructs, and it's not certain how difficult it'll be to mock out Phaser functionality to be worth it.

These tests only need the one platform that's actually under test, but the extra platform is there for the player to get into jump state. It shouldn't have to be there - the test can be written so that player goes into jump state automatically. This will make the test case easier to understand.

When release is ready, merge it into a release branch, which will then kick off build process that places compiled output into gh-pages branch.

PhaserTester would create a PhaserTestCase for each test, which would contain things such as:

• keyUp
• keyDown
• test text
• other objects related to the test
  • test scenes could provide an export method that exports scene-specific test objects out into this test case object that the caller of the test can then retrieve

At the end of the test case (in afterEach) the test case instance can be disposed of with a dispose method that would remove all test objects from scene and clear all relevant event handlers.