(A)D&D hardback spines

Say, you’re in a Half Price Books looking at the role-playing games. You’ll probably see some books that look like these. (Clicking it should show you a bigger version.)

(You may want to reference my D&D ID page and the time line in Wikipedia’s “Editions of Dungeons & Dragons” article while reading this.)

The top two represent first edition Advanced Dungeons & Dragons published by TSR. (Of course, it wasn’t called “first edition” at the time. That came later when second edition was published.) Later books had the orange spine. Some of the early books where later printed with new covers and the orange spine, but the contents are the same.

The third and fourth represent second edition Advanced Dungeons & Dragons published by TSR. Again, the fourth one is later books. Some of the earlier books where printed with new covers and spines to match this new trade dress but, again, the contents are the same. Note that the later books lack the handy “2nd Edition” text.

Note that all edition of the game published by TSR are highly compatible.

The fifth spine represents “third edition” Dungeons & Dragons published by Wizards of the Coast. Note, again, that there is nothing that explicitly says “third edition” here, although that’s what it is most commonly called.

The sixth spine represents “3.5” Dungeons & Dragons published by Wizards of the Coast. The “core” books did say “v.3.5” on the cover, but other books didn’t. Honestly, though, I don’t have enough 3.5 era books to tell you much about distinguishing 3.0 from 3.5. Mainly I do it through knowing pretty much all the 3.0 products, so if I don’t recognize it, it is probably 3.5. ^_^ The good news is that 3.0 and 3.5 are very compatible.

The seventh spine represents “fourth edition” Dungeons & Dragons published by Wizards of the Coast.

I believe there was only one hardback ever published for “classic D&D”. i.e. The “non-advanced” D&D published by TSR before and parallel with AD&D. That is the Rules Cyclopedia. Everything else for classic D&D was, I believe, saddle-stitched or boxed sets.

Of course, what you really need is a “pocket guide”, but this is what you get. ^_^

I’d love to do something like this for the perfect bound books as well, but I don’t actually have any of them.

Hey, Wizards of the Coast! If you’re reading this, I hope you’ll understand why I don’t think “D&D next” should just say “Dungeons & Dragons” on the cover. Even if I’m playing “D&D next”, I’m going to occasionally see second-hand books, and I’d like it to be easy to tell unambiguously if a book with “D&D” on the cover is intended for the game I’m playing or not. Yeah, yeah, I know. You’re going for the “make it easy to use anything from any edition”, but as a customer, I still want every book to tell me what edition it was originally intended for. I shouldn’t have to have the knowledge of a collector for this. There is zero reason for this confusion to exist. I know everyone at TSR and Wizards thought it made sense at the time to do what they did, but you were wrong. Please, do not contribute to the confusion. Thank you.

D&D (details & divisions)

Mike Mearls has started a new column on the Wizards of the Coast website called “Legends and Lore” to talk about the history of D&D. I think that’s a great idea. From what I know of Mike, I think he’ll do a good job of that. (Personally, I’m going to be very interested in any products Mike produces after he leaves Wizards.)

I’m going to join in criticizing his first installment, however.

Whether you play the original game published in 1974, AD&D in any of its forms, 3rd Edition and its descendents, or 4th Edition, at the end of the day you’re playing D&D.

We’re talking about at least three different games here. Sometimes differences are important and glossing over them helps no one.

This is our game, and it is as healthy, vibrant and important as we make it. The rest is details. Don’t let that details drive us apart when the big picture says we should be joined together.

Rob Conley has said, “Wizards needs to take leadership.” He’s right. Preaching unity while sowing division rings hollow. I say, if Wizards of the Coast is serious about fostering a community spirit, here’s what they should do:

1. Pull any products that are confusing history.
2. Start teaching history instead of obscuring it.
3. Admit that the marketing of “4th edition” was over-the-line with its attacks on previous editions (including 3rd).
4. Admit that pulling the PDFs from sale had nothing to do with piracy.
5. Make all the old TSR and “3rd edition” products available.

That’s not even leadership. That’s merely acting in good faith and refraining from putting obstacles in the community’s way.

Granted, Mike’s column may be a start on #2, but it will take more than that.

If I were them, I’d do #5 by simply declaring those products to be public domain. After all, they aren’t making any money off of those products anyway. Then the community could simply share what they already having instead of Wizards having to do any work to make the historical artifacts of this hobby widely available both now and for the foreseeable future.

On the other hand, if Wizards wanted to make those products available again for sale, I think that would sow some good will among the community as well. Although, at this point, they’ve created competition that is trying to fill that niche as best as they can.

---

And now, according to the Joesky rule, a new monster for Labyrinth Lord:

Flame Salamander Guardbeasts

No. Enc: 1, Align: N, Move: 120’ (40’), AC: 4, HD: 4, Att: 1 bite, Dam: 1d6, Save: F4, Morale: 8, Hoard Class: XX

Flame salamanders often keep these elemental beasts to serve like guard dogs. Like their keepers, these quadrupeds have a lizard-like appearance and give off an intense heat. Those within 10’ take 1d4 points of fire damage per round. Fire-based damage does not harm them. They can detect invisibility to a range of 30’.

Once brought to zero hp, the guardbeast does not die. Instead it transforms into two guardbeasts, each half the size of the original and each having 2 HD. When these are brought to zero hp, they likewise divide into two beasts each one-quarter the size of the original with 1 HD each. When these are bought to zero hp, they (finally) die.

Prefix notation via closures

For the programmers in the audience...

Recently I’d read yet again someone saying that prefix notation is one of the things keeping more people from using Lisp. As I’ve said before, I find it hard to believe that this is an obstacle in practice. Especially since so many languages limit infix notation to essentially numbers (and only built-in numeric types at that) and Boolean values.

(Keep in mind that I’m saying this as someone who was raised on C rather than Lisp.)

Then I started thinking about the way that method invocation in many object-oriented languages is infixish. Consider Smalltalk: "hello" at: 3 Or Java: "hello".charAt(3) Or even: bigInt.add(anotherBigInt)

So, by using the closure-as-object idiom in Scheme...

(define (number-object-ctor n)
(λ (op arg)
  (if op
      (number-object-ctor (op n (arg #f #f)))
      n)))

(define (print-number-object n)
(display (n #f #f))
(newline))

(define x (number-object-ctor 4))
(define y (number-object-ctor 5))

(print-number-object (x + y))
(print-number-object ((x * x) + (y * y)))

It’s not as practical as an infix macro. I just thought it was interesting, however, that prefix notation could be twisted into infix notation that way.

Indie elves and old-school dwarves

Ken Hite:

I’ll have more to say on the storied rivalries—and eerie similarities—between indie elves and old-school dwarves in later columns

When—around 2004—I found that the two role-playing games I wanted to play most were classic Traveller and Expert D&D, this was the thing I had noticed. These games from c. 1981 seemed to have a lot in common with current indie games. I’m looking forward to reading Ken’s thoughts about that.

Undermining your own argument, OOP-style

Say you want to convince me some assertion about programming languages. Perhaps your assertion involves object-oriented programming.

If your example is a class with public setters and getters for every private data member, then I’ve already stopped listening. Your assertion is rejected with prejudice.

If you have a good reason for using such an example, then point it out up-front, and I’ll give you the benefit of the doubt.

What I want from Hasbro

Jeff wants the original D&D box set or one of the Basic Sets in their vintage wood box line.

Which is a great idea. I’ve long been saying that the old game deserves to live on the shelves alongside other classic games.

Whatever you think of the D&D/AD&D split, there’s no doubt that the old Basic Sets sold well. There’s no doubt that a great many AD&D players got their start in the hobby with one of the old Basic Sets. There’s no doubt that an old Basic Set is even more of a different game than the current edition of D&D than it was a different game than AD&D.

Some may doubt that the old game is still as much fun today as it was then, but I’m not the only one who will vouch for that fact.

And let’s not forget that Wizards approved miniature (but complete) reprints of the Basic and Expert sets. They approved selling of PDFs of the classic products. Hackmaster and a “current edition” did coëxist in the market. The idea isn’t without some precedence.

I’d love to see the 1981 Basic and Expert sets reprinted verbatim, but if I’m dreaming...

I’d like to see the Basic and Expert books edited into a single product. With commentary by me to try to head-off some of the misconceptions that I had.

What might the actual products look like?

• A boxed set
  • 4 player booklets
  • A DM booklet
  • B2
  • Dice
• Free PDF of the player booklet online
• A companion box set (not more levels, but more spells, monsters, treasures, optional subsystems, &c.)

Maybe? I don’t know.

Of course, D&D is just the tip of the iceberg if we’re going to talk things I want from Hasbro. About Avalon Hill...

Dragon Warriors RPG back in print

A new version of the Dragon Warriors role-playing game is coming in October.

• General info
• About the rulebook

I’d never even heard of it until a few years ago. I’m looking forward to giving it a try.

Misconceptions about early D&D

There are a couple of misconceptions I see expressed about early Dungeons & Dragons.

1. It was little more than Dungeon!
2. It needed additional rules to make it go much beyond Dungeon!

Based on the things I’ve read about Arneson’s Blackmoor campaign and Gygax’s Greyhawk campaign, the first one would seem quite false. This is probably why I felt the quote from Tim Kask worth posting.

When you look at the actual rules, it can seem to be little more than Dungeon!—though hints of more are there. As Mike Mornard said...

There were no rules about it because nobody thought they were needed; the rules were just for the “nuts and bolts” mechanicals.

The night Ernie (Gygax) talked the chimera out of attacking us, it depended on how well Ernie talked, not any rules. The night my 3rd level Balrog pretended to be a photographer for Balrog Times magazine, our success depended on how well we amused the referee.

The rules were written with an “Everything not forbidden is permitted” attitude.

That’s not to say adding rules to support such things would be wrong. (That’s a whole ’nother discussion. (^_^)) In that same thread, Mike agrees with Fute when he says...

I further posit that the decision of what to codify with resolution mechanics and what to leave fuzzy is not based on some logical analysis of mediating factors, but on what the designers think is fun to roll dice for, and what they think is fun to improvise.

The point is that the lack of a rule does not indicate the lack of something at the table. (Because the referee’s role had been expanded from interpreter of the rules to living rulebook.)

More from the Kask

Our best early adventures and campaigns were about problem solving, riddle unravelling and a group effort to out-think the DM, not about hack & slash mayhem and gore. That was a part of it, but certainly not the only focus. We would often go two or more adventures without figuring Exp.

—Dragonsfoot post by Tim Kask

Blame AD&D!

In this Dragonsfoot post, Tim Kask admits that AD&D was a mistake. (O.O)

Woo hoo! I can blame TSR for making me a recovering rules-lawyer! (^_^)

Not regularly haunting DF these days (and even when last I did, I didn’t make it to “General Discussion” much anymore), this came to my attention via Jim Raggi’s blog.

Objective-C++

It has long seemed to me that C++ and Objective-C are very complimentary. It is interesting that they are actually very easy to combine. The result is known as “Objective-C++”. C++ is nice for “value” classes. i.e. Classes whose instances tend to the value of variables. Operator overloading is particularly nice for numeric classes or “smart” pointers. Exceptions are nice too. (Though I still wish C++ had “finally”. Yeah, I know the usual C++ alternative, but that doesn’t mean it can’t be convenient.) Objective-C is nice for “reference” classes. i.e. Classes whose instances tend to be referenced by pointer or reference variables. Add automatic garbage collection for the Objective-C objects, and you’ve got a really nice set of language features. Last I looked, just about all those pieces where there, but getting them to work together on whatever platform you’re on could be difficult. These days, though, I’m preferring vanilla C, Scheme, or even EcmaScript over C++ or Objective-C.

Why I fear complexity in EcmaScript 4

Various thoughts I had whilst reading Brendan’s @media Ajax Keynote. I don’t see why every EcmaScript programmer can’t learn to use closures and prototypes. These are not difficult concepts, yet they are extremely powerful. Of course, if the new stuff is really less verbose and less error-prone, I’m all for it. It’s better, however, if any more concise and less error-prone elements are built on top of existing features rather than introducing new features. The thing that worries me about adding classes to EcmaScript is that it increases the complexity. An increase in complexity in software means an decrease in stability and a decrease in security. For EcmaScript, it also means raising the barrier for implementing and maintaining the language. Less complexity means that implementors can take time to do things like removing the memory leak bugs from their closure implementation rather than wasting time adding essentially duplicate features and, by the way, implementing those poorly as well. It’s not that I’m afraid I’ll be forced to use new features that I don’t want to. I want new features, and I want to use them! I’ve been writing software long enough to know the dangers of complexity, though. Features have to over justify the complexity they bring. Better to add macros that allow more concise syntax to use existing features than to add features because you don’t have macros. Putting more burden on people writing static analysis tools is exactly the wrong thing. EcmaScript needs to encourage lots of static analysis tools. And, by the way, the less complex they are, the better they will be as well. I’m all for evolution. I certainly think things can and should be made better. But I want it to be better. I think I mostly agree with Bredan except:

• I think additional complexity needs huge justifications
• I’m suspicious of claims that anything should be added because it will improve the sales pitch

Inheritance is over-rated

Some more observations based on my experiences with EcmaScript (a.k.a. Javascript) as compared to C++ and Java:

(I suppose I could try to generalize and consider EcmaScript a representative of the Smalltalk tradition versus C++ and Java as representatives of the Simula tradition; but that probably opens a lot of other issues.)

It occurs to me that most classes I’ve written in C++ or Java have not needed inheritance. They provided only encapsulation. (Which I can do just fine in C—no object-orientation required.)

When I have needed inheritance, it has most often been for polymorphism. In EcmaScript, you don’t need inheritance for polymorphism.

(With C++, you can have polymorphism without inheritance, but that requires the complexity of templates. Likewise, in Java you can use reflection to achieve the same sorts of things, but you get more complexity with it.)

Sometimes I’ve abused inheritance in C++ or Java to work around limitations. Such as adding additional methods to an existing class. In EcmaScript, I can add methods to objects (or objects serving class-like roles) directly.

In EcmaScript, I only really need to use inheritance when I need to share an implementation, and that just doesn’t seem to come up as often in my experience.

(Moreover, I find closures—which EcmaScript has but C++ and Java lack—extremely useful.)

Now, there are—of course—trade-offs involved. EcmaScript isn’t all roses by any means. Give it a static debugger (like MrSpidey/MrFlow), and I think it could hold its own versus C++ or Java for many applications.

Give it hygienic macros (on the road-map for Javascript 3) and first-class continuations, and it starts to stack up well against Scheme as well.