Okay, so it looks like the order of release will roughly be the following. I'm hoping to get them into some sort of distributable state over the Easter holidays, which for me is the next three weeks. Don't take that as fact, though.

Most tested and verified working through lots of complete games:

Net (most tested, works very well without any problems)
Bridges (very well tested, works very well without any problems)
Mines (user request, works very well without any problems)
Untangle (works very well without any problems)
Cube (works very well without any problems)
Fifteen (works very well without any problems)
Blackbox (works very well without any problems)
Tents (works very well without any problems)
Pattern (font display a bit too small for some puzzles, but otherwise fine) - I'm not too worried about this one given that the excellent GhostPix is the same type of game and infinitely better.

Only basic testing has taken place (i.e. I played with them for a little while by clicking around and checking things changed, and completed the ones that I was able to complete, without any major problems showing up) for these ones:

Dominosa
Flip
Galaxies
Guess
Inertia
Lightup
Loopy
Netslide
Rect
Samegame
Sixteen
Slant
Twiddle

These ones will have to wait until I have released most of the above due to some problem with them:

Map (drag-drop display problems make playing it very ugly)
Pegs (needs looking at to find a quite annoying slowdown when dragging that wasn't there until a few revisions ago, probably SDL Timer related - it looks like it's trying to draw circles over circles over circles as you drag the "mouse")
Solo (requires keyboard input of numbers, so I'll have to bodge that with GP2X controls)
Filling (requires keyboard input of numbers, so I'll have to bodge that with GP2X controls)
Unequal (requires keyboard input of numbers, so I'll have to bodge that with GP2X controls)

If anyone would like to suggest a mapping for the keyboard, or express a preference for right/left/middle click buttons on the normal games, I'd be open to ideas. At the moment, I'm using shoulder buttons but I think it might be easier long-term if I use the top three buttons (A,B,X?) of the right-hand side for "mouse clicks". L+R shoulder buttons will probably change numbers in those games that need them. Select will probably be "restart this game". Start will probably be "new game", with vol+/vol- being "quit".

I'm hoping that F-200 users will get touchscreen but I can't guarantee it as I don't have one (and, honestly, don't really care that much about it so long as it's playable in some fashion, although I am being careful not to use stick-click and other F-100-only features) - but if it's seen as an SDL mouse or it's easy to code, then it will be so. From the look of it, I can open a device file, read an entry and get X,Y co-ords which is enough for "click" but then I'd worry about how you'd right-click or middle-click (probably holding down the relevant button while pressing the screen but then that's more coding to differentiate between F-100's and F-200's and F-200 users who want to use F-100 style controls, etc.).

Changing sizes/difficulty of the puzzles will have to be done by supplying command-line parameters (so a simple menu system could take that away from the actual program executable quite easily), and saving/loading/playing a particular numbered game I really don't care about and stripped out, so all that code would have to be reintroduced by someone else. I suspect the easiest way would be to supply a command-line argument again.

In the future, users would have a "puzzle menu" (which could be quite a simple C / SDL program but I'm not going to write it) which would allow them to select games, change difficulty, size etc. and then run a game. When the game quit, it'd go back to the "puzzle menu". Without such a menu, these programs would have to be run inside script-wrappers if they are to re-execute the main GP2X menu. I'll include those because I care about that, but I don't want to get involved in making a "puzzle menu".