Last time I was talking a bit about the test framework I am setting up. I actually became a bit obsessive with this in the last weeks and spent a lot of effort to get it to a point where it fulfils everything I need. Meanwhile I am at a point where tests are run every time something is submitted to the version control system. The result can be nicely seen on a html page and a history of the last 20 tests is visible. Log files for passed and failed tests are stored and can be accessed from the html page. All in an eye pleasant view, slightly  heavily inspired by a professional commercial CI system (is anyone able to guess which one? Write it into the comments and you will get personalized kudos in the next update :-)).

From the screen shot above you can guess that I have some unit tests running meanwhile. I decided to run the Vice emulator using a virtual display, because that allows me to run it on my headless server and still store screenshots in case something unexpected happens. This proves to be pretty important, as my tests rely on a Vice break point to be triggered. If this does not happen for some reason (e.g. if I messed up the code and it does totally different things from what I actually intended), the test system will grab a screen shot and kill Vice after a time out. That makes it easier for me to guess what went wrong.

But I did more than gold plating my CI system: I finally started implementing the much more advanced idea I had for increasing the char mode flexibility. The idea is to assemble the current charset arbitrarily out of different char set parts. For any rectangular area on the maps, the combination of charset parts can be changed. This is done in the background, so the player does not notice it. Obviously that does not help against the limitation of 256 character visible on the screen at the same time. But as soon as a couple of characters are not visible anymore, other characters can be swapped in. This is hard to handle during level design, but I think it should be doable to optimize the charset parts automatically in the level editor. Ideally, I could simply design the levels mostly arbitrarily, and the editor will take care for the rest. Let’s see how it works out…

Wow, that is a long time since my last post! Well, I had a lot to do in my daily job and all my other hobbies demanded some well-deserved time. But here I am back in front of my PC and typing away. The project is surely not dead, it just needed a bit of a break to go back to full speed again. There was a bit of a setback with the anticipated help for the graphics, so currently the team consists more or less of one person again. Nothing to worry about though, as there is no time pressure! That’s the nice thing about hobby projects…

I picked it up where I left it and finally finished the mechanism for continuous integration testing. “Continuous wha…?” I hear you say. Well, it is a buzz word for automated testing triggered by any kind of change. There are really really advanced tools to do all this kind of stuff, but I felt that they are waaaay too much overkill for my use. So I quickly setup my own system, that is really really simple. There is a daemon running on the server that watches for submits in the versioning system. As soon as something has changed, it will start a script on the server, that will get the latest version of the software and search for subfolders in a dedicated test folder.  Each of these folders contains a script, that can generally do any kind of test and will output the result on a web page. Passing and failing is signaled by a colored flag, so it is easy to see if something got broken. Additionally the test script itself and all kinds of error outputs are accessible from the web page, to easily identify a problem, when the test fails.

Up to now, the only test builds the disk image for the game, so a build buster can be easily identified. Not so impressive, as this can easily be checked locally on the machine where I do my development. But this is the basis to do much more advanced things. I am planning to run a C64 emulator and perform all kinds of tests in that, e.g. do a speed-run through the game to see, if it is still possible to finish it! I did this manually countless times for the original “Time of Silence” and it really, really sucked big time. You begin to hate a game, when you play it through for the hundred-fiftieth time, and this is definitely not a good prerequisite for coming up with ideas for improvements. So this is something that I will definitely avoid this time.

The infrastructure is now practically complete, so there is no excuse for not ramping up on the game itself again! Well, there is also the level editor, let’s see where I am going to concentrate on next…