I properly blame Weregoose for this. lol

http://gabrielecirulli.github.io/2048/

He found this little gem and posted it this morning to IRC. It's a simple, yet fun and addicting, tile puzzle game. You start out with 2 tiles with 2 on them. You combine them to make a tile with 4 on it. Every time you move tiles, you get a new tile. It starts out with just giving 2s, but you do eventually get the random 4 thrown into the mix.

The object of the game is to keep shifting and combining tiles until you get to the mystical and magical tile, 2048.

So far, I have the following:



I thought about trying to expand the number's size in the box as there were fewer digits. Not sure it's really needed, but I guess it could be done. Based somewhat on Weregoose's shot: http://i.imgur.com/mKxQCjr.png

The overall controls are easy. If you press up, you are essentially shoving all pieces that can move upwards. You don't choose individual tiles.

Thoughts thus far?

Current mental debate I have for myself for the mechanics in a BASIC engine, would be if a direction is pressed, and after checking a move is capable of happening, do I clear the board, make the changes to the matrix, and then redisplay everything? Do I make the mods to the board and then redisplay affected lines? Want to make this so it's as fast as possible.

Still need to actually start in on code for this, though. Would be a helpful start. lol

It would be silly to redraw anything that didn't change, so I'd only redraw things that changed.

I do agree, just need to figure out how to log which of the rows/columns need redrawing.

I'd probably keep track of it in a list. Any time I change a value in the matrix, write the coords to the list. Then loop over the list, and redraw those cells.

Good plan. Means I'll need to create a tile to clear out the other tiles, make it faster that way.

Any blank space is a 0, with values 1-11 for the tiles. When recalling the tile, it'll just be value+1 to get the line number to pull the string back from to display.

I got this. lol

I think the hardest thing in programming this game would|will be just computing the new tile values for any of the four possible directional moves, and even that shouldn't be too hard.

Edit: Just spotted those screenshots. Awesome!

Thanks, and I think you're right on that. More so that there could be multiple mergings on one line that you'd have to track.

Also, the sprite data for the 12 sprites comes out to an appvar the size of 13,315 bytes.

Were you wanting to still co-op on this, or were you wanting to try this with xlib?

Either way. On the one hand, I'm curious how an xLIBC version would look, but on the other hand, I don't want to steal your thunder with this version, and working together could get it done a bit faster, especially if the matrix manipulation gets tricky. Thoughts?

If you haven't seen it this is a version that includes an AI that can give hits or play completely autonomously.

I would appreciate help with that, since that will probably be the biggest drop in speed will be handling the matrix changes and adjusting tiles accordingly. Let me see about getting a board drawn to the screen and the first 2 random tiles generated into their appropriate spots, and we can go from there

Edit:

Okay, we have a start:



I'm thinking of using the 2048 tile up in the right hand side, centered, above where Score: and Highscore: shall go, to the right there. Then I need to determine the positions of the boxes (shouldn't really be hard) Based on matrix coordinates and such to set that up properly.

I propose that as with Basic Tetris, we work together to create a reasonable backend that works, then each layer our own frontend (one Celtic II CSE, one xLIBC) on top, and publish both as joint projects. How does that work for you?

I'm getting kind of fascinated myself with the implementation. I may even code an RPL version on my HP 50g myself.

Merging the matching tiles itself shouldn't be difficult at all. The tricky thing is handling the blank spaces and properly shifting tiles to fill in the gaps.

My naive first attempt would be to iterate over three of the columns/rows, see if each one is zero, and swap it and the next one if so. Unfortunately, that could require up to three executions in the worst case (e.g., [0 0 0 1]) to do the job.

One trick might be to just iterate over the items and copy them to a new row/column while skipping the zeroes. You could have a fifth "scratchpad" row (not shown or used in actual gameplay) for writing out a new row, then rowSwap( it with the old row. For vertical movement, you could use the transpose function to "turn the matrix sideways", treat the columns as rows, then transpose it back to its original orientation. This also has the advantage of saving code, since you'd only have to implement left/right movement, and up/down would be done simply by transposing before and after calling the left/right code.

I'll see if I can come up with a more clever way to do things.

Another thing that sounds particularly tricky is detecting when the game is over. I would imagine that making a temporary matrix and trying each of the four directions to see if any tiles moved after each move would be far too expensive in TI-BASIC to be practical.

Kerm: That seems like a solid idea What did you think of the board generation and idea for the 'logo' at the top right?

Travis: Yeah, a lot of that is what I've been debating on and thinking. It'll just come down to creating a version, and see if it is fast enough, or if I need to rethink the engine.

Edit:



Randomly placed tiles now work, and correspond to placement in the matrix.

That looks great, tifreak8x! Feel free to throw that code at me whenever you feel like it and I can start experimenting with the combining algorithm.

So far, it just displays that and pauses, I still need to work on looping, making sure you can restart the game with a clean slate, etc, then begin working on making tiles shift and generate a new random one.

Want to say I actually contributed something to this, unless you don't like my While loops and generally unoptimized code lol

Psh, of course keep working on that! But in the meantime I want to experiment with some code we can eventually drop into your finished program.

Alright, so, I've gotten this aspect started to where pieces shift around to the left. The code will be similar in the other directions, so that should help me out to some degree. I think. Hope. Anyways. Progress!

That looks rather fast to me! Do you use fancy matrix manipulation or two nested loops? Keep up the good work.

Two For( loops, with conditionals inside the second to check values and such to not be doing work when it doesn't need to be.

I also just realized I could set up the loop to be better at what it does without all the conditionals.. Might even make it faster.