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.

1. 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.
2. 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.
3. 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.
4. Instant death. We all know it from 80s games and hate it. Full stop.
5. 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.

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).