In my recent campaign, I had a handout for the players. I took it out, and on a whim, I thought « a handout is boring ».
I tore it into quarters in front of their eyes. I wrote on back of the handout pieces “5“, “10“, “15“, “20“. “Make me an investigation check,” I intoned in my best DM voice. “I will grant you any pieces under your roll.“
They got 23, so I gave them all four scraps. They taped it back together and got the whole handout.
And they remembered that handout. They told players in other campaigns about the handout.
I’m a fan of the game Dungeon Master II (1993). In fact, I’m planning to get a tattoo of the rune system. So I looked around for a reference image. Here’s one from the game manual:
This looked like a nice one, because it shows the game graphics:
But there’s one problem–an entire row of runes is missing. Here’s a corrected one I made.
I’ve had a couple people ask how my TODO list works, so here’s what I’ve been doing for the last few years. I have four lists in total: a calendar, a yearly list, a daily list, and a master list.
A calendar.
The calendar has anything that needs to be done on a specific day. Birthday reminders, doctor’s appointments, and weekly activities like board game night or trash day. You’ve seen calendars. This is nothing interesting.
A yearly goals list
A yearly list of my goals for the year. I typically have 5-15 goals, and finish half of them.
This is mostly for motivation and focus. I don’t look at it much, and often only write it a third of the way into the year.
You can ignore this one.
Daily TODO list
A daily TODO list, written on paper. I throw it out at the end of each day, without copying anything off it. (I actually scan it, but I never look at the scans). This one I find very helpful.
Master TODO list
A “master” TODO list, consisting of everything I want to get done long term. I store this as a text file.
Each task is a one-line description.
I sort tasks into four categories:
Tasks that will take under an hour
Tasks that will take under a day (but more than an hour)
Tasks that will take less than a week
Tasks that will take more than a week
At the very top is just a list of all my task numbers, so I can see how many I have in each category, and skip down to them.
Tasks are marked as
[ ] Unfinished
[x]Finished (think ✅)
[X]Cancelled (think ❌, decided not to do it)
[/] Partially done (for very big tasks)
[>]Transferred to another system (doesn’t happen in the master TODO system, but sometimes I do this from my journal or a daily TODO list to indicate I wrote it down in the master TODO system)
In addition, I have a few special categories:
Urgent tasks. Sometimes I’ll have things that really need to get done soon (but not “today”, or they’d go on the daily list). Taxes often fit in here.
“Stuck” tasks. If I have no idea how to proceed with a task, it goes in a special category.
“Done” tasks. These are waiting to be archived (which is why everything you see is un-done)
“For fun” tasks. I try to keep a tasks which are just for fun in their own little section. Things like “learn to make ice cream”!
I try to minimize subtasks, in general. If I have a big task (clean the house), I’ll try to list it as “clean the bedroom”, etc as seperate tasks. If I have to, I’ll have a big task that references separate small tasks, but it’s the exception, and usually in the “more than a week” category.
And that’s about all I have to say.
I play D&D. There are a thousand initiative trackers out there. Here’s one I invented recently.
First, each player picks a Meeple to be their character’s mini.
Four PCs on a wagon move over swampy terrain.
Quick, roll initiative! The players all roll, and so do the enemies. We grab a second meeple for each player, as well as second token for each enemy. This becomes the initiative tracker.
This is the initiative order. It’s currently the red meeple hero’s turn. Next up will be the blue meeple hero, then the black cube enemy, and so on.
HACK (noun)
a rough cut, blow, or stroke. (the work was accomplished one hack at a time)
a quick job that produces what is needed, but not well (this code is a hack, but it works!)
Hack-A-Day is challenge to make complete one new project, from scratch, every day in November 2023.
Last year (2022), I set myself the challenge to make a software project every day, and met it. I had a ton of fun, and make a lot of cool video games and projects I can show off. This year I’m inviting the rest of the world to join me!
I’m a programmer, so I’m doing a new computer programming project every day. But you can do any kind of project, whatever you pick is great.
I’ve been pondering simple input methods for microcontrollers. One obvious idea is, a keyboard! But for some reason, my USB keyboards use a staggering amount of power compared to my microcontrollers–1W of power for my mechanical keyboards, maybe 0.1W for the regular ones.
Let’s look inside a commercial keyboard, and see if we can hook up to it:
Yikes. What’s going on? Well, let’s make our own little keyboard, and explore what’s going on. We’ll build it in three layers, or “index cards”:
The bottom layer has 6 vertical stripes. The top layer has 3 horizontal stripes. Each place they cross will be a “key” you can press.
In between them, we add a spacer layer (punched holes) so they keys are “up” by default, and you have to press them to make them connect.
This picture might help explain how they will go together:
Now we assemble:
The final keyboard has 6 x 3 = 18 “keys”. We write the hex digits plus a couple extra keys with marker.
If I attach alligator clips to the second horizontal screw terminal, and fourth vertical screw terminals, and wire a battery and buzzer with the terminals, I get a connection beep only when I press the key “A”:
In a real computer, we obviously can’t just move alligator clips around. Instead, we attach wires to all 9 posts–three outputs wires for the horizontal lines, and six inputs for the vertical lines. We output a signal on the first horizontal line, and see if we can read it from any of the six vertical lines inputs. Then we output a signal on the second horizontal line, and see if we can read it, and so on for the third. Assuming only one key is pressed (or none), we can identify the key. This “scanning” process could be done thousands of times a second, rapidly enough that it can’t miss our slowpoke human fingers.
Click to view interactive schematic (credit: Kragen)
And this is how most keyboards work. There are some special keys–Shift, Ctrl, Alt, etc might be on their very own line, since we want to detect key combos. And better keyboards can detect multiple keys being pressed at once (N-key rollover), which I think they do by having a completely separate wire to each key which multiple people tell me they do with a diode next to each key.
For the above project, I used:
Three index cards
A hole punch
Scissors
A ruler
A pen (NOT a pencil, since graphite is conductive)
9 screws, 9 nuts, and 18 washes. I selected #6 American Wire Gauge, which is about 4mm thickness
On some keyboards I’ve made, you have to press quite hard.
My multimeter takes a while to register a press. I think a microcontroller would be better.
You have to attach the terminals carefully. I think what’s going on is that you can actually put the screw exactly through the center of the washer which is actually making contact with the strips, so that only the washer is attached, and the screw doesn’t rub against the washer.
It’s of course fairly easy to mis-align anything. This is pretty easy to fix with care. I used the “spacer” grid to draw the centerpoint of the printed letters.
The screw heads are a bit thick, so it’s hard to press the keys in the column/row next to the screws. A piece of backing cardboard might fix this.
This was my third attempt. Here’s the second, using aluminium foil. It worked at least as well, maybe better, but it was harder to make. I just taped the foil down, taking care not to cover the contact points. I am told the aluminium will gradually oxidize, making it non-conductive.
And here’s one using graphite from drawing hard with a #2 pencil.. Graphite, it turns out, works terribly, and I couldn’t read a signal halfway down the index card. Despite what people have told me, I’m not yet convinced you can make a conductive wire out of it.
Infocom introduced (AFAIK) the concept of feelies:
[…] Imaginative props and extras tied to the game’s theme—provided copy protection against copyright infringement.[45] Some games were unsolvable without the extra content provided with the boxed game. And because of the cleverness and uniqueness of the feelies, users rarely felt like they were an intrusion or inconvenience, as was the case with most of the other copy-protection schemes of the time.[49] Feelies also provided the player with a physical aspect to the gameplay of their text adventures, giving another dimension of strategy to what would other-wise just be a text parser.
– Wikipedia (Infocom)
I love to give out feelies for my D&D campaigns. Here are some lil handout props I made:
A friend of mine, Kragen Javier Sitaker has been designing something he calls the zorzpad (see link below). I can never remember the name, so as a joke my version became the “zorch pad”. We live on opposite sides of the globe, but we’ve picked up the same or similar hardware, and have been having fun developing the hardware and software together.
The basic idea of the Zorchpad is to have one computer, indefinitely. It should keep working until you die. That means no battery that runs out, and no parts that go bad (and of course, no requirements to “phone home” for the latest update via wifi!). This is not your standard computer, and we’ve been trying a lot of experimental things. One of the main requirements is that everything be very low-power. He picked out the excellent apollo3 processor, which theoretically runs at around 1mW. In general, the zorchpad is made of closed-source hardware.
Since I’ve realized this will be a long project, I’m going to post it piece-by-piece as I make progress. Below is a demo of the display.
The graphics demo shows, in order:
a title screen
a flashing screen (to show graphics-mode framerate)
a demo of font rendering. we’re using the fixed-width font tamsyn.
We’re using a memory-in-pixel LCD. The only manufacturer is Sharp LCD. You have have seen these before in things like the Pebble watch–they’ve very low-power except when you’re updating. This particular screen is quite tiny–240x400px display (which is fine with me), but only 1.39×2.31 inches (35x59mm). The only bigger screen available in this technology is 67x89mm, a bit lower resolution, and out of stock. As soon as it’s in stock I plan to switch to it.
According to the datasheet, the screen consumes 0.05-0.25mW without an update, and perhaps 0.175-0.35mW updating once per second. We haven’t yet measured the real power consumption for any of the components.
The most obvious alternative is e-ink. E-ink has a muuuch slower refresh rate (maybe 1Hz if you hack it), and uses no power when not updating. Unfortunately it uses orders of magnitude more power for an update. Also, you can get much larger e-ink screens. The final zorchpad might have one, both or something else entirely! We’re in an experimentation phase.
Datasheets, a bill of materials, and all source code can be found in my zorchpad repo. Also check out Kragen’s zorzpad repo.
As a programmer, one task I have to do often is estimate how a long a task will take. But as a programmer, most tasks I do have never been done before, and will never be done again, so estimating how long they will take is a little tricky. Here are some tips I’ve learned over the years.
Always use clock time.
Yes, there are interruptions. You need your coffee. You didn’t get around to it that day. You want to know those things in your estimate, too. Just use the time on the clock for when a task starts and ends.
This is especially important if you’re self-employed.
Write down how long you think a task will take. Afterwords, write down how long it took.
This simple step is the most important one. This gives you a clear idea of exactly what a task is and when it’s done. It also starts automatically training your brain.
You’ll start seeing patterns. You consistently underestimate how long everything will take. Conversations take longer than they feel. Exercise takes less time than it feels like. Fixing problems is highly variable. Doing something from scratch is easier to predict.
Play a game. Predict things as well as possible.
Don’t change how you do them. You win if you guess accurately.
Use as few units as possible.
Don’t use minutes, hours, days, weeks, and months. Personally, I try to use minutes and hours for everything. Of course, when I report to my boss, I convert to days, but in my own notes I estimate things in one unit.
Learn your multiplication factor.
How long will it take you to do a project? Well, last time you had a similarly-sized project, you thought it would take 2 hours, and it actually took 14 hours. Your multiplication factor is about 7x. So this time if it feels like a 3 hour task, plan for 21 hours.
Assume there’s only one multiplication factor for one kind of work (one kind of work like your entire job, not one type of task). You can have different ones for different time scales, though (minutes vs hours vs days vs weeks).
You can measure other peoples’ multiplication factor to figure out when they’ll actually be done with tasks, but I suggest doing it quietly and not mentioning it.
Credit: Folk, but credit to Joel on Software for the idea of estimating it for each team member
To estimate a long task, break it up into pieces, and add up the pieces.
Do this if your task takes 2 days or more. Because of the multiplication factor, carefully budget time for added tasks, things you forgot, problems, etc. Or you can skip it. Just consistently pick one.
Some tasks are more variable. Saying “something will take 1 hour” is vague. Saying “something will almost certainly take between 30 minutes and 4 hours” is more precise. How big should that range be? That’s called a credible interval.
Train your credible intervals. I trained mine using bug fixing, something which happens several times a day, is hard to predict, and you have little control over (you can’t “call it done” early). Customer calls could be another great candidate.
I trained on bugfixes using 50%, 90%, and 99% intervals. There are specific mathematical scoring rules, but basically if something is in your 50% interval more than half the time, narrow it; if your interval is correct less than half the time, widen it.
Credit: Eliezer Yudkowsky (personal website, no longer up)