How does the physics engine get tested for MakeCode Arcade?
I was writing some demo code and realised I can test it to some extent with the win/lose mechanism acting as a pass/fail. If the MakeCode Arcade simulator has a “headless mode” then that could be used for testing?
That’s the from beta beta (
0.14.4 5.17.29). The PyGamer and Meowbit both pass too and seem to vary less the simulator does.
The production beta (
0.12.17 5.17.29) is both weird and amusing in its behaviour but still passes. Dropping the countdown from
5.55 seconds makes this fail which seems deserved to me.
The code (this has in it a workaround for the double event mentioned in Wall collisions and sprite vy - that workaround could be disabled to test a fix):
That test can also be run with some different
vx starting values to generate tests which are expected to fail.
BTW, what’s the intended behaviour for the simulator (in Chrome) if the user switches briefly to another non-MakeCode tab for a few seconds?
An astute reader of the code will spot that it should be
or false rather than
and true to allow disabling of the workaround by toggling the
This test passes in the current v0.14.9 version and doesn’t require the workaround anymore to filter out the second “double hits”.
Browser behaviour for tab switching is discussed in Time and switching tabs.
I’ve done some more testing in this space in light of the “tight maze issues” noted in Maze tile map navigation issues.
The tests in the program below are not exactly the same but they do test a few areas with lateral velocity and accelation. There are currently 7 failures on one type of test, it only “scores” 89 (out of 96) on
In addition to a headless mode perhaps a mode that keeps the simulator’s time slices at a fixed, non-adaptive rate would be good for testing. That would allow for reproducible results from the simulator regardless of load on the test host and performance of the interpreter.
More broken/strangeness in Mega-elastic collisions. Bouncing off a wall appears to generate extra kinetic energy and sprites with low velocity (0.0–1.0 range) do not move at the set
I’ve also got some code which tests that collisions (overlap events) occur with fast moving sprites vs thin stationary sprites and checking that the degree to which sprites which are halted pass the other stationary sprite. See code at end of Numeric output in simulator creates new graphs for every restart of code #1598.