Great Exploitations

Rather than disallow block placing, let the bot place blocks.

 

This is really cool; I also like your new progress bar much better than the old one.

Rather than disallow block placing, let the bot place blocks.

 

It's too easy to place blocks by mistake. Often times, I'll recognize the mistake while I'm still on the erroneously-placed block, but by then it's too late.

 

Because 1/4 of the squares in the maze are always vacant, you could restrict the user to placing blocks on those, but then allow the user to remove the blocks after placing them.

Rather than disallow block placing, let the bot place blocks.

 

It's too easy to place blocks by mistake. Often times, I'll recognize the mistake while I'm still on the erroneously-placed block, but by then it's too late.

 

Because 1/4 of the squares in the maze are always vacant, you could restrict the user to placing blocks on those, but then allow the user to remove the blocks after placing them.

Makes sense. This would allow the bot to still navigate amidst user-placed blocks. So I will probably limit placement.

 

Unlimited removal is a little problematic, however. About 1% of such squares are not actually vacant *. I can, however, keep the last few blocks placed in a stack and allow them to be removed.

 

* The maze generation algorithm is a heuristic. Here's why:

 

Unbiased algorithms require lots of memory - typically a stack equal to the size of the maze.

Memory-free algorithms are slow and biased.

Sometimes, getting the last 1% takes 99% of the time.

 

All 3 are bad on the 2600. So...

 

The algorithm starts as a stack-based approach (recursive backtracker) but the stack is limited. If the stack is overrun, it reverts to a memory-free algorithm (hunt & kill, I think) until a visited cell is found, then back to the recursive backtracker. The last 1% takes a long time since the stack is always overrunning, so it was omitted.

 

The end result is a good maze with lots of long dead-ends that is generated relatively quickly, with minimal resources.

About 1% of such squares are not actually vacant *. I can, however, keep the last few blocks placed in a stack and allow them to be removed.

 

If divide blocks into three types "OO", "##", and ".." thusly:

##OO##
OO..OO
##OO##

where the "#" blocks are always present and the ".." blocks are almost always absent, is there any circumstance in which a ".." would be present but some of the "OO" blocks surrounding it would not be?

 

If not, why not allow unlimited block removal of any ".." block adjacent to the player?

 

BTW, I think you need to fix some range-checking at the bottom of the maze. I think the player gets to wander into code, and will crash things if a block is placed there.

About 1% of such squares are not actually vacant *. I can, however, keep the last few blocks placed in a stack and allow them to be removed.

 

If divide blocks into three types "OO", "##", and ".." thusly:

##OO##
OO..OO
##OO##

where the "#" blocks are always present and the ".." blocks are almost always absent, is there any circumstance in which a ".." would be present but some of the "OO" blocks surrounding it would not be?

 

If not, why not allow unlimited block removal of any ".." block adjacent to the player?

I'll try it and see how it works.

BTW, I think you need to fix some range-checking at the bottom of the maze. I think the player gets to wander into code, and will crash things if a block is placed there.

The bottom of the maze resides at $FFF0-$FFFF... Obviously, the problem arises when writing to hotspots. I just have been too lazy to fix this.