Friday, September 28, 2007

Brief reviews of all of the "Commodore 32" contest entries

Here are my brief reviews of all six of the Commodore 32 contest entries from three years ago. Since these have already been reviewed by others, I will keep my review very brief.
  1. Amusement Park. This is easily the best of all of the entries. It has some 15 rooms and a number of different puzzles to keep you challenged. Even after finishing all of the rides, there is the additional challenge of figuring out how to get all 100 points. Some reviewers criticized the writing, but it's fine for a text adventure. Indeed, this is a story of someone remembering fondly going to an amusment park, and how those memories are slowly dying. There are no significant bugs; I thought not being able to get the last five points was a bug, but figuring out how to do it simply requires paying close attention to the game's text.
  2. Downtown Train. Second place. I felt this one had the best writing of all of the Commodore 32 entries. I really liked the ending and the love story in this tiny adventure. Only three rooms and one challenging puzzle.
  3. Turning Point. Third place. This game also has good writing, and a couple of nice puzzles. However, maybe I've played too many text adventures, but I was able to solve this fairly quickly. The game only has six locations, and not as many puzzles as Amusement Park. Besides that, it's a really fun tiny adventure.
  4. Endgame. Fourth place. This would have been a fun little one-room adventure, but had too many bugs for me to fully enjoy it. For example, "erase" is not correctly implemented, which confused me until I figured out to use the verb "remove". Also, as a Christian, I found the 500-point ending a little offensive.
  5. Zombies. This would have been a fun adventure, but has too many bugs. This adventure really needed to fuller testing and bugfix cycle.
  6. Paparazzi. This is why you do not use Inform 6.30 to write a tiny 32k adventure. There is a lot of bloat in 6.30 that 6.15 (the compiler all the other entries used) doesn't have; the author of this game simply did not have enough room left to make a compelling adventure.

Friday, September 21, 2007

MaraDNS 1.3.08 and MaraDNS released

OK, I have a tradition of releasing new versions of MaraDNS on solstices. This time, however, I'm releasing a new version of MaraDNS on an equinox. Basically, new code is being contributed to the MaraDNS codebase: Mr. Sarton is improving ipv6 support and I just added NAPTR support. However, these changes can not be integrated in to the Beta-test release of MaraDNS, since the only changes in that branch are bugfixes, new SQA tests, and documentation updates.

So, I have created a new development branch of MaraDNS. This is where new features, such as NAPTR and ipv6 are being added to the code. These features have not been fully tested and I can not guarantee that development releases will even compile. However, they feature new features that some people may want to use.

Today I have branched off MaraDNS 1.3.08 (the development branch) and (the updated beta test release). The files can be downloaded from the MaraDNS download page here.

- Sam

Thursday, September 20, 2007

Interactive Fiction review: Inevitable by Kathleen M. Fischer

OK, last night, as I was relaxing, I finished Inevitable (the version submitted to Spring Thing 2003), a game by Kathleen M. Fischer I have been playing all week. Here is my spoiler-free review of the game: The puzzles are not very well designed. There is, for example, one puzzle where you have to do five different steps (two in "Easier" mode) to solve the puzzle. If you don't do any of the steps correctly, the puzzle is not solved. The game does not give you any hint you have done any of the five steps, and one description of an object is poorly written, making it very difficult to solve the puzzle in question.

If the description of that one object was better written, I would have been able to solve the one puzzle without cheating. And yes, the post-SpringThing version of this game has the same problem with the item description in question.

I had to resort to using txd to decompile the game to solve this one puzzle.

Once this puzzle was solved, I was able to finish the rest of the game within 30 minutes.

The game feels rushed, particularly near the end. It starts off with giving you wonderful puzzles, and memories that give the game real flesh, but then degenerates in to a very frustrating puzzle-fest, where you have to solve about 10 puzzles without being able to visit very many new locations when solving each puzzle, and where you get no real new memories after solving these same puzzles.

A lot of the mythology of the universe of this game is completely unexplored. For example, (minor spoiler) we never get a hint about why the bad guys massacred so many people in the past; something which I felt should have been answered in the game. I also did feel the story, as I was finishing the game, was not very compelling.

On a 1 to ten scale, I give this game a five. Minus three points for poor puzzle design, and minus two points for not having the story in the conclusion of the game as compelling as the story near the beginning of the game.

MaraDNS snap update; MaraDNS and 1.3.08 coming out tomorrow

I have updated the snapshot release of MaraDNS today to include some updates to the FAQ included with the 1.3 branch of MaraDNS. I have also added (completely untested and probably currently not working) support for the NAPTR record, as requested on the MaraDNS mailing list. The update to the FAQ will be included in; the NAPTR code will only be in 1.3.08.

I plan on releasing MaraDNS 1.3.08 and tomorrow.

I have also made a snapshot for the 1.2 branch of MaraDNS, which integrates the update code in this branch, and which fixes a one-byte typo in the FAQ.

The 1.3 snapshot can be downloaded here and the 1.2 snapshot can be downloaded here.

As an aisde, I have removed all unsupported older versions of MaraDNS from the webpage; the only versions of MaraDNS available on the webpage are recent snapshot releases and the three supported releases of MaraDNS:,, and 1.0.41.

- Sam

Tuesday, September 18, 2007

MaraDNS snapshot update

This weekend, I silently uploaded a new snapshot of MaraDNS. Today, I have slightly updated that snapshot. This snapshot has some new code:
  • IPV6 support added to askmara and fetchzone by Jean-Jacques Sarton.
  • updated
Since this is new code, I will be branching the MaraDNS tree when I release and 1.3.08 this Friday. Basically, is MaraDNS + updated tests + bugfixes + updated documentation; 1.3.08 will be with Sarton's ipv6 code added. This way, people can contribute new features to MaraDNS while I prepare the 1.3.07 stable release of MaraDNS, which I plan on releasing on December 21st.

It can be downloaded here

- Sam

Thursday, September 13, 2007

New MaraDNS snapshot; help for people trying to install Linux on a 1420

I have updated the MaraDNS snapshot today. This snapshot has a couple of fairly minor changes:
  • There is a new mararc dictionary variable, future that will allow new parameters to be set in future versions of MaraDNS, but still have the mararc file parse in MaraDNS 1.3. For example, let us suppose a future version of MaraDNS sends NOTFY packets when a zone file is updated. Then we can have a mararc variable send_notify_to, and for people who wish to use the same configuration file in MaraDNS 1.3, future["send_notify_to"].
  • I have doubled the default amount of memory allowed to be allocated, since I saw MaraDNS hit the maximum the other morning, when I was on a broken internet connection
It can be downloaded here
For people trying to get their Dell Inspiron to work in Linux, Dell now has an ISO image available for installing Linux on to one of these computers.

- Sam

Wednesday, September 12, 2007

On limiting the size of an interactive fiction game

I have been reading some of Emily Short's essays. One essay that, in particular, stood out to me is one on Interactive fiction geography. In this essay, Emily talks about some ways to put a border around an IF map, and how to make this border exist without making the player feel claustrophobic. She suggested some ideas for a boundary; I have a couple other ideas for a boundary in IF:

  • One, which I implemented in Desert Adventure, is to have the boundary be one where the player realizes they will die if they go past the "edge" of the map. Basically, I have a "lost in desert" location where all the exits take the player back to the start location, with the message "Lost in the desert, I walk towards the oasis, the only landmark I can see." seen when they travel from this location.
  • Another is to not have a boundary at all. How is this done? With a random map generator. Basically, have the computer generate interesting scenery which extends forever no matter what direction the player goes. The problem with this approach is that there is a limit to the kinds of maps random map generators can make. Basically, a random map generator can make a reasonable approximation of natural scenery, or maze-like maps. Also, a computer can't make the kinds of clever puzzles that are the hallmark of most kinds of interactive fiction.

    What a random map generator can generate are "hack and slash" maps; they can work when the objective is to, for example, kill monsters and collect treasures. Random map generators can also make basic "find the key" puzzles; and possibly even "examine things to find stuff" puzzles, but nothing really more complicated than that.

    I can see something like this for a role playing game, where the player has skills and hit points, and has the objective of killing monsters in order to acquire more skills and hit points, which allow them to kill even nastier monsters.

    However, I am not sure whether this kind of game will appeal to many interactive fiction players. It's a different game, and we knew this as far back as 1981 (Such as Scott Adams' "If you like to kill monsters play 'MACES & MAGIC'!" comment in Savage Island).

Anyway, some food for thought for game designers.

Monday, September 10, 2007

MaraDNS snapshot update; Desert Adventure updated

I have uploaded a new snapshot of MaraDNS today. In this updated snapshot, Jean-Jacques Sarto has added support for, and I have documented, FQDN6 records, records that allow you to set up "reverse" and "forward" DNS support for IPV6 addresses.

I have also changed the formatting of the source files: the .c and .h files no longer have tabs, but use multiple spaces instead. This is something I should have done before releasing 1.2; it makes the source code look consistant across different editors. since this change means that it will be more difficult to use patches for older versions of MaraDNS that use tabs instead of spaces. At least I did it before 1.3.

Finally, I have added a few more SQA tests.

I have also updated my Desert Adventure game. I made one puzzle a little easier and another puzzle a little harder (But help is now available for this harder puzzle). Also, I fixed one bug and revised the compile script to remove more unused whitespace, allowing more adventure to fit in the same amount of space.

In addition, I revised ScottFree to give SavedRoom initial value of 1 and added a z-machine version of Desert Adventure (created with scott2zip, revised by myself, and compiled with an ancient version of Inform) for people who don't feel comfortable compiling ScottFree.

The update is available here (80k zip file).

Friday, September 7, 2007

Making MaraDNS even more secure

Now that MaraDNS has had over five years of real-world testing, and a few minor security problems (nothing worse than denial of service) have been found, here are some thoughts on how to make a program have the minimum number of security problems possible:

  • Do not add features to a program after a design/requirement spec for the program has been written. All three MaraDNS security problems existed because I added features to the program after the basic program was done. Namely:

    1. I added round-robin rotation to the codebase after the basic authoritative-only DNS server was written. This added a denial of service security bug to the code.

    2. I changed the authoritative code to give out nicer messages when invalid DNS packets were received. This added another denial of service security bug to the code.

    3. I added ipv6 to MaraDNS. This was the cause of a third, and final (so far; knock on wood) denial of service security bug to MaraDNS.

    It also looks like the one known denial of service security bug in djbdns was the cause of a similar feature creep; basically, the existence of TCP code in dnscache caused the bug.

  • Code in a style that make memory leaks difficult. For example, make sure there are a limited number of strings allocated at the beginning of a function, and use a variable to store the return value. Use gotos for error trapping if programming in C, since C does not have real Java-style error trapping, nor C++'s automatic destructors.

    If a block of code needs a temporary string, declare the string at the beginning of the block and don't leave the block without zapping the string. For example:

    function() {
    /* This is *always* the first part of a
    * block that allocates
    * strings. Yes, we allocate every last
    * string *before*
    * doing anything else */
    overflow_resistant_string *s1, *s2, *s3;
    if(allocate_memory(s1) == 0) {
    return ERROR;
    } else if(allocate_memory(s2) == 0) {
    return ERROR;
    } else if(allocate_memory(s3) == 0) {
    return ERROR;

    int return_code = OK; /* If you're using
    * GCC2 still, upgrade */

    /* Now we run normal code */

    /* Lots of snipped code here */

    if(do_something_important == FAILS) {
    return_code = ERROR;
    goto leave_function;

    /* Lots more snipped code */

    if(weve_already_funished == YES) {
    return_code = YIPEE;
    goto leave_function;

    /* More snipped code */

    return return_code;

  • Use buffer-overflow resistant strings. Check; this is why MaraDNS (knock on wood) hasn't had a security problem worse than denial of service.

  • Use as many operating system features to sandbox the code as possible. Check; this is why MaraDNS is in a chroot() environemt running as the "nobody" user (it is also possible to have MaraDNS run as a maradns-specific user if desired)

Thursday, September 6, 2007

Desert adventure: A new tiny interactive fiction story

I spent all day yesterday making an interactive fiction story called Desert adventure. This is classic late-1970s early-1980s adventure: Our adventurer is all alone in a desert near an oasis, and has to find the treasures.

This is an original adventure for the Scott Adams' adventure interpreter language, and is, to the extent of my knowledge, the first original adventure for Scott's language in over 20 years.

While Inform, Adrift, and what not are more capable than Scott's language at making complicated adventures, Scott's system has the advantage of being extremely compact, being originally designed to run on a system with only 16 or 24 kilobytes (yes, kilobytes) of memory. For example, my implementation of Cloak of Darkness for Scott's system is under 3,000 bytes in size. Compare this to the Z-machine version of the same game, which is over 50,000 bytes in size.

The program to run Scott Adams' adventures is under 20k in size; the Z machine interpreter is about 80k in size, and other interpreters are even bigger.

My goal in making this adventure was to make a playable, very small adventure that people can freely include with programs like ScottFree.

In particular, I wanted the adventure to fit in under 6 2048-byte blocks (12288 bytes), which it barely does.

To play this game, play it online or download it here (80k zip file). This zipfile includes a Windows program for running Scott Adams adventures, a version of ScottFree for *NIX (including MacOS X in a terminal) updated to not have bugs when compiled in a modern version of GCC, and a z-machine version for people who don't feel comfortable compiling ScottFree.

- Sam

Update: 2007/09/10: Updated version to 1.1 and added note there is now a z-machine version of Desert Adventure. 2007/09/11: Added online version

Monday, September 3, 2007

MaraDNS snapshot update; Cloak of Darkeness

I have made an update to the MaraDNS snapshot public today. In this update, I have removed a lot of old cruft from the MaraDNS tree. The biggest savings comes from removing the .pdf manpage reference from the documentation tree; this reference doesn't include the tutorial, so is of limited use. I have also removed some old documents and programs not needed by MaraDNS which haven't been looked at or updated in years.

In addition, now has a man page, and the authoritative tutorial has been updated to point out the recursive resolver had dnscache-style custom name servers for subtrees of the DNS space.

Jean-Jacques Sarto has contributed a patch that allows csv2 zone files to have FQDN6 records in in csv2 zone files, for better ipv6 support. I have not integrated this patch yet; I have to make sure he licenses the patch under a MaraDNS compatible license and that the patch doesn't introduce any other bugs.

The September snapshots of MaraDNS can be downloaded here.

I have had a long-term interest in Interactive Fiction ever since the days of Adventure and Zork in the late 1970s. This weekend, being a little bored, I have ported Cloak of Darkness to the parser Scott Adams used for his late 1970s and early 1980s video games.

I had to do some hacks to pull it off; namely, I have the adventure teleport the player from one room to another instantly under certain circumstances:
  • If the player tries to go out in to the street from the foyer, they enter the street. They are then instantly teleported from the street back to the foyer with the "You've only just arrived, and besides, the weather outside seems to be getting worse." message.
  • If the player has hung up the cloak, and enters the bar, they are instantly teleported from a dark room to the actual bar.
Basically, since Scott Adams' format kills the player if they hit a wall in the dark, I made the bar a dark room with exits in all directions. If they take any of the exits, they go to another dark room and have a 50% chance of messing up the message for every turn they are in the second dark room. Both the first and second dark room's "North" exit takes them back to the foyer.

Another hack is that the Cloak is not a normal pickable (carryable) item. Instead, "drop cloak" is explicitly given two actions:
  • Give the player the "This isn't the best place to leave a smart cloak like that lying around!" message in any room besides the cloakroom
  • Put the cloak on the hook in the cloakroom, and set the flag so the person, when in the dark room, is instantly teleported to the bar.
Also, get cloak when the cloak is in the cloakroom picks up the cloak, and clears the "telport from dark room to bar" flag.

The game makes assumptions that Scott Adams' adventures never had, but it works pretty well. In ScottFree, I never see the teleport. It is possible, were this file used in an actual 1970s computer, that the player might see a brief flash of the room they were teleported from before being teleported.

My port is available in a zipfile, along with a version of the scott2zip converter updated to run in Perl5 and ScottFree updated to not have a bug when compiled in GCC4 (A recent version of the Linux C compiler):

The above zipfile can be freely uploaded to the if-archive or anywhere else (I assume Roger Firth allows people to freely distribute implementations of Cloak of Darkness).

I think this is the only new Scott Adams game in over 20 years. Considering how difficult it was to pull off, I can see why no one makes games in this format any more.

- Sam