Challenges in updating ZMPP’s screen model

So now ZMPP has a dramatically simplified setup and execution model, those changes were actually much quicker to do than I thought and each took about a day. On the other hand I did not really make changes to the core, but simply wrapped it in a different way so it can be easier reused in different contexts.

The real challenge is the rework of the screen model - in fact there are three:

1. “classic” screen model (V1-3)
2. “modern” screen model (V4-8 except 6)
3. V6 screen model

1. The “classic” screen model

What I call the “classic” screen model is the screen model used by the majority of Infocom text adventures, such as the Zork trilogy, “Leather Goddesses of Phobos” etc. It is characterized by a main text window with a standardized status bar at the top. This model is very simple to implement with standard GUI components and even transfers well to an HTML interface. Unfortunately, aside from the Infocom adventures, this screen model is not frequently used by modern Interactive Fiction.

2. The “modern” screen model

This is the screen model which is by far the most popular of the current Z-machine screen models. A top window rendered in a fixed pitch font, without scrolling and word wrapping and a bottom window for main text display and input which can have variable pitch font, scrolling and word wrapping. The top window’s number of rows can be specified by the game and the bottom window will shrink accordingly so that the sum of the heights of both window add up to the total height of the window.

The popularity of this particular screen model can be explained by the availability of one of the best authoring systems for Interactive Fiction: Inform. Inform’s output formats are usually V5 or V8 (or Glulx, which is a different virtual machine for Interactive Fiction with larger available memory).

This screen model does not translate itself easily to standard user interface components or web interfaces, which is mainly due to the fact that a few games use the behavior of the screen model that the content of the windows are not erased after the top window was resized. So, in “Curses” by Graham Nelson, the top window is used to render a book citation in box (because of the fixed pitch font) and shrinks so that the former content of the top window now belongs to the bottom window (and will be cleared away). This behavior is difficult to implement with standard UI components or in a web interface, because rendering into other component’s regions is usually not desired. 

3. V6 screen model

This is the most complicated screen model and neither widely used by Interactive Fiction authors nor commonly implemented by many Z-machine interpreters. It uses 8 windows which can contain graphics or text and can use an interrupt mechanism to implement word wrapping. ZMPP implements it, but currently has a number of issues due to lack of testing. I will probably describe it in more detail when I get to work on that.

For the near future, reimplementing the classic and modern screen models is the main focus. The requirements I have distilled from user requests and my own ideas are:

• use JTextPane for the main text window if possible
• support selection, cut, copy, paste
• support resizing

Since I do not have enough in-depth experience using the styled text components of Swing in the way described (that’s why I ended up with custom rendering for the current versions - it was quicker to implement), I will create a number of prototypes in the next days to see what is possible.

 

Back to the Z-machine

In the last two years, I have only made smaller fixes and changes to ZMPP. The reasons were various: learning to be a father, tinkering with TinyUML and playing with Z-machine implementations in Ruby and Erlang. While working on the other pet projects, I noticed that ZMPP is still the most successful of them, simply because it is the one with an existing user base besides myself.

ZMPP is ready for a major overhaul. There are several pain points I want to tackle:

• the public interface between the core and the user interface is too complicated and makes implementing different front ends a big pain.
• all currently released ZMPP versions follow a game-loop style scheme, which means that the Z-machine runs in its own thread, until it stops, timed input is realized by threading as well. Besides making the execution and input logic too complicated, there are reportedly deadlocks which are almost definitely a result of this design decision. However so far, ZMPP is probably the Java Z-machine where timed input works best
• top priority and the largest challenge is the rework of the screen model. On Java, ZMPP has the most complete screen model implementation, but it is still far from what I want it to be. I will elaborate on that later.

So, with that said, it means that I am waving good-bye to TinyUML, Smeagol and Schmalz in order to focus on ZMPP entirely. As a single, it is easy to find time to do a lot of different projects, but once you get married and have children, programming in the free time while still important, should not exactly be the top priority.