Managed to put some of the optimisations back into the game without buggering it totally

The screen drawing code doesn’t seem to be the main culprit in making this slow any more. If I run the editor the highlighted tile lags less than in the game itself. The only thing I can think of is the bit of code that works out where the laser is going.

Nope, after a bit of testing, it’s the code that puts the tiles on the board. With few tiles the highlight lags a little. With a screen full of tiles, the pointer lags a lot.

Oops… I just thoroughly broke the code that handles the game board while attempting to optimise it :-]

Never mind, that’s one reason why I store all my source in a Subversion repository. In fact, being able to recover from my own cockups is pretty much the only reason I have versioning control over my sourcecode.

And since I checked my last changes into the repository just before mangling the code, I’ve lost nothing. Which is good. The last changes I made were quite subtle and a pain to fix.

Home tomorrow.

I know you’re not supposed to wildly alter the gameplay of your games right before their release, but this feature was just too good to miss out. Not only that, but it was so simple to implement

Originally, the Tile Chooser would randomly generate a never-ending stream of tiles to place on the board, making gameplay quite random, and hard to design levels for - after all, if the sequence of tiles the player is placing is random, it’d be possible to design a level they can’t complete due to the required tiles not being given out.

Now though, a level can either have a Tile Chooser that gives out random tiles, or it can be filled with pre-chosen tiles. So now it’s possible to create some hideous maze on the board, provide the exact tiles needed and leave it up to the player to work out where those tiles should go.

All I need to do is alter the editor slightly and update the documentation to fit.

Now that I’m trying to use the level editor, I’m finding all sorts of weird and obscure bugs. Things like trying to delete a tile off the board while you have a start or end piece chosen makes the whole thing crash, or if you edit a level but don’t press Back or Next in the level navigation your changes aren’t actually saved. The Back and Next button logic was also quite confusing, needing to be re-written three times before I got it right.

Through the examination of corefiles (bit like forensic science that, your program dies and all its bits are scraped together into a bag for someone to pick over) I’ve managed to fix those bugs and a few others I found along the way.

Debugging’s quite nice though. While writing a program, you get a feel for how it is progressing. It starts off as something that’s highly likely to crash and delete all its data. You generally don’t trust the program to work properly, but as all the bugs that make it crash are slowly removed, trust increases. Eventually you reach a point where it feels stable enough for some proper usage. At this point half a dozen really bizarre bugs turn up and kill it, but these can either be worked around or fixed with one or two lines of code (once you find where to put those one or two lines of code…). Eventually you reach a stage where you might entertain the idea of letting someone else play with your creation.

Naturally, within five seconds of seeing it, they are looking confused and saying “I think I broke it”

Being the programmer makes finding bugs tricky. You know exactly where to kick the program to make it collapse on the floor, and since fixing bugs isn’t as fun as testing cool new features, those sensitive areas are left alone. Sometimes hard to fix bugs get accepted and forgotten about. Regular users don’t know the intimate innards and kick your program in the balls without knowing. If you let another programmer test your stuff they become experts at torture, taking great pride in saying “This bit wants a number… what happens if I set the value to be ‘Hello’… aha! It’s gone funny”. Regular users also do daft things like reading the documentation and following it, then complaining when it doesn’t work. Surely everyone knows documentation is just there to pad things out

Completed the documentation. It was quite tedious, but quite easy to add each screen and map the buttons on them. You can even click on bits of an image I have created and get taken to the relevant parts of the documentation. It’s a bit like an HTML imagemap I suppose.

Also fixed half a dozen random bugs that appeared. It’s amazing just how broken your code can be, but things still work OK. It’s not until you errorcheck everything that you notice where things are going wrong. Maybe there’s a lesson to be learned in this… something about always checking for errors

The ultra-last thing I have to do is make a load of levels. That’s the fun bit since it just involves sitting down with a big cup of tea and bashing out a load of sick and twisted designs

Summer Camp has started. There are nine hyperactive kids under our supervision. I was expecting more than that, but at least it means this week should be easy. Extra easy for me since I bugger off on Wednesday and don’t return till Friday night. Today was exceedingly taxing…

I woke up, had some breakfast. For breakfast I had Rice Krispies, scrambled egg on toast and tomatoes. The excitement didn’t begin there either, the morning consisted of watching some lame girlie film while sewing up holes in our Ghyll jackets. After snapping two needles, poking one into my finger and almost falling asleep I went off to find something else to do. Outside I met Paul who was clearing out the incinerator. This looked much more interesting, so we spent an hour poking the thing with a shovel trying to make it burn better. After wandering about, putting all my random bits of kit away and trying to look busy, it was dinner time.

After dinner I was supposed to be going on a walk with Dan and all the kids, except most of the kids were stuck in various traffic jams around the country. Eventually enough arrived that Dan could take them for a walk. I stayed behind waiting for the rest to turn up. To pass the time I watched Paul get scared climbing a ladder to clean out the gutters. He’ll happily lead a 30m VS with wonky protection, but for some reason going up ladders freaks him out. Bits of rope were dangling out the windows of the building so he could attach his climbing harness to them, should the ladder disappear. It looked like we’d just had a mass breakout I managed to drag ladder watching and standing around in the rain out for a few hours, then as it approached half four I vanished into my room (propping the door open, should people want to find me… see, not skiving, just keeping out the way

And that is why I have almost finished the game

Hurrah! The code is finished. Bugs have been squashed, final bits of code have been finished and all that remains is to write some instructions and then make many many levels using the level editor. No doubt I’ll find a few bugs and really irritating things before final release.

In fact, I was just about to have a play with the editor, and I’ve found a bug

The game itself is complete, as is the level editor. All that needs to be done is some more tedious XML parser error checks, making the level editor a little more user friendly and fixing a rather odd bug that causes the whole thing to crash if you press Escape while in the instructions. Oh, best write some instructions too!

I should be able to get this complete and tested by the time I go home next week. Once I do, I can upload it It’s a bit of a big bugger, mind. Must remember to remove the corefiles, debug builds and all the weird automake cache stuff. I haven’t the slightest clue how the automake and autoconf stuff works, so unless it turns out to be moronically simple there will have to be some installation instructions.

Looking back through the subversion logs, it’s only taken me three months of spare time to make this. Not bad really.

The level editor is now usable I can now edit the user defined levels and create new ones. The next thing to do is validate the created levels so they are playable (i.e if the user puts a right-facing laser emitter against the right side of the board the level won’t work at all).

I also spent a long and tedious amount of time adding error checking to the XML loading routine for the level files. After spending too long trying to track down a bug that was caused by bad XML data, it seemed a good thing to do. I need to add this code to the other XML loading routines for the hiscore table, etc. God it’s boring code… lots of if-then-else stuff to print error messages on the screen. It works though, it complained about missing items in the test level file I was using

Not sure if I can be bothered to add sound. Since I spend most of my time listening to music on my PC, and Linux audio is a bit backwards in that only one program can access the soundcard at any one time (unless you use one of those horrid multiplexing things like aRts* that bugger up the audio/video sync of a DVD) I’ve not noticed a lack of sound, and beyond a few bleeps when you finish the levels, sound wouldn’t add much.

• This sort of thing should be handled by ALSA directly. There is a multiplexing thing in ALSA, but it doesn’t seem to work that well. I don’t think I’ve had a PC that’s made bleepy sounds since my 286 that ran Windows 3.1.

My game’s logic is now complete. The game has a little twist to make it more interesting to play - sometimes the laser might flash on and off, sometimes it might not come on until you create the required number of reflections. For a laugh you might be required to create a certain number of reflections before the level can be finished. If you don’t, you lose. The way you can sit for ages trying to work out where to put a piece, combined with the sudden-death of a level that’s finished too soon should add to the fun - especially if the laser doesn’t turn on until you’ve made 5 reflections.

Now to fix some bugs and introduce the STL to other parts of the code.

Wooo!

http://www.llamasoft.co.uk