29 October 2007
If a character has polymorphed into a hydra and loses a head, what happens when he returns to his normal form?
Here’s my answer:
Ricky, when you come to a question like this—that the rules do not explicitly cover—there are three methods the Dungeon Master may use to answer this question:
- What would be the most fun?
- What makes for the best story?
- Let the dice decide.
Most importantly, however, is to recognize that this is the key ingredient of games like Dungeons & Dragons: They have a human referee (Dungeon Master, Game Master, &c.) who serves as a living rulebook. As was written in the third of the original booklets...
In this light, we urge you to refrain from writing for rule interpretations or the like unless you are absolutely at a loss, for everything herein is fantastic, and the best way is to decide how you would like it to be, and then make it just that way!
...why have us do any more of your imagining for you?
What I think isn’t important. It is what your DM decides that is.
I will, however, note that a wise DM seeks & considers the advice of his players.
So far, I’ve only been able to find two reasons to buy a Playstation 3...
On the other hand...
- PS3: $400
- Xbox 360: $280
Turns out there is going to be a version of Rock Band for the PS2, though it won’t have all the features.
19 October 2007
(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.)
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.
- “Combat is just trading blows until somebody runs out of hit points.”
- “After he casts his single spell, a first-level magic-user has nothing to do.”
- “A rogue’s sneak attack doesn’t work against plants, so the rogue player is going to get bored in encounters with plant-monsters.”
(These all happen to apply to various editions of Dungeons & Dragons, but similar sentiments have been uttered about every P&P RPG.)
If a player is bored during a pencil & paper role-playing game, is it the game system’s fault?
Maybe, but I think that is rarely the case. After all, the people who created, developed, and play-tested the game didn’t find it boring or it wouldn’t have been published.
The examples above tend to be cases of not seeing the game for the rules. Most games are more than just the rules. According to Hoyle, the rules of chess are seven pages. Yet I’ve got one 217 and another 362 page book on how to play it. Reading the rules that govern bidding in bridge won’t teach you how to bid. How much more does this apply to role-playing games?
08 October 2007
Of course, there are a few server-side EcmaScript solutions out there, but I’m used to rolling my own light-weight version when investigating such things.
I didn’t want to jump right into that, however, so I tried to come up with an idea for a command-line program I could start with. Spidermonkey comes with a command-line interpreter, but it is very minimal. Hardly more than readline and print.
So, I thought of text adventures (a.k.a. interactive fiction). I had the basics of Cloak of Darkness mocked up PDQ. It went faster and farther than I think any of my other attempts at such a program has gone in any language. My opinion of the EcmaScript is continuing to increase. I began to think I should break out some of my old text adventure ideas.
The thing is, though, I’d have to make some significant enhancements to Spidermonkey’s command-line interpreter to really make it practical for IF. It would make a lot more sense to just use browser-based EcmaScript (instead of command-line) or to use Inform, so that people besides just me could actually play it.
Inform is a DSL (domain specific language) for interactive fiction. That’s fancy computer geek jargon for a language specialized for a specific purpose.
HTML and Postscript are domain specific languages. (Incidentally, HTML is not a programming language, but Postscript is.)
EcmaScript isn’t really a domain specific language, but as it is most widely and most easily used within web browsers, it often tends to be one in practice.
I’m all for DSLs, but the problem I have with most of them is that they’re wholly new languages. Ideally, a DSL—unless really simple—should be an extension or a subset of an existing language. This is the resistance I have towards using Inform.
The Lisp and Scheme advocates like to point out how they often extend their languages to create DSLs within them, which I’m finding to be a very compelling argument.
03 October 2007
In The Command Line—The Best Newbie Interface?, Richard Wareham makes a case for a command-line user-interface being better—even for non-technical users—than graphical user-interfaces. A case based on his experience teaching a beginners’ computing course.
It’s an interesting line of thinking. If a fraction of the effort that has gone into GUI’s were applied to command-line interfaces (not—by the way—to discount the advances that have been made), I think his case could be bolstered considerably.
I probably spend roughly equal time with both types of interface. Which suggests that—for me—each has strengths & weaknesses; neither being superior. I have a tendency, however, to think that this balance wouldn’t hold for average users.