A Tale of Two Languages
As soon as the interactive fiction (or text adventure) genre got started with the arrival of Will Crowther's Advent in 1975, people have been working on ways to make creating it easier.
The original Advent was programmed in FORTRAN. The expanded version, created by Don Woods, used PL/1. Both of these languages are general-purpose computer languages well suited for many tasks, but not particularly suited for creating interactive fiction. Many of the early fans of Advent wanted to create their own version of the game, and using FORTRAN or PL/1 was difficult to impossible, depending on the computer platform to which they were porting it.
One thing many of these early implementers realized about interactive fiction was that most of it was just text, and that the operating system-specific parts of a game amounted to only about 10% or less of the overall size. The solution many arrived at was to put all the operating system-independent text and logic into a story file and then create an interpreter or virtual machine that could play or run the story file. These story files first were written in a custom language designed for creating adventure games and then compiled into the proper format. This method allowed Zork, the most popular and commercially successful Advent-like game, to be available for 23 different platforms, a testament to the power of “virtualization” decades before it became a hot buzzword.
Infocom, like all the commercial publishers, had its own language. Infocom's language was called ZIL (for Zork Implementation Language). It was not public and had to be compiled on a mainframe. When compiled, it would run inside the Z-Machine (Zork-Machine). Ports of the Z-Machine were built for every platform Infocom supported. The ZIL language was powerful and had lots of features, but its proprietary nature, and the fact that a mainframe was required for compilation, put it out of the reach of hobbyists, so the community created its own languages. Six/Fant, DDL (Dungeon Definition Language), ADL (Adventure Definition Language), TADS (Text Adventure Development System), AGT, Hugo and others were created, enabling anyone to write interactive fiction.
Throughout Infocom's short lifetime, several versions of the Z-Machine were created. These versions differed in the complexity of the story files that they would support. For example, version 3 of the Z-Machine supports up to 255 objects, 32 attributes and a maximum story file size of 128K. Version 5 of the Z-Machine could handle up to 65,535 objects, 48 attributes and a maximum story file size of 256K. Version 8 of the Z-Machine is identical to version 5, with the added feature of supporting story files up to 512K in size. Version 5 was the one used by Infocom for most of its advanced games.
By the early 1990s, all the commercial publishers had gone out of business, so if you wanted to play a new piece of interactive fiction, you either had to write it yourself or hang out on the newsgroups dedicated to interactive fiction. The classic games from Infocom and others still could be found on various re-releases and Collector's Editions. The interactive fiction genre wasn't dead, but many consider the period between 1989 and the mid-1990s to be the “dark ages”.
Despite progress, the Infocom games still were seen as the high watermark in interactive fiction, and creators had a hard time approaching them with the various community-developed systems. They just weren't powerful enough or were missing important features or were lacking a decent parser or all of the above.
It wasn't until after Graham Nelson successfully reverse-engineered the Z-Machine, and created a language and compiler that would produce story files compatible with any interpreter, that supported version 5 (and 6 and 8) of the Z-Machine, that the second golden age of interactive fiction began. He called his creation Inform, and he based the design of the language on ZIL.
Speaking of ZIL, here is a simple example:
<OBJECT SERVER (LOC SERVER-ROOM) (DESC "an ancient server") (FLAGS NODESC) (SYNONYM SERVER COMPUTER MACHINE ANCIENT OLD)>
Basically, when creating something in ZIL, you have objects, and those objects have properties and attributes. This format proved itself to be very flexible for Infocom's games, and the language was modified and improved as new versions of the Z-Machine were developed.
Inform has followed a similar path. Like the Z-Machine with which it is designed to be compatible, the Inform language has gone through several refinements over the years. The current versions of Inform are 6 and 7. Of the two, version 6 of Inform is very similar to ZIL. Here is a ZIL example in Inform 6:
Object server "server" server_room with description "an ancient server", name 'server' 'machine' 'computer' 'ancient' 'old', has scenery;
Everything is still an object, and most of the differences between them (at least in the example above) are in matters of naming. FLAGS has been renamed to has, SYNONYM has been renamed to name, NODESC has been renamed to scenery and so on. That's not to say that there aren't substantial differences—there are. Probably the main difference at this point is that Inform 6 can create far larger and more complex games than any of the ones Infocom created with ZIL.
However, even with a powerful and refined language at their fingertips, many of the top interactive fiction writers—including Graham Nelson, Emily Short, Andrew Plotkin, Sonja Kesserich and others—felt that writing interactive fiction in Inform 6 was not natural enough. Writing in Inform 6 feels like programming; there's no way around it. The flippant retort to such a statement is, “Well, yeah. You're creating a computer game. What did you expect?” Their response was that creating interactive fiction should be more like creating regular “non-interactive” fiction.
How radically different is Inform 7 from Inform 6? Well, here's the same example from above in Inform 7:
The ancient server is scenery in the server room. Understand "machine" and "computer" and "old" as the ancient server. The description of the ancient server is "an ancient server".
So, instead of statements, we have natural language paragraphs. However, while Inform 7 was in the planning stages, the decision was made that even though it was going in a radically new direction, it should still be built on top of Inform 6. What Inform 7 does behind the scenes during compilation is to parse what you write and translate it into Inform 6. The translation is done by machine, so it doesn't look like what a human would write, but it is valid Inform 6 and can be compiled by the regular Inform compiler. This allowed developers to focus on the design of the language instead of the design of a brand-new compiler.
To illustrate the differences between Inform 6 and Inform 7 I've created an example game in both languages. Due to space constraints, we can't print the full games here, but they are available on our FTP site at ftp.linuxjournal.com/pub/lj/issue174/10130.tgz.
The compiled version of each game also can be downloaded from the Linux Journal FTP site (available at the same address listed above). Even though the source code is very different, they both play the same.
As I refer to the two programs, I will use the Inform version (i6 or i7), followed by a colon (:) and the line number(s). So, if I refer to the Inform 7 version of the cd-tray object, I would write it as i7:094-095 (Listing 1).
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- RSS Feeds
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Weechat, Irssi's Little Brother
- Senior Perl Developer
- Technical Support Rep
- UX Designer
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?