I've been working on a Lights Out game for the 84+CSE. I spent some time last night and some today, and this is what I have so far:

It's a little slower on the calc, but the keys are more responsive than they appear in the screen shot. The player will be able to set their own difficulty and be able to pick their colors (though it took me a long time to come up with these colors and I like them). Score will be some function of moves, time, and difficulty. Suggestions for a formula are welcome.

You can notice on the screen shots that I'm drawing the boxes using a line thickness of 2. However, this leaves a pixel at the bottom off, which you can see when it's drawing. So I then have to draw a line for the bottom of the square. Very strange, but it works.

Let me know what you think!

Out of curiosity, are there any guarantees as to whether or not a particular board is solvable? I'm not terribly familiar with the game.

I suspect Shaun creates the boards by starting with a 'solved' board and performing valid moves to un-solve it, so they should all be solveable. Presumably the harder the difficulty, the more randomization moves he does. Shaun, this looks great! I look forward to the completed version.

This is looking great so far, Shaun

This is, indeed, how I do it. Many "random" boards are unsolvable. Unfortunately, this means that even though you up the difficultly, it may not actually be more difficult, but that's just how it goes. I'm thinking I'll also add support for Mini Lights Out and Lights Out 2000 if I get really adventurous.

I'm also still looking for a scoring function, so feel free to suggest one.

Also, some people are really into this game.

The obvious scoring function that occurs to me is taking the "correct" number of moves plus some fudge factor and subtracting the number of moves the user made to get to the final result. More quantitatively, if the difficulty level is D (say D={1,2,3} = {easy, medium, hard}, the ideal moves was I, and the actual moves was A:

score = C(2D+I-A)

C could be some integer coefficient >1 to give scores a higher and more exciting spread. Needless to say, this allows negative scores; I'm not sure if that's something you want.

I don't want negative scores, and that doesn't factor in time. The difficulty will probably be more spread out (5-20 or something like that).

Ah, time is a good point. Are you thinking of using the timers, or just fudging it by counting getkey ticks to avoid factoring drawing time into the equation? For time, I guess you could either come up with an algorithm to estimate how long each move should take for the average user, and then reward shorter times or penalize longer times, or you could do something logarithmic.

You should be able to see in the screenshot:

I'm using the timer (doing it any other way seems silly). You can see that after it's done drawing, it skips ahead a few seconds because it doesn't update the display when it's drawing, but the calculator is still ticking away.

Though now that you mention it, not ticking when drawing would probably be a good idea--though it doesn't really make a huge difference. I could still do that with the timers, though, just store out the values I want to be checking against before drawing and such.

This looks great Shaun! I look forward to getting my hands on a TI-84+CSE so that I can start having some fun with it!

I know I haven't really updated in a while, but I made some progress tonight. Nothing screenshot worthy, but I did add in a bunch on infrastructure for allowing settings and such. I also added external tool support to TokenIDE. Unfortunately, TilEM doesn't work right when sending a file (I have to send it three times in order for it to work) so that wasn't too much help. Once there's a working (non-web) 84+CSE emulator out there, though, editing will be sooo much easier.