For today’s hour of code (and a little more) I primarily reworked the code that generates mazes to try and generate more interesting play fields. In particular I was aiming at how it was possible for a maze to be generated with a path directly from the top to the bottom with nothing intervening to impede the ball progress. Once this was done I ironed out two of the remaining three (known, obvious) bugs.
The primary change to maze generation is that where previously everything was generated row by row, we now generate column by column instead. Depending on the type of item being generated, there are other various tweaks to this behaviour as well. The only thing not generated this way are the black holes, which did have their generation parameters tweaked slightly.
When arrows are generated, there is now a random number of them per column, up to a set maximum and with a minimum of one. Thus no matter what, the ball will hit some obstacle as it traverses the maze. We’re also now set up so that a parameter to the generation code indicates if there should be any automatically rotating arrows in the level, because in the original game these sort of arrows were not generated until round three. Currently this parameter is still always true for testing purposes.
The gray and bonus bricks are similarly generated, although where previously there was a percentage chance that an item would not generate we instead include zero in the list of possible entities of that type per column. The existing rules for ensuring that these bricks don’t generate directly under arrows remains in place because that still seems like a good idea (it tends to make such bricks useless).
The black holes are still generated by positioning them randomly, but now we enforce a restriction that there may not be more than one in any given column. Additionally the minimum distance between two adjacent black holes has been slightly extended. The generation parameters now also make sure that they do not generate against the side walls or within a few tiles of the top and bottom of the maze. After playing around with this a bit, this seems like a good change because it makes the ball have to move more before hitting a black hole.
The bug where a player could push a ball that was blocked and have it visually get out of sync was literally because the ball pushing code doesn’t check to see if the cell below is blocked before it starts the ball moving. This works just fine for the computer player because the AI filters out blocked balls before starting to consider moves, but the player has no such code. I modified the ball push function to perform this check for us, which gives extra redundancy against this happening again in the future if the AI code is touched.
As a last final visual tweak, I modified things such that when we enter the phase for removing all blocked balls, any un-played balls still visible in the top row (left there by the last player) are visually removed. They aren’t considered blocked for the purposes of that calculation, they’re just hidden and expunged. Such balls should not be a valid part of the final ball drop.
The only remaining bug is that of a ball coming to rest on a teleport entity. Visually the teleport is still there, but such balls are not vanished or dropped at the end of the round. I ran out of time to check out why this is. I have a couple of possible fixes in mind depending on what the ultimate cause is, with a fall back solution of considering such a black hole “permanently plugged” when this occurs, which would remove it from the maze entirely.
We’re running out of Devember so I’m thinking a little bit of polish on this would be to include a title and game over screen and properly handle a regular and long form game (long form being played over three rounds with a cumulative score).