Acme MUD

formerly "untitled gamification platform"

A Quick Post Before Bed

Haven’t coded anything for about a week. I started to code the pager last week but lost interest pretty quickly. It does need to get done though; having to use the editor to browse code is definitely sub-optimal. Now is when I kinda wish I had an apprentice or an intern or something to hand off projects to. It might be a bit much for someone who is brand new to programming, but on the other hand it might not be. Either way, it’s something that I don’t personally need to code the rest of my stuff, because I have my own development environment and can more code externally out in zsh. However, it does need to be done were I to throw up a demo instance of the game anywhere. All this makes it a good candidate for a junior programmer, because they don’t have to stress over too much over how quickly they’re progressing. Meanwhile I’d be free to work on the more architecty stuff. Kinda makes me think that maybe I should table the pager and instead put a little more effort into looking for a good candidate. The only reason I decided to work on it now was because I’ve got most of the rest of the shell already done.

Speaking of which, sometime after my last post I did quietly finish path expansion. It wasn’t too much work, I actually already wrote the algorithm years ago for EotL but I never implemented it anywhere. Revisiting the code went fairly smoothly. It’s actually pretty cool – it supports wildcards in the middle of paths, so you can do like ls /usr/*/workroom.c to list all the workrooms. get_dir() resolves the actual wildcards for us, so the thing runs pretty fast. The one thing I would like to add is support for the ** wildcard, but the driver won’t resolve that one for us so it’s a bunch more work. It’d be nice to have for a future release, though.

I’ve actually started creating issues on github to track stuff like this, and I’ve been trying to use the special tags in my commit comments when I close out tasks and such. The more workflow we can capture, the more interesting game mechanics we’ll be able to stitch in later. What github offers in the way of issue tracking pales in comparison to Atlassian Jira, which is what we use at WSI; but I think it’s better to keep things simple for now anyway.

I guess next I need to start thinking a little bit about recruitment, and also pick something else to work on. I’m thinking object expansion, but I gotta get my head around what exactly it means to refer to an object on the command line, both in author mode and in player mode. It seems like you might want to be able to apply different expansion algorithms depending on context; like tell.c is going to look at users anywhere in the game but look.c is only going to care about items that are present. How much of that do you need to support and how much of it just confuses the UI? And how much does this even matter right now? Depending on the level of abstraction we can punt some of these questions until later, when we actually have a functioning game. In any case, pretty fun stuff.

Maintained by Bobby Schaetzle