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…
Ha, got your attention with this vocal headline? It is obviously not true that C64 games suck, well at least not all of them. But when I started thinking about making a C64 game, the first thing I did was reflecting about what I like and what I hate in existing C64 games. And to be honest, the things I hated were an overwhelming majority. I realized that I am actually hardly ever motivated enough to play through an adventure or RPG game on the C64, although I do this pretty frequently for PC games. So I made a list of things that I really hate and that I want to avoid in a game I am writing myself.
- Cumbersome user interface. The C64 has so many keys, so let’s use every single one of them! Many old school adventures really made use of this and made me pull my hair off on the desparate search for this darn key for the Fireball spell. Sure, this was documented in the manual, but who plays still with a manual on his knees nowadays? A user interface should be simple and follow the habits that people are used to today. E.g. run/stop could be a replacement for escape and interrupt a cut scene, or cursor keys and return can be used for selecting options.
- Frequent and eternal loading. I have especially fond memories of the game “Knights of Legend”, that would require two disk swaps and several minutes of loading to show the inventory (this was cleverly combined with the cumbersome user interface of point 1, so it happened frequently that I would accidently hit the inventory key and needed to follow this procedure without any chance to cancel it). This is a tough one, as the C64 really has a small memory and loading is slow, even with fast loaders. So what can you do? At least try to load, when there is a break in the story anyway. I read an interesting paper about the psychologic effect of progress bars. Not only do progress bars make the waiting feel shorter, but adding an animation makes them even feel progress faster! And finally, if there is the need for a long load, well then at least it should be worth it and reward the player with as much new stuff as possible. New music, new tilesets, etc.
- No in-game explanation of background story. Although I love the presence of additional printed material for games, I think a story should be understandable without reading hundreds of pages in the manual before you start. A cut scene here and there and a bit of in-game text can really make a game much more immersive.
- Instant death. We all know it from 80s games and hate it. Full stop.
- Starting over and over again. This surely depends on the genre, but for most games I think a save/restore mechanism is not hard to do and can save the player from a lot of frustration.
This is only my personal view and it is probably very focused on adventure/RPG style games. There are absolutely great games that happily ignore these rules. But I will try to follow this vision and hope to make life at least a tiny bit more comfortable for C64 gamers today.
Setting up the team still takes some time and I felt slightly uncreative this week. So I mostly concentrated on setting up the infrastructure. I setup the Perforce Helix server and a Bugzilla server (not that I would expect any bugs, haha). I am not a sysadmin and am not really experienced in this stuff, so I needed to learn quite a bit about secure communication. All seemed well, until I wanted to setup the secure connection for bugzilla. I was not really aware, but the server had a rather old Fedora Linux distribution installed, which is not supported anymore. I ran into a dead end, as setting up SSL for the installed web server was not possible with the latest known security standards. So I decided to install a brand new Debian instead and simply restore the data that I had on the server already. Setting up Debian and securing it was surprisingly easy and quick. But I really have a slow upload link, so I failed to upload my backups (especially the data for my daughter’s minecraft server, she will kill me when she notices). Argh. Luckily there is not a lot of data that really needs restoring, so I guess I will simply install everything again. Sounds like great fun for tomorrow evening, yay! So to show my respect for all the guys and girls that need to deal with this stuff everyday, here comes a view of them on themselves:
Apart from that I found some time to document all this stuff and to start writing on the character descriptions. I have a pitch for the story, but it is far too early to share anything as everything might totally change every day. As soon as things settle a bit, I can provide a glimpse on who you will meet in the game…
“Time of Silence 2” is only my second attempt at a computer game (well, to be honest there have been some more attempts that died an unspectacular rather early death) and it is the first one that might involve more than one person (me). So I fired up the internet search engine of my choice and tried to figure out what the pros do. Luckily there are a couple of things that get much less important for a non-profit computer game. All the development cost estimates, effort estimates, timelines, hiring, etc. are not strictly needed. There is no need to convince publishers, show rentability or analyse the market. Still, a lot of the usual procedures make sense. One of them is the Game Design Document, which provides all necessary information to people joining the team. Writing this document is part of the pre production phase, which obviously is what I am currently in (as I started writing this a couple of days ago). Ideally at the end of this phase there should be a detailed story, character descriptions, level descriptions, quests should be outlined (at least the main ones); in short other team members should have enough guidance to be able to create content mostly autonomously. Lots of writing work, but my motivation is high and I am making good progress.
Another thing that needs figuring out is the usage of tools for collaboration. Being involved in software development in my every day job I am aware of the advantages of versioning systems, bug tracking tools and automated testing. I do not want to overcomplicate things, so I tend towards Dropbox for sharing data. I love Perforce as versioning system and luckily I have rented a virtual server anyway (mostly as minecraft server for my daughter and her friends), so I can setup a Perforce server easily. I am totally open for anything regarding communication, but Skype seems to be a reasonable option.
Do you have any experience in working with virtual teams? Write your suggestions or warnings into the comments and save the project from total chaos right from the beginning!
So, here we go! This is the public development blog of the game “Time of Silence 2” for the Commodore 64. I am right now in the process of finding people to help me with the development and plan to post updates at least every couple of weeks here. The usual stuff: ambitious plans, how they get destroyed over time and what is the meagre result that we converge to in some time far, far in the future. Right now I do not really have a clue, when the game will be finished, but I am convinced it will be somewhen in 2016 (note to self: do not forget to update this year according to the schedule slip)! Expect to find previews, concept drawings, background stories and reports about the great fun the team is going to have figuring out how to fix the mess that I have left from “Time of Silence 1”.
I hope the next things to report here is how the team will be built up. I am looking forward to some interesting new team members! Until then I will write some internal documentation and might start planning the level editor, that is urgently needed (I am really sick of hacking in hundreds of lines of hex numbers, as I did for the first game).