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).
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide