After almost a year of development, my game is finally released, and I thought it would be interesting to show how I’ve fiddled with Inform 7 to achieve an ASCII-style interface, a dialog system and gameplay mechanics closer to a point & click game than a parser-based game.
I wanted to do this with minimal use of extensions: only the Basic screen effects and the French extension were used. The rest is pure I7 (I know nothing of Vorple or I6).
The game page is here, with screenshots, and the full source code can be downloaded. Note that the game is in French, as are the code comments, but I wrote the code itself in (sometimes broken) English. There are about fifteen long meta-comments in the code. You can find them by searching for “#EXÉGÈSE”. They’re in French, but easy to run through a translator.
So, here are the interesting technical features:
-
ASCII-style interface and auto-revealing map (see “Volume - Interface” in the code)
Probably the most striking feature for a game programmed in Inform 7, but also the least technically complex. It’s all about screen clearing, fixed fonts and “to say” rules. A simple kind of value is read to determine which type of screen should be displayed at any given moment in the game. The map that reveals itself progressively is also technically rudimentary, and not really dynamic (see “Volume - Carte”). -
A separate inventory screen, with dynamic character portrait
This feature uses the same mechanics as above. The character state is visually displayed through her portrait: the drawing changes according to the clothes or objects worn. From this screen, it’s possible to perform actions on the items you’re holding: open, close, combine and so on. -
A main menu, a “quest log” and various interlude screens
I’ve integrated a main menu that displays some basic options: save, help, quit, etc. In the same screen, a quest journal reads the status of the game and displays the current mission, with many variations. This is where clues are given to the player in an organic way. Similarly, a number of other intermediate screens are used for narration or detailed examination of objects, with or without ASCII drawings. -
Text display in frames (see “Book - Affichage textuel adaptatif”)
Since the interface is made up of text frames, texts need to make automatic line breaks when they reach the end of the available space. It doesn’t look like much, but I pulled my hair out to get it right. I use regular expressions to divide text line by line, to the desired length. Unfortunately, processing a long text in this way produces a noticeable lag: that’s why the vast majority of texts in the game are pre-cut to the appropriate length. -
A list of available commands in place of a parser (see “Book - Trame fondamentale”)
As you can see on the screenshots, not just any command can be run: only numbers or letters that match the commands displayed on the screen. This involves completely blocking the normal flow of a turn: each command is processed in an “after reading a command” rule, produces a result, then becomes rejected with “reject the player’s command”. The “input standby” kind of value determines what effect a command has, depending on the current in-game context. -
A topic-based dialog system, with portraits and speech bubbles (see “Volume - Dialogues”)
This system could be used in any ordinary interactive fiction, without a graphical interface. Here, it takes advantage of the interface to display the portrait of the two people talking, and their speech bubbles as well. The mechanisms are quite complex, since I’ve included a lot of functionalities: starting a discussion topic with someone, discovering a new topic, exhausting a topic already discussed, managing the list of topics available with a given person, and so on. The dialogues themselves are written in tables, separated by line and by reply, with several columns that trigger different effects: change of speaker, end of dialog, actual in-game effects, etc. -
Dynamic non-playable characters (see “Book - Vie des personnages”)
Limiting the number of possible actions and isolating the dialog system in a separate screen makes it easier to integrate a variety of characters, compared to ordinary IFs. In this game, there are several characters to talk to, who move through the rooms (each move is sequenced in three turns), who sometimes actively seek out the player character, and who engage in different occupations depending on their role and the time of day. All this is handled automatically, but different rules allow you to force someone to move to a specific location, or to force a change in their occupation.
I think I’ve covered the most relevant features. If you find it interesting, I’ll be happy to answer any questions you may have. Don’t insult me if you notice (rightly) that some things are poorly optimized, or that I have some serious shortcomings in I7 / programming in general 
Creating this game took a lot of work (more than 38k lines of code!), and I feel I’ve been a bit disrespectful of I7, but I’m very satisfied to have reached the end.
