A-code build types
A-code games can be built in a number of different ways, such as e.g. console only. This document explains all these build types and their uses. For details on actually building games in verious modes, please see a separate page explaining how to build A-code games from derived ANSI C sources.
The console build
The console build replicates how the original Adventure was initially played. It takes input directly from the player and outputs any responses in plain text to a "computer terminal" – these days most likely a terminal emulator window. Some players still prefer this build typeand it is also very handy for debugging.
While it still defaults to the dimensions of displays of ancient VDUs (24 lines and 80 fixed font characters per line), other dimensions can be specified on the invocation command line by means of the -s option. The kernel also provides the necessary hooks for a game to permit changes to these defaults while playing.
The console build also offers a unique opportunity to experience an A-code game the way the original Adventure was played in 1970s/80s. The -o command line option allows the output speed to be set to the baud rate of 110 (a teletype), 300 (earliest VDUs), 600, 1200, 2400, 4800 and 9600. Younger players are hereby invited to marvel at the patience required to play at the lower speeds (as we did!).
For the full list of console build command line options, please see the document describing command line invocation of A-code games.
The browser/console build
By default, A-code games built in this way do not interact with the player directly, but instead invoke a local browser and use that to render game's output and to obtain player's commands. In this mode, an A-code game acts as a very simple HTTP server. No access to network is involved – there's just local socket-based communication between the game and the browser.
Unless otherwise specified, the player's default browser is invoked, but another browser can be specified either on the invocation command line or by modifying the acode.config file created by the A-code kernel.
The browser build of an A-code game automatically includes the console build (but not the other way around!). Thus a browser-build game can be invoked in the console mode by adding -C to the invocation command line. All console build command line options apply when -C is spcified.
The library build
A simple such wrapper (libtest.c) is provided with kernel sources and should be compiled and linked with derived C-sources and with kernel sources to produce a library build executable.
The QT5 build
The QT5 build uses the library mode of A-code and wraps it in a QT5 GUI front-end.
The single turn build
Originally developed for CGI operation, single turn game builds are only suitable for running in a cloud, via a suitable front-end script, e.g. a cgi-bin or a PHP one. In this mode, the game executable is supplied a single command as a parameter on the invocation command line, sends the text generated in response to standard output and exits. (See the the command line options document for details.)
The actual interaction with the player is carried out by the front-end script, which repeatedly invokes the executable for successive game turns. The secret sauce is, of course, the player-invisible save and restore of the current state of the game. This mechanism got later adapted for use by other game modes, automatically giving all A-code games a persistent state.
In this build all text output is HTML-formatted by default, though this can be overridden if necessary, by adding -C to the invocation command line. All output text is also prefixed by a single character, which provides information to the wrapper script and is not expected to be displayed to the player.