B/X D&D thief house rule

Just an idea for a house rule for B/X Dungeons & Dragons. Apply a thief’s dexterity adjustment to their level to determine their thief skills. So, a 1st level thief with an 18 dexterity would use the 4th level row of the thief skills table.

The idea is generally like the “Dexterity Table II” from AD&D (PHB p. 12), but in a simpler, more B/X-style form.

Is it crazy?

Dialogue with a printer

My printer: I’m out of magenta ink.

Me: How about the other inks?

Printer: I’m out of magenta ink.

Me: I know, but just show the status of the other inks like you did when they were all full.

Printer: I’m out of magenta ink.

Me: sigh

Me: Scan this.

Printer: I’m out of magenta ink.

Me: sigh

After buying replacements for all six ink cartridges and replacing magenta...

Me: Print this.

Time passes.

Printer: You know what? The gray is empty.

Replace gray cartridge. Time passes.

Printer: Hey, look! The black and yellow are empty too.

Replace black and yellow cartridges. Time passes.

Printer: OK! What did you want me to print?

Me: sigh

Step-die RPG systems and variance

I once heard a sports pundit—it may have been Frank Deford—say that amateur golfers ought to stop saying, “At least I’m consistent.” He argued that consistency was exactly what separated the amateur from the professional.

I mentioned that I like the idea of “smaller is better” step-die systems over the more common “bigger is better”. Here’s why: In a step-die system, the variance of a skill check changes with the character’s skill. In a “bigger is better” step-die system, the variance increases with character skill. In a “smaller is better” step-die system, the variance decreases with character skill.

The latter makes more sense to me.

Dictate

Dictation for the iPhone is very impressive. I am not sure, however, that speaking this message has been faster for me than typing it. Furthermore I think the time it takes me to type a message is dwarfed by the amount of time it takes me to organize and compose my thoughts.

The trouble with retweeting

It bothers me when someone I follow on Twitter says “please retweet”.

Case 1: Someone who follows me also follows the original tweeter. My retweet will just be noise for them.

Case 2: Someone who follows me and isn’t interested in the original tweeter. My retweet will just be noise for them.

Case 3: Someone who follows me who doesn’t follow the original tweeter but would be interested in following them. The retweet is only useful to the extent that it has made this person aware of the original tweeter.

While case 3 is good, a lot of case 1 & 2 noise is going to be generated to achieve it. Surely there are better ways to help people find followees than this.

I think the occasional “this person tweeted something unusually clever or insightful that I want to share” kind of retweet is just fine. “Please retweet”, however, tends to signal my above concerns.

Because it’s just like forwarding e-mail, isn’t it? Occasionally there are times when forwarding an e-mail is exactly the right thing to do. E-mails that were written with the expectation of being forwarded, however, are the one’s that are wasteful.

Interactive install

Computer install & update mechanisms should ensure that all needed user interaction happens up-front. It should also tell the user when the interactive portion is complete.

People debate whether these machine actually improve productivity, but babysitting them during lengthy operations is clearly unproductive.

Separating layout

The hypertext markup language (HTML) used to create the pages of the world-wide web began as a description for simple documents with hyperlinks. It supported headings, paragraphs, lists, and links. (Plus a handful of other things.)

Then tables were added. (Also notable was the addition of forms, but that’s another branch of the story.) Tables could not only be used to display tabular data, they could also be abused to create layouts beyond simply headings, paragraphs, and lists.

As styling was added to HTML, there was also a move to separate style from content, which brought us cascading style sheets (CSS).

There were problems with table-based layouts. To try to get away from the problems of table-based layouts, people have tried various HTML+CSS tricks. Many of which are based on a grid. Personally, I find these at least as troublesome as table-based layouts.

Perhaps we should separate content, style, and layout. HTML tables are, I think, a good way to describe a grid-based layout. If we, however, separate them from the content, does this eliminate or mitigate the problems we had with table-based layout?

OK, at this point, some understanding of HTML and CSS will be required.

Imagine a grid file containing mark-up similar to HTML tables. We’ll replace “table” with “grid”, “tr” with “row”, and “td” with “cell”. Cells support the rowspan and cellspan attributes. Cells contain CSS selectors that indicate what content from the HTML file should appear within that cell in the layout’s grid.

<grid>
  <row>
    <cell rowspan="2">div#header</cell>
  </row>
  <row>
    <cell>div#body</cell>
    <cell>div#rightsidebar</cell>
  </row>
  <row>
    <cell rowspan="2">div#footer</cell>
  </row>
</grid>

There’s probably a better way to describe layout, but I think HTML tables aren’t a bad start—once separated out. Personally, I’m not crazy about SGML/XML for things other than mark-up. S-expressions or some other syntax might be preferable. (CSS has its own syntax, so let’s not feel constrained to keep SGML/XML syntax for grid files.)

; Just a thought...
(grid (row (cell (2 1) div#header))
  (row (cell div#body)
       (cell div#rightsidebar))
  (row (cell (2 1) div#footer)))

Without browser support for grid files, we could write a program that would read HTML and grid files and generate HTML that faked it with tables.

Just a thought.

P.S. Since writing this, I came across this: The Evolution of Web Design