Inspired by the frame-based iteration to find the new cell after a move, I'm thinking that you could do animation fairly easily by showing the intermediate frames as you do the collapse of cells. So, if a cell was moving from column 1 to 4, you'd see two frames in the middle of the move. I think this would be a small modification, breaking up the current shifting processing code to only do one shift per frame display and adding a Shifted state that you'd be in if you're still shifting but had shifted at least one cell. I might work on this and see how it affects the game.
The game plays nicely, but it lacks any sound. Having some simple effects for merging cells would be really nice, and if an end-of-game state is implemented, that would be a nice hook for playing some melody.
The original web game keeps a running score based on the sum of all the merges. It seems possible to adapt an existing six-digit score kernel to show a running total kept by the game, making it more fun to go after a high score on the console.
If the "find new cell" routine runs for 16 frames with no success, the game should go into a GameOver state. Traditionally, one way to show this is to have the playground/foreground colors cycle to avoid monitor burn in.
It might be nice to support multiple versions of the tile set using the SELECT switch... since the setup code sets the MSB of all the tile bitmap pointers, changing tiles would just involve having more pages of the bitmaps ready and resetting that MSB value.
Ola -
I am porting your engine to the Apple II, and I ran across this in line 599 in 2048.asm:
ldx FirstDataCellOffset ; and count points for merged cells...
But FirstDataCellOffset is a constant, of value 5. Shouldn't this be an immediate load instead of zero page?
ldx #FirstDataCellOffset ; and count points for merged cells...
It seems to work either way, but the score goes crazy the first time through (on my Apple port). Subsequent games behave correctly. Fixing the addressing mode makes the first game score correctly.