Posts Tagged ‘Stick Game’

A Stitch in Time…

May 17, 2009

Well, I finally completed (re)work on the Stick Game, and got it into a form where it can be distributed. The delay: memory leaks. Yeah, that post where I said the game didn’t have any was tragically, horribly, wrong. It turned out, that it just didn’t have any in the main control loop. It had all sorts of them hiding away elsewhere, and catching and killing them was a huge pain. The bottom line: unless you’re certain that you’ll never use a piece of code ever again, write it well the first time (or, at least, make sure you properly deallocate your memory). That way, you won’t be stuck with a weeks long project many years hence putting it into a shape where it can be distributed without blackening your name.

Anyway, at this point the first pass at content for the site is up. Next, I want to do some work on the interface, then test everything out, and it’ll be ready to go live.

Too much power

April 25, 2009

So, I’m still prepping the stick game for uploading to the web site. When I wrote it originally, I thought it would be cool to allow arbitrarily large numbers of rows – probably something about showing off the robustness of the data structures. The problem is, when I wrote it, I gave short shrift to performance optimization. The AI enumerates all possible moves and possible games, then plays a move which leads to it winning (or taking the longest possible time to lose). That’s fine for when you have a small number of sticks, but when you have a larger number of sticks, the process of enumeration consumes all available RAM, and causes the program to become non-responsive. As a result, the fact that the AI will only play once it’s found the correct move means that it (effectively) never plays once it has to deal with a large number of sticks.

Now, if I’d been thinking about performance optimization when I originally wrote the game, I would have done something marginally clever, like have a calculation thread constantly running the background, enumerating away, rather than waiting till it’s the computer’s turn to start thinking. I could also have done something like add a timer on the computer’s thinking, and forced it to make a move after it had been enumerating for some set period (e.g., 30 seconds). That second one would actually go hand-in-hand with a third optimization that I didn’t implement: I could have written the code to save intermediate results, rather than only saving the results once the enumeration’s finished (the current approach).

So there are all sorts of optimizations I could implement to help clean up the mess from when I originally wrote it. Alternatively, I could just remove the user’s ability to start the game with an arbitrarily large number of sticks (thereby making sure the game is only played with the smaller numbers where the lack of optimization isn’t a problem). As it happens, in my relatively old age, I have found that there’s another optimization that is more important than the ones I described above: minimizing my own time expenditure. Given that, what will actually happen is that I’m going to remove the functionality that’s causing the problems, and leave the task of optimizing for another day.

Trip Down Memory Lane

March 28, 2009

Good lord I used to be a [more] incompetent programmer. Last night I was putting the Stick Game in shape for uploading to the web site. I was appalled at how poorly written the code was. Magic numbers everywhere, no page flipping. Strange (and so far unpredictable) side effects from executing innocuously named functions.

All I can say, is that, in spite of all the dynamically allocated arrays, at least it didn’t have any memory leaks.

On the other hand, before I judge myself too harshly, I should keep in mind that the version of me who wrote that code originally wasn’t writing it to be read. The game was intended as a substitute for a writing project in a GE class about treatment of time in literature. As such, it did what it was intended to do. That is, it compiled, it was functional, and it included some explanation of algorithmic complexity and trade offs between storage optimization and processor optimization suitably dressed up in language from the course to get me through the class.

Still…yuck. In any case, I had hoped to be able to upload the program last night. Given the poor state of the code, that didn’t happen. The new plan is that I’m going to need to figure out what I was doing with all those blasted magic numbers and poorly named functions, then try and polish up the interface without breaking everything. Then I’ll upload it.