Simple ICQ Export script

Recently my girlfriend finally decided to stop using the original ICQ program, which she retained mostly because of the unimaginable loss of conversation history. Quick search did not reveal any good and simple means to convert the history data. Most of the software was outdated or for different versions.

We had two versions of history files - one was directory with XML files and the other seems to be Access mdb (created by ICQ version 6 I think). To sharpen my Python skills (which at the time being is a bit like trying to sharpen a club), I decided to write simple conversion script for the XML history files.

The script is published on http://code.google.com/p/icqexport/. For convenience, I have also prepared Windows build http://icqexport.googlecode.com/files/icqexport_01.zip. You are free to do anything with the script and welcome to send me notes and suggestions.

The usage is very simple, although nothing is guaranteed :) Copy the script to the directory where ICQ history files are stored and run it. It will traverse all subdirectories and convert history XML files to one readable TXT file.

The only version supported is 0x00140034 (tested on ICQ version 5.1). You're fine if there's something like this at the beginning of your files:

<root>
<version>0x00140034</version>
<event>
...

I didn't see the mdb structure yet but if I will get to it, I'll keep you informed.

Tomix - First level ready

During this weekend I planned to finish the first version of first level of our puzzle game. I had kinda slacking mood (caused partially by this great blog), but I forced myself to overcome it and in the end I was able to finish the first level as planned. There are still no graphics so I'm reusing arrows from Heartbeat, but the basic "engine" is ready. There is still a lot of work to do but being able to actually play the level is really motivational.

I handed it over to Mitsuki to try the game logic and she quickly found a solution - although not the one I had originally envisioned :) But it was possible because of a bug in checking of the final position so in the next version it won't count. But at first glance it seems that the idea is viable and I have a lot of great feedback for the game from Mitsuki. We only have to stay focused on the fact that we create puzzle game, because some ideas would lead us to completely different genre :)

So now Mitsuki will start working on the graphics to incorporate to the game. In the evening I also checked some sites with free game development resources so we could re-use something already created, but my search did not finish yet. But I have a few good sources I want to check so expect another post covering those I think are most useful.

For the next work I hope to finally start work on the editor. I kinda didn't get to that yet, but I already know how to serialize objects in Python :) And it has not that high priority for me - worst case we can easily define the levels in source code.

I also checked some libraries to create menus in pygame but unfortunately none of them seem appropriate to what I want to do so I'll probably have to write my own solution. KezMenu looks fine but it can't center the text and unfortunately it's GPL'd - and I did not decide on the license to code yet, so I may not be able to use that. Well, we'll see.

Device identification problem during boot

Since installing xubuntu last autumn, it sometimes happened to me that my machine required several restarts to boot up. I have identified the problem but being linux n00b I was unable to find some solution to it for some time.

The problem was following:
I have two harddiscs in my computer - one is old IDE disc and the other is new SATA II disc. The Linux system is installed on the new disc which is usually identified as /dev/sda (where /dev/sda5 is the root partition). The other disc is usually on /dev/sdb. What sometimes happened was that the devices where identified the other way round - IDE being /dev/sda and SATA being /dev/sdb. After that the computer of course did not boot and ended in some sort of fallback console (sorry, I forgot the mode's name).

Sadly, asking administrators at work did not help me (most probably because I was not able to describe the problem correctly - the only thing I found out was that the IDE disc should be /dev/hd something and not /dev/sd something - very helpful).

Before some time I found what I thought will lead to solution, but I was hesitant to change the fstab because I didn't want to break it any more than it was :) What I needed was to identify the mount points by partition label instead of device (see http://tldp.org/HOWTO/html_single/Partition/#labels).

Today, I finally got to fixing it (at least, it appears to be fixed now :)). The whole process involved:

• installing GParted which unfortunately did not help me with setting the partition labels and thus was not that useful (it provided me with nice overview of the partitions :))
• setting label to ext3 partitions using tune2fs (e.g. tune2fs -L pubsw /dev/hdb1 sets label pubsw to par
• setting labels to NTFS partitions using ntfslabel (part of ntfsprogs package)
• modifying fstab to use the labels (see http://tldp.org/HOWTO/html_single/Partition/#labels for example fstab)

To sum it up - if you have this problem with identifying devices during boot up, use labels to identify them in fstab. This seems like a good idea generally because as I understand it the device identification can change when switching hardware (imagine adding shiny new HDD to your computer and not being able to boot up as the result - ouch!)

In the end the changes where really not that hard and if I knew a little about Linux I could've fixed this long time ago. But I'm a little smarter now and maybe after some time I will know Linux as good as Windows. Most probably after Windows 7 comes out - because last version I had is Windows XP, I will know very little about both Windows and Linux.

Development update

I did find a few hours to quickly whip up the first prototype of Tomix (which is the codename of the game I'm working on) and it's ready for me to play with :) Fortunately pygame is really very easy to use for what I'm planning to do and I'm also slowly getting used to vim and Python. But I'm still not very good with either of them.

Back to the prototype - now I can move the player around on the screen and push things (nothing groundbreaking yet, but what would you want for a few hours worth of programming).

I plan now try to design one level to see if my idea of combining Atomix and Sokoban is at least partially viable. Afterward I'd like to start work on the prototype of level editor which will probably take me more time - I need to learn how to work with mouse in pygame and think about reasonable way to save the edited levels (not sure how to serialize things in Python). Hopefully I can find at least one free weekend to actually implement something (all the codes till now were written on train and that is unfortunately not the ideal development environment).

Also, Mitsuki volunteered to help me with the graphics (so the size of development team has doubled :)). This means that if we eventually manage to have some game ready it will look a lot nicer than if I did it on my own. On the other hand, this also reduced number of readers of this blog that are not working on the game from 1 to 0. Maybe I should start looking for some interesting topics to write about :) (Well, I have a few, I just need to find time and mood to try something new)

Slowing down quickly

It seems that with the spring beginning, I will have less time than I originally expected. Nevertheless, I thought about the story of the puzzle game, which is planned to be roughly based on Atomix and Sokoban.

The story is not very important for this kind of game but it gave me important ideas on which to base the following puzzle. I'm not planning it to have some big impact like in PuzzleQuest (how could I compete with that?) so I will be creating (almost) pure puzzle game.

With the story boiling in my mind, I can now start looking for some free resources to use in the game (mainly music, sounds and probably some textures) and sketch the basic look & feel of the game.

I will also start working on some early prototypes with pygame because I'm still not very good with it (or Python to be honest). I hope to get good insights to the techniques I should use in the final game.

But, as I said, I expect the work to go kinda slowly for now, mainly because I won't have time during this and next weekend. On weekdays I tend to be a little too tired from regular work, but I'll try to do something when on train to work, so maybe I will move forward at least a little.

Well, it seems that this blog didn't go very well. Or, it went exactly as expected - abandoned after first post. But after a time I have decided to try to write something again, maybe this time it will be better than on the first try.

I began to be quite excited of game programming after my girlfriend and her team finished visual novel Heartbeat for a ren'ai visual novel competition (warning: unless you speak Czech, you probably won't enjoy this game very much). As a little bonus, I programmed very simple DDR simulator for the game in pygame.

Because the team plans to create sequel to Heartbeat (where I should provide some simple puzzles), I decided to improve my Python and pygame programming skills and write some simple game on my own.

I'm still not 100% sure but I will probably be going for some Atomix inspired puzzle game or simple implementation of Alquerque with AI opponent. I hope to write something more after I decide and actually begin implementing something.

So, if anyone is actually reading this, wish me luck and determination to keep at least one of these new projects :)