A few years ago, I wrote about cheap wooden discs as D&D minis, and I’ve been using them ever since. They do a great job, and cost nearly nothing. For the most part, we’ve used a few for the PCs, marked with the characters’ initials, and the rest for NPCs and enemies, usually marked with numbers.

I see lots of people talk about using software on their laptops or smartphones for tracking combat in D&D. Mostly, people talk about tracking initiative. This always struck me as weird: I just write down everybody in order on a scrap of paper and throw it out later.

Last night was the first session of my otherwise long-running tabletop RPG game in over a year. Our old venue had become unavailable, last year, then other complications came up, and finally when things seemed like we could get things moving, there was just a lot of inertia to overcome. Finally, I sent out a grumpy, “Should we just call things off forever, or what?” Fortunately, I got quick responses from everyone: no, the previously mentioned date is good. Unfortunately, the date was in just a few days, and I only had the next session planned in broad strokes.

In 2005 or so, I started running a science fiction role-playing game, and it ran for a little under five years. I had a lot of fun, and I think the game had some merit, but I got frustrated with a lot of its failures and wrote a post mortem in which I put most of the blame on myself for a lot of problems that I brought down on my own. Below, I reproduce most of my report to the players:

Yesterday, I tweeted this:

My first ebook reader was a Sony PRS-300, which I bought just about a year ago. There was a lot to like about it, and I never felt particularly tempted to replace it with a Kindle. It really all comes down to one thing: the size. If you compare the Kindle and the Sony Reader sizes, you can see just how much bigger the Kindle 3 is than the PRS-300. The Sony reader fit much better in my pockets, so I could take it anywhere. I’d take it on walks to 7-11, to the playground with Martha, on short car trips, or anything. The Kindle is just a little too big for that to be as comfortable.

In my last entry, I wrote about how role composition and advice and BUILD interact. A number of times, I’ve wanted to get behavior that was like BUILD, but without needing the stub method hacks that are needed to get roles to participate in the method call. A very simple example came when I was writing Throwable::X, which had a mechanism for all of its contituent parts to contribute tags. The idea was that any class or role that was part of your class hierarchy could implement an x_tags method that would return a list of tag strings. These methods would all get called and the resulting set of tags would be uniqued and returned.

A very common complaint on #moose is, “BUILD is broken. I put BUILD methods in my code and they never got called.” There are a lot of variations on this. They tend to come from the fact that BUILD is not called like almost any other method. Imagine the following class hierarchy:

Right now, the most popular Perl library for testing code that throws exceptions is probably Test::Exception. It works like this:

I was happy to learn about this bizarre flag in Perl, even though it took a lot of aggravation to learn it.