Milestones and Kanban

In the last month I was able to finish version 1.0 of my game data editor “TOSEdit”. This is the first actually useful version, because it can create tiles, charsets and maps and export them in the same binary format as the wonderful CharPad. This will be the base for the further required features, that are needed to support the more special properties of the TOS2 C64 engine (like e.g. swapping parts of the charset on the fly). Interestingly, the implementation of the editing itself went pretty quickly (did I already mention that I love Java?). But what really needed time was a reasonable implementation of cut, copy and paste and of undo. I never implemented an undo mechanism before and it is actually quite a challenge. You need to do it completely for all actions that change the underlying data somehow, or it will fail miserably. Well, I was able to finish it and thought that this is worth a “release”. Where release in this context only means that I give it the satisfying version number 1.0 and write a blog post about it!

tosedit_1-0

I think working towards milestones and releases is so much more satisfying! When starting the work on the editor I decided to even go one step further and apply some agile methods to plan and track my progress. As I am the only person working on the project, Kanban seemed a reasonable method and what can I say: I love it! Kanban is a simple way to organize tasks (or rather “stories”, which are features that are needed, described from a stakeholder point of view). In my specific case there are 4 columns with such stories, a “Backlog” of things that I want to do at some time in the future, but did not think enough about that I could immediately start work on. After I spent enough thoughts about it, the story is moved to the “Selected for Development” column. When I actually start working on it, it gets moved to “In Progress” and when I finally finish it, it gets moved to “Done”. There is one specific rule that is typical in Kanban, which is that you limit the number of stories that can be in a certain column. In my case I decided to say that I never want more than 3 stories in progress. This helps to focus and get things done instead of being distracted too much.  I am using the wonderful Atlassian Jira (which is free for small projects and nicely combines agile methods with bug tracking) and below is a snapshot of my Kanban board, filtered for the TOSEdit 1.0 release. You can see that there is only one issue left (which is writing this blog entry), which I will move now to the “Done” column. Really satisfying!

kanban

The Editor

Wow, no posts for such a long time! Well, it is summer and I have to admit that I did a bit of a break from my PC while the weather was so nice. But did I take a break from the project? No! I spent a bit of time thinking about concepts, I fought a bit with infrastructure (and actually had to change the provider of my development VServer, well you get what you pay for), and I even spent some time with scissors, paper and glue and created some prototypes for a nice packaging. Googling the Internet for creating cardboard boxes is an, um, interesting experience. Apparently only kitsch fanatic house wifes seem to care for this normally. But who says I am normal :-)! The results of all this work are nothing exciting to show off, but were important to work on at some point (at least for me, as I am a bit fanatic about the overall experience of a product). On the code side I did lots of clean-up and integrated the task scheduler and the font swapping module I wrote about further down. I wrote many many unit tests, so I am of good hope that the game will be much less bug-ridden than the compo version.

What I did this weekend was maybe more exciting: I finally started work on the game editor. With all the new features of the game engine, standard tools are just not flexible enough to work with. So here comes a screen shot of the first editor version! A lot is still missing, but I feel I am on a good way:

tosedit It is really heavily inspired by the fantastic CharPad, I hope the creator does not see this as a plagiat, but rather a tribute to his great software! Especially the font swapping needs a lot of intelligence in the software.

Apologies once more for the delayed update! I expect them to happen more frequently now that the weather is getting more favorable for dwelling in my computer cave…

Tasks, schedules and priorities (2)

Apparently I was creating more questions than answering them in my last post. I will try to provide a bit more detail about the implementation of the task scheduler.

interrupt-3

The interrupt routine decides, if it wants to schedule a new task. If the new task has a higher priority than the one that is currently running, we want to switch to the new task. So what we need to make sure is, that when we return from the interrupt we do not return to the old task, but to the new one. In order to achieve this, we need to manipulate the stack accordingly, as the return address (and some more information) is stored there. Let’s look at what happens when an interrupt is triggered:

  1. the currently executed instruction is finished
  2. the current program counter is pushed onto the stack, high byte first
  3. the status register is pushed onto the stack
  4. the interrupt flag is set (because you usually would not want your interrupt routine to be interrupted itself)

All these steps are performed by the hardware itself. An interrupt service routine normally saves the registers in software in addition:

  1. A is pushed onto the stack
  2. X is pushed onto the stack
  3. Y is pushed onto the stack

How can we manipulate the stack now to return to a different task? We simply push respective data onto the stack!

    lda #>task
    pha          ; push >task
    lda #<task
    pha          ; push <task
    lda #0
    pha          ; push arbitrary states, IRQ flag must be clear
    pha          ; push arbitrary A
    pha          ; push arbitrary X
    pha          ; push arbitrary Y

When the end of the interrupt service routine is reached, it will restore Y, X and A and the final rti will pop the state register and jump to the new address we just pushed onto the stack! We do not have reasonable values for the registers (as the task was never executed before), so we simply chose 0. There is one caveat regarding the state register: we need to make sure that the interrupt flag is clear, or the interrupt will never be called again. It took me a while to realize this, as I was happily using php to push the current state register instead and as can be seen from step 4 above, that had the interrupt flag set.

Now let’s have a look at the task_done routine that is jumped to by a task when it is finished. In theory, all we need to do is to jump to the task with the next highest priority. Let’s for now assume, that the old task has the next highest priority. Things get slightly messy now: we still have the remains of the interrupt on the stack, but tasks are always executed in the main loop! So instead of jumping to the new task with jmp, we will misuse rti and simply do the same as we would do at the end of an interrupt routine:

    pla
    tay
    pla
    tax
    pla
    rti

Et voilá: we restore all registers and are back in the old task!

There is one additional thing that needs to be organized: when a task is added with a lower priority than the currently executed one, it needs to be stored for later. To do this, a list with upcoming tasks needs to be kept. Every time a task is done, the list needs to be searched for the next highest priority and the task needs to be pushed onto the stack as described above. But I am going to leave this little detail to be worked out by the reader (ha, I always wanted to say this cruel sentence at some point in my life)!

Tasks, schedules and priorities

Here we are with another rather technical update! Last time I was posting some information about how I want to get more diversity into the game graphics by switching parts of the character set on the fly while the player moves through the world. That actually raised an interesting new problem: how to handle tasks with different priorities!

Up to now there were only two possible priorities: tasks that need to be done during the currently displayed frame (like color RAM scrolling or inserting new characters at the border of the screen) and tasks that only need to be finished eventually during the next frames (like scrolling the currently invisible double buffer or checking for trigger areas for events). The character set swapping adds another priority: in theory it can take quite long and there is no need to have it finished in the next 2-3 frames, it is ok even if it takes e.g. 10 frames or so. Instead of patching this into the existing engine I decided to do it right from the start and be prepared for any upcoming additional tasks.  Which means: implement a task scheduler!

clocks-1098080_640

What does a task scheduler do? It makes sure, that most of the processor time is spent on the tasks with the highest priority. I simplified the concept a bit, so that higher priority tasks are always finished before lower priority tasks are continued. The implementation is actually simple, although there is some mean stack fiddling involved and it needed a bit of head scratching until I got it right. The interface of the scheduler module has only two routines: task_add, which adds a new task with a given priority and might switch to it immediately (if it is the highest priority), and task_done, which is called by a task when it is done and selects the next highest priority task to be executed.  All that is needed is to modify the stack such, that the RTI instruction at the end of the interrupt routine jumps to the right task. Apologies for the clumsy block diagram trying to depict this with an example. Did I mention that I am not a graphician?

In any case: implementation is done and unit tests are passing (yay!), so I am looking forward to put this new module into good use!

Gold plated tests and breaking the 256 character limit

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

ci

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…

Still alive!

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.

compiling

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…

All C64 games suck!!!

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. Knights_of_Legend
  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.Labyrinth_-_C64_-_Game_Over
  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.
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.

I am so glad I am no sysadmin…

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:

sysadmin

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…

Ah, it’s the pre production phase!

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

Juwel-typewriter_hg

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!

Welcome!

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