2020-11-08

I’ve been making super minor changes since I started this game, focusing mostly on getting the blocks to drop in a way that doesn’t halt the entire game play.

Since the game is (currently) written in NextBASIC the maths and logic to check which blocks to drop and how far is pretty intensive even when running at full tilt at 28Mhz.

If you watch the video below you’ll notice when I’m selecting the blocks on the far right of the grid, the time it takes to clear out the blocks increases giving the impression of a hang:

So I’ve been focusing on how to improve perceived performance.

• Instead of scanning the whole grid, I capture the range of min-x, max-x and min-y (which is inverted) - so this speeds up the scanning process
• During the scanning and clearing process, I’m repeatedly calling the readInput so that the pointer can still move whilst the work is being done - this reduces the feeling that the game has hung during larger scans
• During the scan process (the tag routine), if there’s more than one block tagged, I immediately start removing these blocks from the display, this allows for large clearings to give visual feedback that there’s work being done, and so far has visually tricked me into thinking I can’t play until the animation is complete

With the fundamental game play mechanics in place, I’m now adding the details to the game like the “next stage” overlays, buttons to quit or retry, an interface to change the game seed - and, if technology permits, a way of submitting high scores online, via the spectrum…