Archive for January, 2010

Default Keybindings


So today I was reminded by a Finnish fan that I neglected to include a list of default keybindings in the walkthrough. That has been remedied.

Sinoth mentioned to me that I should implement a way to spectate as people play the game. ¬†Watching someone’s every move without their invitation seems a little intrusionary to me, but perhaps people wouldn’t mind. Anyone have any opinions?

This morning’s post is brief because I have stuff I need to get done today, but perhaps I will return tonight to add some content of worth.


big yellow Q


Deprecation of the Telnet Interface

So while watching the logs and generally putzing around yesterday, I noticed that someone had connected using the old telnet interface. I also noticed that it was using damn near a megabyte of bandwidth per minute. For reference, the SSH interface uses between 100 and 200 kilobytes. So I made the decision that the telnet interface had to go. It just wastes too much bandwidth. So I shut it down. The telnet interface is officially deprecated in twilight.

Distributed RCS

One of the unfortunate aspects of git (and distributed revision control in general) is that it encourages you to make very atomic commits. Virtually any time you change anything, you should be committing it. With subversion, I’d labor away for most of a day, changing something here, tweaking there, and at the end a finished feature popped out and was committed. With a DRCS, you’re encouraged to make those changes and tweaks, but to commit fairly frequently along the way. The mentality is, most of these changes and tweaks, while they may not implement the entire feature, they DO implement some sort of a useful change. If you change the condition of an if(), that change can probably stand on its own. Maybe it’d be unutilized, but it won’t BREAK anything. And someone else, working on their own tree, may want that same change made to that conditional, because what they’re doing WOULD utilize it. So rather than waiting till the end to commit one huge patch, you’re encouraged to commit as you go along, and people can “cherry pick” your patches as they choose, since most of them stand alone.

Anyways, the downside to all that is that the log gets very very verbose. Dozens of commits even for a single feature. And I don’t feel like digging back through all that cruft, so I’m just going to hit on the points that I can remember.¬† (more…)

new revision control system


So the majority of my attention today was devoted to moving from using subversion as my revision control system, to instead using git. I’ve used git a few times before in the past, for other projects, so I had a fair idea what I wanted to do, but nevertheless git has some disfunctionalities that took me a little while to remember how to work around.

Some decisions were made by the developers of git (and I’m sure for very good reasons) that make it difficult to commit changes from one repository to another, in the traditional sense. In a certain fashion, it makes sense. Git is designed for a large web of developers to be able to work on their local repositories, and then when their code hits a certain level of maturity, other devs can pull those changes into their own repositories. And indeed, git works exceptionally well for this. Unfortunately it just makes for an extra pain in the ass when you, personally, have two systems and you do your work on one and you want your changes to appear on the other. If firewalls and NATs didn’t exist it wouldn’t be a problem, but they do. And my “development” system resides behind a firewall and doesn’t allow incoming ssh, while my server does allow it. Anyways, gist of it is, it took me awhile to remember how to make ‘git push’ work in the fashion in which you’d expect.

With that done, I set about modernizing the build chain. In the past all the building was done with a very primitive, hand-written Makefile. It did the job just fine, but I wanted to at least put a proper build chain in place, should I ever decide to share the code with anyone (someone signs on as a co-dev, etc).

That about sums up my efforts of the last day or two. There’ve been quite a few minor adjustments to the code, but nothing drastic. My SSH library, libmoosshsrv, has taken a few steps closer to being publicly releasable. I’m still not confident enough that it’s crypto-secure to pull the trigger on that yet, but it at least implements everything the RFC states is required, and most of the things that are recommended. However, the more I’ve thought about it, the more I think the library would actually be much less useful for other devs than most people seem to think. Conventional single-player roguelikes are served quite well by having a set-up similar to, where you log in with some public credentials (joshua/joshua, if you like movie references), and your login shell is set to be the roguelike executable. The only systems that would gain any significant amount of benefit from libmoosshsrv would likely be multi-player roguelikes, or perhaps single-player roguelikes with interactions between games. There don’t seem to be very many of those projects around.