When I started with kams, it was just going to be my own little MUD server that I puttered around with. So I set up a little Subversion repository and went at it. That repository slowly turned into my main server for the game. That way, I could do version control and keep a backup copy of everything. That worked pretty well for quite a while, until the decision was made to release some code. To do so, I created a branch, stripped out all of the stuff I didn’t want publicly released, and then released that code. Well, that is the way it was supposed to work. Actually, I had to fix things along the way as I was preparing the release code. This meant copying/merging back and forth between the branch and the trunk versions of the code.

This became annoying.

Now that I have been using Git for a while, I was hoping to do something so that I can continue my current path (keeping my private stuff private, but in the Subversion repository), but also maintaining an on-going public code repository.

To compound the issue, I (very foolishly?) do most of the development work on the live server. (Keep in mind, no one is actually using the live server, so this really does not matter.)

This is what I came up with. First, I created a GitHub repository for the public code. Then I copied my latest branch into the Git repository, committed it. Next, I created a new branch, deleted all the files, and then did an svn checkout to the new branch, and finally committed the private files to that Git branch.

Now what I can do is make code updates on my trunk code (kept in Subversion), then do an svn update on the private Git branch, then do a Git commit of the specific changes I want put in the public repository, then do a git cherry-pick of that commit into my master branch. Finally, a git push puts it all up on Github.

This works in reverse, as well. Changes made in the Git repository can be propagated to the private branch, from there to the Subversion repository of the trunk.

Works fairly well, actually, and it will make it considerably easier to create future releases. Yay.

I’ve released a new version of kams (0.2.0).

Today is the first day of the new quarter, but I don’t have class and I’m sick. So I’m staying at home. Yay.

Okay, in my last post I was talking about some changes I was making to kams to make it work with Ruby 1.9.1.

Today I happened to glance at the memory usage. This is just after starting up the server and I have about ~830 game objects in the world (I expect that to be a small number, given that I only have 152 rooms, 325 exits, and the rest are random things like clothing). Under Ruby 1.8.7, this takes ~36MB of memory. Under 1.9.1RC1, it’s only 16MB. Less than half.

Nice. Now to look for areas where memory may be leaking…

Here are a few things I have found so far while making kams compatible with Ruby 1.9.1:

• Small eventmachine change needed as shown here.
• require 'md5' changed to require 'digest/md5' and MD5 changed to Digest::MD5 (this works with 1.8.7, too.)
• Any hashes which were defined not using => (i.e., {'a', '1', 'b', '2'} ) have to now use =>
• One issue required some version checking: the Observable module in 1.8.7 uses an array, in 1.9.1 it uses a hash. This doesn’t matter much to me, except when Observable objects are marshalled and this goes along with them. What I have done for now is set it to an array or hash as appropriate when loading the objects (there is no content for it, in either case).
• Array#to_s has changed. In 1.8.7, [].to_s => ””. In 1.9.1, [].to_s => “[]”. Somewhat annoying, but easy to handle.
• Have to deal with Object#instance_variables and Object#instance_methods returning arrays of symbols instead of strings.
• Ran into an issue with Mutex#try_lock. Asking about a solution now…

Update – No one answered my question about Mutex#try_lock, but someone fixed it anyway :)

The first release of the Kingdoms of Ahln MUD Server (kams) is available over here.

Well, the conference paper that has been delayed again and again since the beginning of this year has finally been submitted to WICON so I feel a sudden sense of relief and release.

A meeting with my advisor today set out a fairly ambitious (I think) schedule for my next projects, but I am excited to get started on it, though that may just be because it is something new.

In celebration, Kingdoms of Ahln now has its own little server, meaning it is actually accessible to people other than myself. I plan to be putting a lot of time into it in the remaining summertime. I’ve had a lot of ideas bouncing around in my little head, but they are pretty worthless if they stay there!

It’s also time to finally start working on my mom’s website for her new independent practice, which I am sure she will appreciate.

And what about Pi, No Forks and Black Orange? Believe it or not, I do have some song things kicking around, but I have not had the time nor energy to record them. But maybe I will now. My instruments and recording stuff look sad and lonely.

I’m pretty much done with Sqwee for now, I think. I still use it, but haven’t had any burning desire to improve it or add any new features. Of course, maybe if other people used it and made suggestions…

One other thing I’m planning is maybe adding some way of leaving comments on this blogatron…though probably nobody would. Hrm…

Yes, I am actually still working on this game. Today it received a fancy new URL, a faster loading logo, and set of fancy pantsy forums.

The game itself is still plodding along. Unfortunately, my ISP really limits incoming connections for some reason, so the game is pretty much inaccessible to anyone but myself. This is not really a bad thing, though, because there isn’t much to see anyway.