When are you no longer playing guitar?

From the moment magnetic pick-ups were stuck on a guitar and plugged into an amplifier, guitarists have been experimenting with altering the timbre. At first, it was cutting holes in the speaker cone, driving the amplifiers to distortion, and rotating speakers. Then it was putting various electronic circuits in the signal path for all kinds of effects. Today, digital signal processing can not only emulate all those effects. It hasn’t only expanded into simulating tube amps and vintage speakers. The signal from your pickups can be morphed into that of another guitar, re-tuned, turned from a six-string into a twelve-string, or from guitar to banjo or sitar or synth. Products like the Line 6 Variax, the Fender VG Strat, and the Roland VG-99 offer mind-boggling versatility. (While Roland has been converting analog guitar notes to digital MIDI messages to control synthesizers for a long time, the synth sounds from their VG-99 are far more interesting. It directly processes the guitar signal to morph it into synth-like sounds. Though the MIDI out is still there in case you want to control a real synthesizer with it.) One of the things that attracted me to the guitar was the directness of it. There are no keys or mechanisms. It’s hands-on-the-strings. There are subtleties of articulation. Indeed, the compelling thing about these latest technologies is that they promise to let us keep those subtleties. This isn’t simply extracting the pitch to make a guitar pretend to be a keyboard. They promise convenience without compromise. You don’t need a Tele, a Strat, a Les Paul, and an acoustic. You don’t need a Marshall stack, a Fender Twin Reverb, and a Vox AC30. You don’t need a complex chain of stomp-boxes. No re-tuning to use alternate tunings. One guitar (and no amp) can be made to reproduce all of those sounds without losing the subtleties of articulation. Is there a point at which, however, the technology has gone so far that you’re no longer really playing guitar? Or, once we lost the sound box in favor of magnetic pick-ups did we already move into a realm where anything goes?

Ask the sage

Ricky asked the Dungeons & Dragons sage:

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:

1. What would be the most fun?
2. What makes for the best story?
3. 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?

This is why Gary Gygax could write...

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.

To PS3 or not to PS3...

So far, I’ve only been able to find two reasons to buy a Playstation 3...

• Rock Band is only for PS3 or Xbox 360
• The PS3 isn’t a Microsoft product

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.

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.

Boring P&P RPG systems

• “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?

Speaking of IF and EcmaScript...

Robin Johnson has written a pretty decent text adventure engine in EcmaScript. I’m enjoying his Hamlet game.

EcmaScript, IF, and DSLs

Since I’ve been programming so much in EcmaScript (a.k.a. Javascript) at work, I decided to install the stand-alone version of Spidermonkey at home. That’s the EcmaScript implementation from Firefox. Partly because I’m interested in being able to write web applications that use the same language on both the browser-side and the server-side.

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.

C, C++, Java (no relation to Javascript), Perl, Python, Ruby, Lisp, and Scheme are general-purpose programming languages. They can be used to build programs for a wide range of applications. (Although, certainly, some are better for some applications than others.)

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.

CLUI > GUI?

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.