It is common for interactive fiction to use parser-based interfaces, where users enter commands as free text, with discrete movement and actions. This can both limit the spatial possibilities of a game's world and be an intimidating interface for new players. Thus, we are developing Isofict, a system for interactive fiction that allows the player to move continuously through an updating textual world using a WASD- and mouse-based interface. We present our current progress implementing Isofict as a web-based Inform 7 extension and describe our experience porting two simple games. In the future we hope to compare to more standard parser-based systems.
Interactive fiction (IF) is an umbrella term for interactive
experiences expressed primarily through the use of text,
as opposed to graphics. There are many forms of
interactive fiction, but parser-based IF, which has an underlying
world model afected by typed commands, is the focus of
this work [
Additionally, parser-based IF is based on a “command line”
interface (CLI) where players must figure out what to type,
in the way the parser understands, with minimal guidance.
While experienced players may be familiar with standard
verbs and synonyms used, such an interface can have a high
learning curve [
Some works have explored ways to represent a discrete
world so that it feels more continuous. Seltani [
To attempt to expand the spatial possibilities of IF without
requiring full 3D rendering, we are developing an authoring
system for continuous interactive fiction , where the
underlying world model is represented on a 2D coordinate plane
with simple polygons. We are adapting Inform 7 to take
advantage of its popularity and detailed underlying world
model. We have developed the Isofict Inform 7 extension
and JavaScript library. The name was chosen for the term
“isovist”, which describes the visible region from a point in
space [
The Isofict system uses an underlying 2D spatial model,
which allows the player to move continuously throughout
the world (currently using WASD to walk and turn). As the
player moves, the description of the world is continually
updated, based on where the player is looking and what
they can see (similarly to Seltani [
Isofict is composed of an Inform 7 extension paired with a JavaScript (JS) library. To integrate Inform 7 and JS, we use Vorple [15], an Inform 7 interpreter that provides a translation layer API between Inform 7 and JS. Vorple also provides
HTML for rendering the game text and does not permit accessing the game text directly. To change the display of the game, it is necessary to interact with the rendered HTML rather than with Vorple directly. The Isofict library and extension are designed to work well with a primarily mouseand WASD-based interface, and we have created one such JS front-end.
To update an Inform 7 game to use Isofict , the game author must provide a JS file containing a JSON object that defines the starting coordinates, polygon shapes, and heights of game objects. It must also have the starting coordinates of the player (“POV”) and the directions they can look in. In addition, the Inform 7 code must be annotated with Isofict keywords (see code with the case study Cloak of Darkness).
The JS library for Isofict provides functions for calculating the visibility of 2D polygons plus height. Visibility is calculated using the 2D raycasting algorithm described and implemented in Haxe 3 by Red Blob Games [16]. We have modified the code of the GitHub repository “2d-visibility” by David Neilsen [17], which is a TypeScript fork of “2dvisibility” by Cyril Silverman [18], itself a JS port of the original Haxe 3. Our main changes are to support custom view ranges (rather than 360° vision), and to add the 3D visibility heuristic that objects may be occluded by anything of equal height or taller. We chose to modify a 2D algorithm over using true 3D visibility for simplicity of implementation. The POV is a 2D point in space (without height), with an angle of orientation and configurable fields of vision relative to the orientation. For example, the “forward” ifeld of vision may be a 90° wedge centered on the angle of orientation. Objects that are visible in multiple directions are only marked visible in the direction that includes the greatest percentage of their edges. Each time the POV or orientation changes, the visibility is recalculated.
The Isofict extension provides helper functions that interface with the JS. In addition, the extension overrides the Inform 7 default world model to use the JS coordinate model instead. Inform 7 authors can use the functions provided by the Isofict extension rather than invoking JavaScript commands directly.
The Inform 7 extension is designed to work with a mouse. For example, descriptions of game objects include clickable links to commands like “EXAMINE” and “TAKE”.
We have implemented a simple JS front-end for Isofict using the Svelte framework [19]. The front-end hides Vorple’s mandatory text input box, requiring interaction through WASD and mouse only. Hyperlinks are natively supported by Vorple, and WASD is enabled by passing Isofict commands to Inform 7 via Vorple.
To further refine Isofict and evaluate its usability, we have modified two existing Inform 7 documentation games. Both games use viewing angles for “forward”, “left”, and “right” that each take up 90°.
As a proof-of-concept for Isofict , we re-implemented the
Inform 7 documentation example game Stately Gardens [
In Stately Gardens, the player is free to explore an outdoor garden divided into multiple Inform 7 “rooms”. A system of custom Inform 7 rules makes large objects viewable from outside the room they are in. The player can walk around and look at things, but there is no objective or win condition.
We have rewritten Stately Gardens from the ground up to use Isofict . Using Isofict , we were able to exclude the special code for viewing objects outside of the current room. For simplicity, we omitted the few inventory objects. In the resulting game, the player can move around the Stately Gardens map, and visibility information is provided by Isofict ’s JavaScript calculation instead of a system of Inform 7 rules around sizes and distances. See Figure 1 for the beginning of the game.
For our second case study, we wanted to evaluate how many changes are needed to existing Inform 7 code to make it compatible with Isofict . The game we chose to adapt is Cloak of Darkness [20] (CoD), which is historically a game that has been implemented in most new IF programming languages and tools as the IF “Hello World” [21].
In CoD, the player is able to walk around an opera house consisting of three rooms. The “Bar” is initially dark, and if the player stays too long in it, they damage a message on the floor. When the black cloak the player is wearing is left in the “Cloakroom”, the Bar becomes lit, and the player can see the message. The game is won if the message is not damaged.
To adapt CoD, we again used the version from the Inform 7 documentation [22], but in this case rather than rewriting the game from the ground up, we modified the existing code as little as possible. We found that very little game-specific modification was required, and the result is a fully playable implementation of CoD using a coordinate system. While modifying CoD, we further refined Isofict , as CoD makes use of some Inform 7 default features that were not previously implemented (namely, visibility in dark rooms and the use of portable objects). We took advantage of the new world model by changing the logic of the message in the Bar such that the player must actually walk over it (using WASD) to damage it. See Figure 2 for the key moments in a losing game.
The following code illustrates typical code changes required to port CoD to Isofict . Code removals are tagged with ‘-’, and additions are tagged with ‘+’. Unchanged code is
We are encouraged by the relatively little game-specific code
required to port an existing game to Isofict . After defining
game objects in the JavaScript coordinate system, an author
mainly only needs to do basic tagging of their Inform 7
code to allow it to use the extension. In the future, we will
remove the requirement to define game objects in JavaScript
by providing Inform 7 commands to create objects in the
coordinate system. In addition, we intend to refine Isofict
parser commands to facilitate including the option to toggle
between mouse-based input and command line input to
support users’ preferences or accessibility needs [
The current version of Isofict does not yet support all features of Inform 7. We are continuing to improve the handling of portable items, as well as support for supporters, containers, and objects that form a part of other objects.
There are also some particularly notable limitations to the coordinate system. Most obviously, it doesn’t support true 3D visibility, which is the most disruptive in situations involving small objects. For instance, if multiple small objects of the same height are in a row along the player’s orientation angle, only the front-most will be visible, even when the game author might expect the player to be able to see all of them. Similarly, there is not currently a good way to represent objects on top of other objects or objects that “float”, such as tabletops. Objects with a height occlude the entire area under them. To handle these cases, Isofict ’s visibility system could be improved with more sophisticated height handling heuristics, or it could transition to true 3D raycasting for simple 3D objects.
Another limitation of Isofict is the field of view system, where objects are only marked visible in one direction. In practice, this can cause confusion when objects are placed into non-intuitive directions. For example, when facing an object that is very close, its front view contains a much smaller part of the visible object than is visible in the periphery. Though a player would expect it to be placed in the “forward” view, it is instead added to the “right” or “left”. To handle this, Isofict could incorporate information on how close objects are when making visibility calculations.
Development of Isofict has often been hindered by the need to override the default behaviours of Inform 7 and the Vorple interpreter. Inform 7’s rules for when objects are and are not available (“scoping” and “reachability” rules) are not easily surfaced or replaced. Vorple, on the other hand, directly updates HTML, making it challenging to replace the front-end.
Although we initially intended to make the player interface text-only, during development we found that it could be dificult to play the game without the 2D map. However, we would like to improve Isofict such that the text description of the world would be enough for the player to navigate.
We would like to investigate the efect of Isofict on the player experience. We hope that players will find the changed visibility system more immersive without being frustrating. We would also like to explore the impact of including the 2D overhead map, or not, on the player experience.
We also intend to investigate Isofict ’s efect on game authoring. We hope to see entirely new spatial mechanics that form the basis of games with fine-grained coordinate models, but we also hypothesize that for most games, it does not make sense to create a coordinate model for every object. We look forward to seeing Isofict used in a hybrid manner to create spatial sections of games or to address movement or visibility needs in a coarse-grained fashion. For example, most objects could be part of discrete rooms as usual, while the visibility of landmarks could be addressed via the visibility system.
Some interactive fiction is designed to represent an underlying 3D world; however, existing tools like Inform 7 support a more discrete than continuous spatial representation. To enable more realistic visibility where there are wide open spaces or objects that can be interacted with from other rooms, game authors must write ad-hoc rules to handle their use cases.
To address the desire for more continuous spaces and realistic visibility in parser-based IF, we have developed an Inform 7 extension and JavaScript library, Isofict , that provides a coordinate-based world model and visibility system that allows Inform 7 games to request the visibility of objects in the coordinate system based on the location and orientation of the player. After using Isofict to modify two existing Inform 7 example games as case studies, we find that little game-specific code is needed.
We plan to conduct a user study to get feedback on the experience of playing an Inform 7 game that uses Isofict . In addition, we intend to refine the Isofict extension to even more easily integrate into existing Inform 7 games. We also plan to improve the visibility heuristics and 3D processing. To showcase the capabilities of Isofict , in addition to the case studies described here, we will release an original game using it. We will then release Isofict as a public extension and solicit feedback from game authors on how well it serves their needs.
We would like to thank Chris Martens for their contribution to the ideation of the design of this system. analysis of architectural space, Environment and Planning B: Planning and design 28 (2001) 103–121. [15] J. Leinonen, Vorple, https://vorple-if .com, 2012. Accessed: 2024-08-30. [16] R. B. Games, 2d visibility, https:// www.redblobgames.com/articles/visibility/, 2020.
Accessed: 2024-08-30. [17] D. Neilsen, Petah/2d-visibility, https://github.com/
Petah/2d-visibility, 2019. Accessed: 2024-08-30. [18] C. Silverman, Silverwolf90/2d-visibility, https://github.com/Silverwolf90/2d-visibility, 2016. Accessed: 2024-08-30. [19] R. Harris, Svelte, https://svelte.dev/, 2016. Accessed: 2024-08-30. [20] R. Firth, The “Cloak of Darkness” specification, https://web.archive.org/web/20190916101552/http: //www.firthworks .com/roger/cloak/, 2002. Accessed: 2024-08-30. [21] IFWiki, Cloak of Darkness, https://www.ifwiki.org/
Cloak_of _Darkness, 2022. Accessed: 2024-08-30. [22] G. Nelson, Cloak of Darkness, Game [Inform 7], 2022.
URL: https://github.com/ganelson/inform-website/ blob/main/docs/book/WI_17_2.html, accessed: 202408-30.