Alan

Alan was the first "easy" language I encountered. What struck me, as a nonprogrammer, was that compared to other IF languages, it LOOKED doable. It looked pretty much like English. Consider a very simple object -- a baseball, say, located in a stadium. The baseball can be thrown at the scoreboard, a pigeon, or something unspecified. In Inform it looks (more or less...) like this:

Object -> baseball "baseball"
        with name "baseball",
        description
                "You see a baseball.",
         before [; ThrowAt:
                if (second==scoreboard) {
                        print "The baseball bangs against the scoreboard.^";
                        move baseball to stadium;
                        rtrue;
                }
                if (second==pigeon) {
                        print "The pigeon ducks your feeble toss.^";
                        move baseball to stadium;
                        rtrue;
                }
                else {
                        print "You throw the baseball at ",(the) second, " but
you miss.^";
                        rtrue;
                }
        ];

Even in Inform such a simple object isn't too inexplicable. Compare that with the same object in Alan:

OBJECT baseball NAME baseball AT stadium
        DESCRIPTION
                "There is a small baseball here."

VERB throw_at
        DOES ONLY
                IF obj=scoreboard
                        THEN "The baseball bangs against the scoreboard."
                        MOVE baseball to stadium.
        ELSIF obj=pigeon
                        THEN "The pigeon ducks your feeble toss."
                        MOVE baseball to stadium.
        ELSE "You throw the baseball at the $o but you miss."
                        MOVE baseball to stadium.
        END IF.
END VERB.

END OBJECT.

This example may not be the best because, while Alan never looks much more complicated, Inform never looks any simpler; still, it demonstrates how the Alan code resembles Inform stripped of what we nonprogrammers call, to use the technical term, gobbledygook.

That isn't surprising, since the task of the Alan author, as Thomas Nilsson puts it in the Alan Manual, is simply to "describe" things. "There are no variables, subroutines or other traditional programming constructs," explains Thomas, "because Alan is not a programming language."

Well, If/Then/Else statements looked suspiciously like programming to me, but presented in the form of short sentences they weren't very hard to grasp. Alan does not relieve authors of the kind of logical thinking involved in programming, but it does relieve them of a lot of technical coding considerations that can prove confusing and frustrating to the inexperienced.

Spurred into a fever of creativity by this new writing tool I poured out my soul into a...box. It was amazing. It opened, it closed. You could put things in and take them out again. I was hooked. The sensation was similar to what I felt when I played my first game of Pong and was able to affect the image on the television screen I'd grown up watching in helpless passivity. Now I could actually make my computer tell a story.

Within a few months I completed a humorous game combining memories of the late seventies punk rock scene with the Cthulhu mythos. The HeBGB HORROR! was no masterpiece, but it did finish smack in the middle of the 1999 IF Competition.

So even if you're a nonprogrammer, you can fairly quickly write a game using Alan that some people will actually enjoy. But what can't you do? Specifically, what can't you do that an Inform or TADS or Hugo author could do?

That's a difficult question for someone who doesn't know those languages. You tend not to think about doing things you don't know can be done! While writing The HeBGB HORROR! I kept coming up with new story and puzzle ideas, but never anything I wasn't able to execute adequately.

True, Alan doesn't have many bells and whistles. For example, the Alan author doesn't have recourse to the slick Invisicules-type hint system you see in Inform. There are ways to provide hints in an Alan game, but they involve bending the language to perform a function that wasn't specifically provided for. So programming hints in Alan may actually be more difficult than programming hints in Inform--provided that the author would have had the ability, time, and inclination to even learn Inform in the first place.

Also, the Alan library, which includes the verbs for which a canned response has been supplied, is not as extensive as those of some other languages, a shortcoming which is often, and erroneously, attributed to the Alan parser. The Alan author may be faced with programming more verbs than the Inform author, if only to avoid default responses that are not aesthetically pleasing. The good news is that, while a glance at the Inform library is enough to reduce a nonprogrammer to gibbering terror, it is easy to create verbs in Alan. And from my point of view as a writer, it is far more important to be able to easily create verbs that do something in my story than to have a lot of slick default responses for verbs at my disposal, especially when those verbs don't do anything anyway.