Thursday, 16 May 2019

Building the Infocom Games using ZILF

The last three posts covered building the Zork trilogy, the Mini Zorks and the Enchanter trilogy. Two issues were identified.
  1. Can the game be built using release 0.8 of ZILF or is the latest development version needed?
  2. Does the game file fit naturally within targeted z-machine memory limits or is an abbreviations file needed to achieve this?
Here are the results of trying to build all of the Infocom games contained in The ZIL Files repository.

Release 0.8 of ZILF without an Abbreviations File


Sixteen of the games can be built in this manner.
  • Zork I
  • Zork II
  • Starcross
  • Deadline
  • Zork III
  • Infidel
  • The Witness
  • Planetfall
  • Enchanter
  • Cutthroats
  • Seastalker
  • The Hitchhiker's Guide to the Galaxy
  • Sorcerer
  • Mini Zork I
  • Mini Zork II
  • Checkpoint

Release 0.8 of ZILF with an Abbreviations File


Another twelve of the games can be built in this manner.
  • Suspect
  • Wishbringer
  • A Mind Forever Voyaging
  • Spellbreaker
  • Ballyhoo
  • Leather Godesses of Phobos
  • Trinity
  • Moonmist
  • Stationfall
  • Bureaucracy
  • Plundered Hearts
  • Infocom Sampler

Latest ZILF without an Abbreviations File


Twelve of the games can be built in this manner.
  • Suspended
  • Hollywood Hijinx
  • Nord and Bert Couldn't Make Head or Tail of It
  • Border Zone
  • The Hitchhiker's Guide to the Galaxy (Gold Edition)
  • Zork I (Gold Edition)
  • Sherlock
  • Leather Godesses of Phobos (Gold Edition)
  • Zork Zero
  • Zork I (German Edition)

Latest ZILF with an Abbreviations File


Another two of the games can be built in this manner.
  • The Lurking Horror
  • Beyond Zork

Failures


The following six games can't yet be built.
  • Shogun
  • Journey
  • Arthur
  • Milliways
  • The Abyss
  • Mini Zork (1982)

Saturday, 11 May 2019

The Enchanter Trilogy

Enchanter


This compiles without error using release 0.8 of the ZILF toolset.


Sorcerer


This also compiles without error using release 0.8 of the ZILF toolset.


Spellbreaker


This fails because the length of the game file would exceed the .z3 maximum of 128k.


The game file can be made smaller by first generating an abbreviations file,


then deleting the corresponding .zap file


and finally trying again.


The Mini Zorks

Mini-Zork I


This compiles without error using release 0.8 of the ZILF toolset.


Mini-Zork II


This also compiles without error using release 0.8 of the ZILF toolset.


Zork (Mini Zork 1982)


This doesn't compile and appears to be in a state of partial development.


Thursday, 9 May 2019

The Zork Trilogy

It's been a while since I last posted here. Jesse and I have been tidying and fixing The ZIL Files and Jesse has been updating ZILF where necessary. The situation right now is that 6 of the 48 Infocom games do not yet compile. These are: Shogun, Journey, Arthur, Milliways, The Abyss and Mini Zork 1982.

Let's start where I left off. All three of the original (.z3) Zork games compile without errors using release 0.8 of the ZILF toolset.

Zork I



Zork II



Zork III




However, both Zork I Gold Edition and Zork I German Edition (.z5) need to be compiled using the latest development version of ZILF which has to be built from source.


Zork I Gold Edition



Zork I German Edition




To be continued ...



Saturday, 20 April 2019

The ZIL Files

I've started a new GitHub organisation called The ZIL Files which will hold the Infocom source files from Historical Source in one repository. I'll be trying to compile this source code using ZILF. This blog is where I'll highlight difficulties and (hopefully) present workrounds.

The ZIL Files and Historical Source are linked on the right.

Thursday, 28 March 2019

William Tell: a tale is born

Initial Setup


The William Tell game will start with an introduction.

<ROUTINE INTRO ()
    <TELL
"The place: Altdorf, in the Swiss canton of Uri. The year is 1307,
at which time Switzerland is under rule by the Emperor Albert of
Habsburg. His local governor -- the vogt -- is the bullying
Hermann Gessler, who has placed his hat atop a wooden pole in
the centre of the town square; everybody who passes through the
square must bow to this hated symbol of imperial might."
CR CR
"You have come from your cottage high in the mountains,
accompanied by your younger son, to purchase provisions. You are
a proud and independent man, a hunter and guide, renowned both
for your skill as an archer and, perhaps unwisely (for his soldiers
are everywhere), for failing to hide your dislike of the vogt."
CR CR
"It's market-day: the town is packed with people from the
surrounding villages and settlements."
CR CR
    >
>

We'll be using a basic scoring system similar to the one implemented by Inform 6 so we define top marks:

<CONSTANT MAX-SCORE 3>

The default mode will be verbose:

    <SETG MODE ,VERBOSE>

At the start of the game, we want Tell to be equipped with his bow and quiver of arrows:

    <MOVE BOW PLAYER>
    <MOVE QUIVER PLAYER>

Tell will be wearing the quiver:

    <FSET QUIVER WORNBIT>

He will also have a description (seen by typing EXAMINE ME) appropriate to the game:

    <PUTP PLAYER ,P?ACTION TELL-PLAYER-F>

which will require a new player action routine:

<ROUTINE TELL-PLAYER-F ()
    <COND
        (<N=? ,PLAYER ,PRSO>
            <RFALSE>)
        (<VERB? EXAMINE>
            <TELL "You wear the traditional clothing of a Swiss mountaineer." CR>
            <RTRUE>)
    >
    <PLAYER-F>
>

Templates


Templates are used to define families of closely related objects, all of which behave in the same way.

To use this feature of ZILF, the following line must be included:

<USE "TEMPLATE">

For example, if every room in a game is lighted, it would be useful to have a way of saying so. This can be done by defining the following template:

<OBJECT-TEMPLATE
    LIGHTED-ROOM =
        ROOM
            (FLAGS LIGHTBIT)
>

We will use the LIGHTED-ROOM template in this game and a few other templates besides.

A Template for Props


For scenery items whose only role is to sit waiting in the background in case the player might EXAMINE them, a PROP template is defined:

<OBJECT-TEMPLATE
    PROP =
        OBJECT
            (FLAGS NDESCBIT)
            (ACTION PROP-F)
>

<ROUTINE PROP-F ()
    <COND (<NOT ,PRSI>
        <COND (<VERB? EXAMINE>
            <RFALSE>)
        (ELSE 
            <TELL "You don't need to worry about " T ,PRSO "." CR>)>)>
>

A Template for Furniture


For supporter items which shouldn't be moved by the player, a FURNITURE template is defined:

<OBJECT-TEMPLATE
    FURNITURE =
        OBJECT
            (FLAGS CONTBIT OPENBIT SURFACEBIT)
            (ACTION FURNITURE-F)
>

<ROUTINE FURNITURE-F ()
    <COND (<NOT ,PRSI>
        <COND (<OR <VERB? TAKE> <VERB? PULL> <VERB? PUSH>>
            <TELL "The " D ,PRSO " is too heavy for that." CR>)>)>
>

Now that we have defined some templates, we can get on with defining some real rooms and objects.

To be continued...

Saturday, 23 March 2019

Heidi revisited: is the bird in the nest?

The game ends when the player puts the nest onto the branch. This assumes that the bird is inside the nest, something we haven't checked for. Fortunately, it's quite straightforward to add this check.


The new condition should be read as follows.

When the player is in the location of the branch, if the bird is in the nest and the nest is on the branch then end the game with the message "You win!" otherwise do nothing.

Here is a transcript of our completed ZILF game.

Heidi
A simple Inform example by Roger Firth and Sonja Kesserich.
This version written in ZIL by Shin for the ZILF compiler by Jesse McGrew.
Release 1 / Serial number 190323 / ZILF 0.8 lib J4-190105

In front of a cottage
You stand outside a cottage. The forest stretches east.

> VERBOSE
Verbose descriptions.

In front of a cottage
You stand outside a cottage. The forest stretches east.

> GO EAST
Deep in the forest
Through the dense foliage, you glimpse a building to the west. A track heads to the northeast.

There is a baby bird here.

> EXAMINE THE BIRD
Too young to fly, the nestling tweets helplessly.

> TAKE BIRD
You pick up the baby bird.

> NE
A forest clearing
A tall sycamore stands in the middle of this clearing. The path winds southwest through the trees.

There is a bird's nest here.

> PUT BIRD IN NEST
You put the baby bird in the bird's nest.

> EXAMINE THE NEST
The nest is carefully woven of twigs and moss.
In the bird's nest is a baby bird.

> TAKE NEST
You pick up the bird's nest.

> UP
At the top of the tree
You cling precariously to the trunk.

There is a wide firm bough here.

> PUT NEST ON BRANCH
You put the bird's nest on the wide firm bough.

You win!

    ****  The game is over  ****

Would you like to RESTART, RESTORE or QUIT? > QUIT


There are still some minor differences in presentation between this game and the original but I'll ignore them for now.

Thursday, 21 March 2019

Heidi revisited: dropping objects from the tree

At the top of the tree, the player might type DROP object instead of PUT object ON BRANCH. If this happens, whatever is dropped should fall to the clearing below.

This can be handled by an action routine on the room. However, in this example, we want to intercept DROP after it happens rather than before. This is done by checking for <=? .RARG ,M-END> instead of <=? .RARG ,M-BEG>.


Our ZILF game now behaves like this:

At the top of the tree
You cling precariously to the trunk.

There is a wide firm bough here.

> DROP NEST
You drop the bird's nest.

> LOOK
At the top of the tree
You cling precariously to the trunk.

There is a wide firm bough here.

> DOWN
A forest clearing

There is a bird's nest here.

>


We can improve on the standard message for DROP by telling the player that the object has dropped to the clearing but this will require that we intercept DROP before instead of after it happens.


Our ZILF game now behaves like the original:

At the top of the tree
You cling precariously to the trunk.

There is a wide firm bough here.

> DROP NEST
Dropped... to the ground far below.

> LOOK
At the top of the tree
You cling precariously to the trunk.

There is a wide firm bough here.

> DOWN
A forest clearing

There is a bird's nest here.

>


To be continued...

Wednesday, 20 March 2019

Heidi revisited: climbing improved

Fortunately, we can avoid editing verbs.zil altogether, while still replicating the behaviour of the original game, by creating an action routine on the room. This action routine passes control to the tree's action routine if the verb CLIMB is used by itself.


Our ZILF game now behaves like this:

A forest clearing
A tall sycamore stands in the middle of this clearing. The path winds southwest through the trees.

There is a bird's nest here.

> get nest
You pick up the bird's nest.

> climb
[the tall sycamore tree]
At the top of the tree
You cling precariously to the trunk.

There is a wide firm bough here.

>


as originally intended.

Monday, 18 March 2019

Heidi revisited: the climb problem

In the previous post, we found that the ZILF library has a syntax definition for the verb CLIMB used by itself while the Inform library does not. Since there is no way of cancelling that syntax definition, it seems the only way forward is to remove it from the source code. This requires either editing verbs.zil (not recommended) or copying verbs.zil to the main project directory and editing the copy.


Since this technique amounts to a gross hack, I'll only be using it when absolutely necessary.

Our ZILF game now behaves like this:

A forest clearing
A tall sycamore stands in the middle of this clearing. The path winds southwest through the trees.

There is a bird's nest here.

> get nest
You pick up the bird's nest.

> climb
What do you want to climb?

>


which is still not quite right. To replicate the behaviour of the original game more closely, we must add a syntax token to the remaining definition of CLIMB.


Our ZILF game now behaves as intended:

A forest clearing
A tall sycamore stands in the middle of this clearght changeing. The path winds southwest through the trees.

There is a bird's nest here.

> get nest
You pick up the bird's nest.

> climb
[the tall sycamore tree]
At the top of the tree
You cling precariously to the trunk.

There is a wide firm bough here.

>


It would be preferable to avoid editing verbs.zil altogether...

Thursday, 14 March 2019

Heidi revisited: climbing the tree

In the clearing, the player might type CLIMB TREE instead of UP. As with entering the house, we can handle this by creating an action routine on the object.


However, the original game has the following behaviour:

A forest clearing
A tall sycamore stands in the middle of this clearing. The path winds southwest through the trees.

You can see a bird's nest (which is empty) here.

>get nest
Taken.

>climb
(the tall sycamore tree)

At the top of the tree
You cling precariously to the trunk.

You can see a wide firm bough here.

>


but our ZILF game behaves like this:

A forest clearing
A tall sycamore stands in the middle of this clearing. The path winds southwest through the trees.

There is a bird's nest here.

> get nest
You pick up the bird's nest.

> climb
You must be joking.

>


This is because the ZILF library has a syntax definition for the verb CLIMB used by itself but the Inform library does not.

OK, now it gets messy...

Wednesday, 6 March 2019

Heidi revisited: entering the cottage

At the start of the game, standing "outside a cottage" might lead the player to try going inside:

In front of a cottage
You stand outside a cottage. The forest stretches east.

> in
You can't go that way.

>


This default response doesn't help to maintain the atmosphere of the game but is easy to change:

<ROOM BEFORE-COTTAGE (IN ROOMS)(DESC "In front of a cottage")
    (LDESC "You stand outside a cottage. The forest stretches east.")
    (EAST TO FOREST)
    (IN SORRY "It's such a lovely day -- much too nice to go inside.")
    (FLAGS LIGHTBIT)
>

Other unspecified directions like north and up still produce the standard response but we can change that too by using an action routine:


We then get this friendlier behaviour:

In front of a cottage
You stand outside a cottage. The forest stretches east.

> IN
It's such a lovely day -- much too nice to go inside.

> NORTH
The only path lies to the east.

> EAST
Deep in the forest

...

The next issue is that, since there is no object to represent it, examining the cottage produces this reply:

In front of a cottage
You stand outside a cottage. The forest stretches east.

> EXAMINE COTTAGE
I don't know the word "cottage".

>


This can be fixed by adding a cottage object and making it scenery:

<OBJECT COTTAGE (LOC BEFORE-COTTAGE)(DESC "tiny cottage")
    (TEXT "It's small and simple, but you're very happy here.")
    (SYNONYM COTTAGE HOME HOUSE HUT)(ADJECTIVE TINY)
    (FLAGS NDESCBIT)
>

This solves the problem but gives rise to another:

In front of a cottage
You stand outside a cottage. The forest stretches east.

> ENTER COTTAGE
That's not something you can get inside.

>


As with listening to the bird, this flaw is corrected by creating an appropriate action routine and associating it with the object:


Finally, the original game has the following behaviour:

In front of a cottage
You stand outside a cottage. The forest stretches east.

>ENTER
It's such a lovely day -- much too nice to go inside.

>

but our ZILF game behaves like this:

In front of a cottage
You stand outside a cottage. The forest stretches east.

> ENTER
What do you want to enter?

>


This situation is corrected by creating another library extension:


and then including it in our game:


Our ZILF game now behaves like the original.

In front of a cottage
You stand outside a cottage. The forest stretches east.

> ENTER
It's such a lovely day -- much too nice to go inside.

>


To be continued...

Saturday, 2 March 2019

Heidi revisited: listening to the bird

In even the simplest game, it's possible for the player to try unexpected things. Basic game design is relatively easy. What takes the time and makes a game large and complex is taking care of all the other things that the player may think of trying. In the current exercise, we also have the issue of game library differences.

Here's a fragment of the original Inform 6 game being played:

Deep in the forest
Through the dense foliage, you glimpse a building to the west. A track heads

to the northeast.

You can see a baby bird here.

>EXAMINE THE BIRD
Too young to fly, the nestling tweets helplessly.

>LISTEN TO BIRD
You hear nothing unexpected.

>


Here's the same fragment of our ZILF game.

Deep in the forest
Through the dense foliage, you glimpse a building to the west. A track heads

to the northeast.

There is a baby bird here.

> EXAMINE THE BIRD
Too young to fly, the nestling tweets helplessly.

> LISTEN TO BIRD
I don't know the word "listen".

>


Our first problem is that he ZILF library doesn't define the verb "listen" or any associated syntax. This situation is corrected by first creating a library extension:


and then including it in our game.


Our ZILF game now behaves like the original.

Deep in the forest
Through the dense foliage, you glimpse a building to the west. A track heads

to the northeast.

There is a baby bird here.

> EXAMINE THE BIRD
Too young to fly, the nestling tweets helplessly.

> LISTEN TO BIRD
You hear nothing unexpected.

>


The obvious game design problem is that, although the description of the bird mentions it's tweeting, listening provides no more information. The flaw is corrected by creating an appropriate action routine and associating it with the bird object.


Here is the final behaviour.

Deep in the forest
Through the dense foliage, you glimpse a building to the west. A track heads
to the northeast.

There is a baby bird here.

> EXAMINE THE BIRD
Too young to fly, the nestling tweets helplessly.

> LISTEN TO BIRD
It sounds scared and in need of assistance.

>

To be continued...

Monday, 25 February 2019

Reviewing the basics

Now for a review of the language features used so far.

Constants


A constant is a name to which a value is given once and once only. Any attempt to change the value will be prevented by the ZILF compiler.

So far, we’ve seen a constant being set up with its value as a string of characters:

<CONSTANT GAME-TITLE "Heidi">

and as a number:

<CONSTANT RELEASEID 1>

Those two examples represent the most common ways in which constants are used in ZIL.

Variables


A variable is a name to which a value is given, but that value can be changed to a different one at any time.

We haven’t set up any variables of our own yet, though we’ve used one which the library created:

<GLOBAL HERE <>>

The value of a global variable can be changed at any time. For example, we used the statement:

    <SETG HERE BEFORE-COTTAGE>

to reset the value of the HERE variable to the BEFORE-COTTAGE room.

Later, we’ll talk about local variables and about using object properties as variables.

Rooms


A general model of our room definitions consists of a header, a set of properties and a set of attributes.

<ROOM room-id (IN ROOMS)(DESC "room-name")
    (property value)
    (property value)
    ...
    (property value)
    (FLAGS attribute attribute ... attribute)>

Header

The header contains the room's identifier, room-id, which is referred to within the program and the room's name, "room-name", which will be printed out every time the player enters the room.

Properties

Two properties have been used in our rooms so far: room description and room exit. The general form of a room description is (LDESC "room-description") where "room-description" is a character string which describes the room. This is printed out when the player enters the room. The general form of a room exit is (exit-direction TO room-id) where exit-direction can be any one of  NORTH, SOUTH, EAST, WEST, NE, NW, SE, SW, IN, OUT, UP or DOWN. A room can have several of these. The player is constrained to travel in one of the stated exit directions only. Travel in the stated direction results in the player entering the associated room.

Attributes

Only one attribute has been used in rooms so far: lighted, which represents the flag LIGHTBIT. A room which doesn't have this attribute is in darkness. When the player enters a dark room, instead of the room description (and descriptions of contained objects) the text "It is pitch black. You can't see a thing." is printed out.

Objects


As with rooms, a general model of our object definitions consists of a header, a set of properties and a set of attributes.

<OBJECT object-id (LOC room-id)(DESC "object-name")
    (property value)
    (property value)
    ...
    (property value)
    (FLAGS attribute attribute ... attribute)>

Header

As with rooms, the header contains the object's identifier and name. Object headers also contain the objects location. The general form of this is (LOC room-id) where room-id is the identifier of the containing room.

Properties

Two properties have been used in our objects so far: object detailed description and object vocabulary. The general form of an object detailed description is (TEXT "object-detailed-description") where "object-detailed-description" is a character string which provides a detailed description of the object. This is printed out every time the player examines the object. An object vocabulary consists of a noun list and, optionally, an adjective list. The general form of a noun list is (SYNONYM noun noun ... noun). Each noun is associated with the object by the parser. The general form of an adjective list is (ADJECTIVE adj adj ... adj) where each adj is an adjective to be associated with the object by the parser.

Attributes

Five attributes have been used in objects so far: takeable, scenery, container, open and supporter. The takeable attribute represents the flag TAKEBIT. A takeable object may be taken by the player. The scenery attribute represents the flag NDESCBIT. A scenery object is not separately listed after the description of it's containing room. Scenery objects should not be made takeable. The container attribute represents the flag CONTBIT. A container object may contain other objects. The open attribute represents the flag OPENBIT. An open container object may have other objects put in it. The supporter attribute represents the flags CONTBIT, OPENBIT and SURFACEBIT used together. A supporter object may have other objects put on it.

Routines


A routine is a named set of instructions to be executed in order when the game is played. So far, our game has very few routine definitions. Each routine definition consists of a header and a set of calls which may consist of a combination of ZIL instructions and routine calls.

<ROUTINE routine-name (argument-list)
    <call>
    <call>
    ...
    <call>>

GO

Each game needs a GO routine since this provides the program entry point and the ZILF compiler will reject the program if GO doesn't exist. Here, GO has been defined in a generic manner by separating out game-specific initialisation into a routine called INIT.

;"============================================================================="
;" Generic Initialisation"

<ROUTINE GO ()
    <CRLF> <CRLF> <INIT> <V-VERSION>
    <MOVE PLAYER ,HERE>
    <CRLF> <V-LOOK> <MAIN-LOOP>
>

;"============================================================================="
;" Game Specific Initialisation"

<ROUTINE INIT ()
    <SETG HERE BEFORE-COTTAGE>
    <PUTP PLAYER ,P?CAPACITY 5>
    <QUEUE I-FINISH-IF-GAME-WON -1>
>

More about routines later...

Thursday, 21 February 2019

Heidi: the capacity problem

The game as it stands doesn't work. Even if the bird is put in the nest, the nest can't then be picked up as a single object.

Why?


Jesse McGrew explained it like this.

Inform measures capacity non-recursively. If you can only carry 10 things, you might get around it by picking up a backpack that holds 10 more things. Then you could put another backpack inside that one to carry even more, and so on.

ZILF (by default) measures it recursively - you can only carry a certain total weight, no matter how it's distributed. The backpack is just another thing you have to carry.

Neither system is especially realistic, but Inform's is probably more fun for the player (largely because it's more lenient).


What can I do about it?


The definition of TAKE-CAPACITY-CHECK in verbs.zil needs to be changed. The recommended way to do this is with REPLACE-DEFINITION.


The current source code (which now works as intended) can be downloaded from GitHub.

Extending the ZILF library


The above change is potentially the first of many required to make this game, and others, behave as if written in Inform 6. The changes will be developed separately (as the Inform Style library extension) from now on and included using INSERT-FILE.

Wednesday, 20 February 2019

Heidi: my first ZILF game

As described in the Inform Beginner's Guide, this game can be summarised as follows...

"Heidi lives in a tiny cottage deep in the forest. One sunny day, standing before the cottage, she hears the frenzied tweeting of a baby bird; its nest has fallen from the tall tree in the clearing! Heidi puts the bird into the nest, and then climbs the tree to place the nest back on its branch."
 

The Map


A good starting point is to think about the locations which are involved.


Defining the rooms


Here's a first attempt at defining the rooms in the map.


Joining up the rooms


The available routes between the rooms need to be added.


Adding the bird and the nest


The takeable objects need to be added.


Adding the tree and the branch


The fixed objects need to be added.


Finishing touches


There are two more changes to add before this first pass at the game is done.

First, Heidi wouldn't be able to climb the tree carrying the bird and the nest separately. We want the player character to put the bird into the nest first. One easy way to enforce this might be to add the following to the init routine.

    <PUTP PLAYER ,P?CAPACITY 5>

This states that the player can carry one normal sized object.

Second, there's currently no way to win the game. The goal is for the player character to put the bird in the nest, take the nest to the top of the tree and place it on the branch. When that happens, the game should be over. This can be done with an interrupt routine.

<ROUTINE I-FINISH-IF-GAME-WON ()
    <COND
        (<AND <=? <LOC BRANCH> ,HERE> <IN? NEST BRANCH>>
            <CRLF> <JIGS-UP "You win!">)>
>

This then needs to be queued for execution at the end of every turn by adding the following to the init routine.

    <QUEUE I-FINISH-IF-GAME-WON -1>

The init routine is now as follows.

<ROUTINE INIT ()
    <SETG HERE BEFORE-COTTAGE>
    <PUTP PLAYER ,P?CAPACITY 5>
    <QUEUE I-FINISH-IF-GAME-WON -1>
>

The current source code can be downloaded from GitHub.

To be continued...

Saturday, 16 February 2019

Writing Games in ZIL

To cover a good number of language features quickly, without spending time on writing new games from scratch, I've decided to recreate the examples from the Inform Beginner's Guide in ZIL.

The first task is to create a source file template. This will be the starting point for each game.


After creating the file, test it by starting a debug session. If there are no errors, the result will be like this.


Everything is now ready for writing my first ZILF game.

Thursday, 14 February 2019

Updating the ZILF Library

Since the last release in 2017, there have been changes to the ZILF library which would be useful to include in current game projects. The latest state of the ZILF library can be downloaded at any time by visiting the ZILF Downloads page and clicking download repository.

After extracting the contents of the downloaded zip file, the zil sources contained in the new "Library" folder can be copied to the "library" folder of the existing ZILF installation, replacing the existing zil sources where necessary.

To identify the changed library version, the library global ZILLIB-VERSION should be changed from "J4" to a string which indicates the latest online modification date of the zil sources.


In my installation, that string is "J4-190105", based on the last commit date of parser.zil.

Configuring the IDE on Linux Mint

Type in the full path to zapf.exe and zilf.exe as before.


Navigate to the advent folder in your copy of the samples folder. Then click on advent.zil.


Select the debugger, edit and save launch.json as before. Then click the go icon as before.


The debugger doesn't have it's executable property set! Try setting it.


Then try debugging again...


Unfortunately, mono has a problem loading the debugger. Debug sessions will not work under Linux at this time. Hopefully, Jesse will be able to fix this at some point. In the meantime, the IDE can still be used for editing and building projects. Play testing can be done using frotz.

Wednesday, 13 February 2019

Installing ZILF on Linux Mint

The Toolset


First, make sure that mono is installed using the software manager.


Then, download and extract ZILF as previously described. Here are the contents of my installation directory.


Then, make sure that the .exe files in the bin directory are executable.


Put the full path to the bin directory in PATH as before but this time, make a copy of the sample directory so you have write access. Then enter the compilation command as before making sure to append .exe to the executables.


You now have a working installation of the ZILF toolset on Linux Mint.

The IDE


Download and install the Visual Studio Code package for Debian based distributions. I did this using the GDebi Package Installer. The error message is due to my installation having been updated by the Update Manager.


Install the ZIL extension as before.

To be continued...

Tuesday, 12 February 2019

Configuring the IDE

Click the gear icon in the bottom left and select settings from the popup menu. Now select User Settings - Extensions - ZIL . Type in the full path to zapf.exe and zilf.exe.


Select explorer (the top icon on the left toolbar) click the blue open folder button and navigate to the advent folder in the samples folder of your ZILF Toolset installation. Then click on advent.zil.


Select debugger and click the gear icon (below View on the menu bar) to open the launch configuration options. Set the console type to integratedTerminal if you don't want your game to start in an external terminal.


Save launch.json (control-s) close the launch.json tab and click the go icon in the top left next to the word DEBUG.


You now have a working ZILF IDE.

Due to the popularity of Linux on the ZIL Facebook group, I'll cover my efforts to get this working on Linux Mint 19 next.

To be continued...