Announce: C-40 interactice fiction contest

After the success of the Commodore 32 machine shipped in 2004, we have decided to upgrade this machine for 2007. The new C-40 machine is available at an even lower price than the 2004 Commodore 32, has an easier-to-read LCD panel display, and is far more portable than our earlier model.

While completely compatible with the Commodore 32 games, the C-40 also has an expanded memory. This machine has some 40960 bytes of memory that game cartridges can use. Like the Commodore 32, this C-40 can play both z3 and z5 z-machine games.

We are looking forward to shipping some games that will take full advantage of the C-40s large memory for the Christmas season this year. This is where you come in: We are introducing a C-40 contest where anyone on the internet can make a z3/z5 z-machine game that fits in 40960 bytes or less. Unlike the previous Commodore 32 contest, one is not required to use Inform nor the minform library to make entries for this contest. Any system that the contest entry writer can come up with to pack as much adventure in 40960 bytes is welcome, including home-grown parsers and optimized assembly language. In addition, games are not limited to text adventures; ASCII arcade games are welcome, as long as they can be played on the C-40's 80x24 display.

We are also looking for judges to judge the games in the contest.

The rules of this contest are:

• Any kind of game that is a Z-machine version 3 or Z-machine version 5 game that fits in 40960 bytes or less is welcome.
• All games submitted to this contest must be original for the contest.
• All games must run correctly in Frotz 2.43 using an 80x24 display.
• All games must be submitted on or before Monday, December 4 2007.
• All games are to be submitted to me via email.
• Any entry submitted to the C-40 contest must be one where there is permission to redistribute the submission on my webpage and on the IF archive.

As a matter of convenience, I have version 6.15 of Inform along with the mInform library available for people who want to use this SDK (Software development kit) to make entries for this contest available here (400k .zip file).

This will run in both *nix systems (including Mac OS X) and on Microsoft Windows. Windows users: You will need to create a directory named \tmp before being able to compile programs with the inform.exe program included in the zip file.

Based on the Commodore 32 entries, one should be able to fit a small 10-room adventure in the 40960 bytes allowed in the C-40 contest, or, with some clever programming, a large 25-room adventure.

Of course, one could opt to make a huge Scott-Adams style adventure with dozens of rooms. Or, for that matter, one can make a very extensive ASCII ART arcade game in 40960 bytes (but remember the 80x24 rule!).

- Sam

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.

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.

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.

You can now play Desert Adventure online

You can now play Desert Adventure online if you have a Java-capable browser. :)

Click here to play this game

- Sam

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).

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

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, bind2csv2.py 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):

cloak-scott-0.1.zip

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