Jim Ingram's personal website. Mostly about programming.
A couple of summers ago, I ran a West Marches-style campaign for several of my coworkers called “Riverkeep”, using the Swords & Wizardry Complete rules. There’s a lot of prep work for that sort of campaign, even if you fill in most of the map with pre-existing modules as I did. On top of that, each session had between 8 and 12 players, which is a lot of fun, but also exhausting to run. As a result, the campaign only lasted a few months before going on indefinite hiatus, due to DM fatigue. (Note: I don’t blame the players at all. They were and are wonderful people.) A couple of weeks ago the subject came up in conversation again, and I offered to do a one shot session, unconnected to the previous campaign, for 3 to 6 players. I ended up getting four takers: a couple of campaign veterans who were already familiar with Swords & Wizardry; one guy who had played a bit of 4th and 5th Edition D&D and Dungeon World, but not any older rules; and one guy who had never played a table top RPG before, and whom I’d promised wouldn’t need to read any rules beforehand. We decided to play a single session of about four hours, and in order to make the most of our time, I’d bring several pregenerated characters for them to choose from.
Sometimes I like to disassemble ROM dumps for old NES games to figure out how they work. It’s sort of like putting together a puzzle without knowing what the picture will look like beforehand. You start disassembling opcodes at a known entry point (the NES’s 6502-based CPU will jump to the address stored at $FFFC-$FFFD in the ROM cartridge when the machine resets) and follow the control flow through the rest of the ROM. The puzzle isn’t the disassembly itself, which is a purely mechanical process. It’s figuring out what the assembly code is doing, and why it’s doing it. And along the way you can sometimes find interesting bits of code that are unlike what a modern programmer would (or could) write in a high level language. I found one such bit of code in the initialization routines for Excitebike.
You can specify a precision with printf’s
%s conversion to limit how
many characters are printed:
const char *greeting = "Hello, World!\n"; printf("%.5s\n", greeting); // prints "Hello\n"
But what if you don’t know until runtime how many characters you need?
I just started following along with Bob Nystrom’s Crafting Interpreters book a few days ago, and one of the first things I did was set up a Gradle project for the jlox interpreter. It’s a simple Java application with no external dependencies, so the build script is hardly interesting, except for one thing: starting in Chapter 5, there is a GenerateAst “script” needs to be run before compiling, because it generates source files. Turns out, it’s pretty easy to add a code generation task to a Gradle build.
I’ve been a member of SDF Public Access UNIX System for around fifteen years, at the ARPA level for most of that time. They provide a great service, and have hosted various incarnations of my homepage since I first signed up. The most recent was started in November of 2014 as a blog about programming, built with Jekyll and only lasting for a couple of posts (which I have copied over to this site). Then life got busier, and my blog fell by the wayside.