I’ve tested it in both your emthree basic version and copying the logic into my game and the results are the same.
In your example of having 1 block, there’s no apparent bugs I came across. The only possible bugs are it won’t fill directly below the blocker and the empty space below a blocker sucks in stationary bricks from the wall instead of flowing down from the top. But those 2 could be design choices?
The problems begin once you add in more blockers. Some bricks treat the blockers like empty spaces and will slide into the blocker position. Once that’s happened that blocker is ignored entirely. In the example it only impacts the blockers either side of the gap but I just tested if that’s the case and it is a bug with all the blockers.
A test with more complicated blocker layout to test flow.
A test with adding a simple check for blockers in the slide function before allowing them to move.
if M.is_blocker(board, tox, toy) then
print("Can not move. Blocker on: " .. tox .. "," .. toy)
else
blocks[tox][toy] = block
blocks[x][y] = nil
-- slide diagonal
local to = vmath.vector3((block_size / 2) + (block_size * tox), (block_size / 2) + (block_size * toy), 0)
go.animate(block.id, "position", go.PLAYBACK_ONCE_FORWARD, to, board.config.slide_easing, duration)
did_slide = true
end
The blocker check seems to have stopped bricks overlapping the blockers and ignoring them.
Example tests from my project, which I’m showing publicly for the first time. Sorry for quality/size but file size was too big. Board cleared using a debug button for testing.
First test using blockers. 5.5 seconds to fill and stabilize. Way too long.
Compared to no blockers. 1 second to fill and stabilize.
The blocker version does not have the same fluidity and smoothness to it. It has a very stiff feel and it is slow to fill and stabilize the board.
I hope this post was helpful.