In the collossal cave the user is given a description of a situation he/she's
in, and the user may take several actions, given the actual situation. The
classic adventure game, when started, shows this:
WELCOME TO ADVENTURE!! WOULD YOU LIKE INSTRUCTIONS?
>
If you answer 'yes', you receive the following information:
SOMEWHERE NEARBY IS COLOSSAL CAVE, WHERE OTHERS HAVE FOUND FORTUNES IN
TREASURE AND GOLD, THOUGH IT IS RUMORED THAT SOME WHO ENTER ARE NEVER
SEEN AGAIN. MAGIC IS SAID TO WORK IN THE CAVE. I WILL BE YOUR EYES
AND HANDS. DIRECT ME WITH COMMANDS OF 1 OR 2 WORDS. I SHOULD WARN
YOU THAT I LOOK AT ONLY THE FIRST FIVE LETTERS OF EACH WORD, SO YOU'LL
HAVE TO ENTER "NORTHEAST" AS "NE" TO DISTINGUISH IT FROM "NORTH".
(SHOULD YOU GET STUCK, TYPE "HELP" FOR SOME GENERAL HINTVALS. FOR INFOR-
MATION ON HOW TO END YOUR ADVENTURE, ETC., TYPE "INFO".)
- - -
THIS PROGRAM WAS ORIGINALLY DEVELOPED BY WILLIE CROWTHER. MOST OF THE
FEATURES OF THE CURRENT PROGRAM WERE ADDED BY DON WOODS (DON @ SU-AI).
CONTACT DON IF YOU HAVE ANY QUESTIONS, COMMENTS, ETC.
YOU ARE STANDING AT THE END OF A ROAD BEFORE A SMALL BRICK BUILDING.
AROUND YOU IS A FOREST. A SMALL STREAM FLOWS OUT OF THE BUILDING AND
DOWN A GULLY.
The Red-Thread Project is likely to continue throughout the course, eventually resulting in a multi-user multi-developer Internet game, where the users may not only play, but also contribute to the game. Contributions are rewarded with game-points. When playing the game you also gain (or lose...) points.
In addition to the users, the game contains daemons: trolls trying to make life hard on you, a pirate trying to steal your valuables, and probably some more.
Your virtual self may die during the game. That means that you lose all your accumulated wealth (= objects you own, accumulated points) and must start all over again as a new user.
While playing the game you may want to stop playing the game at some point. In that case you have to leave all the objects you might be carrying at the location you're currently in, and you will leave the game, keeping your accumulated points. The next time you enter the game you'll be back in the location where you left the game, and hopefully you'll be able to retrieve your objects. After all, it's a multi-user game, and another user might have visited `your' location while you were away, grabbing the items you previously owned.
When playing the game, you should provide a command at least once every 10 minutes, or you will be auto logged out. When you're leaving the game (either because you explicitly indicate so, or because you're auto logged out) you will automatically leave all object's you're currently carrying in the state you're currently in. The next time you're logging in again you will be back in the state you were in when you last left the game. Your objects may or may not be there anymore: other users may have found your objects and may have picked them up.
There is at least one (early) state where you will be told that there are lockers. After opening your locker you may either retrieve what's inside, or you may put objects you're carrying into the locker. The latter action will earn you bonus points if a value is associated with the object your putting inside the locker. Once you've put an object into the locker it cannot be retrieved anymore, but it will reappear at a random location somewhere inside the maze, for you or for another user to be picked up. Such objects can then once again be put inside lockers to further boost your credit balance.
A basic environment is available from the very beginning, but hopefully the virtual maze-world is extended over time: it's up to the players to add their own virtual realities, and connect their extensions to the already existing world. Your imagination is the limit: nothing prevents you from travelling through time and space. Just write your own virtual world and allow players to transit from a current state to yours (and back).
rtForm-process. All rtForm-processes communicate in parallel with a
`monitor' program.
RtForm: handles the interactive web-form used by players to
communicate with the game. This program is described in chapter ??.
Initially the user enters a username and password. Username and password are
associated with a user-ID, which is the user's record index in a file
users, holding all relevant info about the registered users. Also, the
user-ID is used to associate state, object, and global variables with the user
who defined those entities. E.g., if user #4 defines a global variable
myVar then the full name of that variable becomes myVar.4.
Monitor: handles all communication between the system and the
rtform web-clients. See chapter ?? for details. Monitor and
rtform clients communicate via named pipes: an rtform client may only write to
the pipe that's read by the monitor after it could lock that
pipe. Instructions follow a well-defined protocol: once an instruction has
been issued, the rtform client waits for a reply from the monitor. Once it has
received the reply, it releases the lock, allowing another rtform process to
submit an instruction. The monitor, having received an instruction, will
process it. An instruction might result in a state-change. If so, the
description of the new state automatically becomes part of the reply.
Compiler: definitions of states, objects, daemons, users, and global
variables are compiled, resulting in binary files (cf. chapter
??). Definitions (except for user-definitions) may be modified: by
submitting a definition twice the last-defined definition is used, replacing
the previous definition. Users can only redefine entities that were previously
defined by them. (Re)definitions are provided on text-files and are compiled
by the compiler (cf. chapter ??). The compiler will merge new
definitions and existing definitions of entities: separate binary files are
available for users, states, objects, daemons and global variables.
Library: the library is a utility (class) library containing
utilities used by two or more programs. It contains the definitions of the
following classes:
Disassembler: the Disassembler is used to visualize the contents of
binary files;
FileHeader: all binary files start with an index, providing the
locations of the various entities in a particular binary file. This
index and accessing the information associated with particular
entities, is FileHeader's responsibility;
global: defines the structure and facilities of Global
variables. Global variables merely have a name and an int value;
header: All entities start with a header. The header contains, among
other elements, the entitity's index, and name, as well as offset of
its variable, code, html and transitions sections;
hex: a support class used by the Disassembler to display
hexadecimal values in a configurable format;
Lfstream: provides an std::fstream as well as locking facilities;
Object: defines the structure and facilities of Object
data. In addition to plain objects generic objects can be defined
by some users. Generic objects are automatically added to users (each
user received one copy of each generic object that has been
defined). These copies are invisible, until the user changes its own
status in such a way that those objects become visible. Once they are
vidible, the user may get those objects, after which they remain
visible to the user;
OData: the class OData holds generic data associated with
objects;
Opcode: all assembly-language opcodes are defined in the enum
Opcode which is a public enum defined in the class OPC. Also,
this class provides the human-readable transcripts of the various
opcodes;
Options: a commonly used class preparing command-line options for
`consumption'. It is the responsibility of the class Options to
provide directly usable information, like the path names of all binary
files that are used by the game;
RuntimeFunctions: this class offers static functions runtime,
providing function information (name, function address) given the
function's index; the function's index, given the function's name; and
initializing the function's addresses when providing an
initializer_list of function addresses. The compiler needs to know the
function's index, given its name; the disassembler needs to know the
function's name given its index, and the Monitor's Executor provides
the run-time function addresses. If the latter class would provide all
this information it would have to be defined in the library. But
conceptually the Monitor's facilities are irrelevant to the compiler
and to disassembling programs. This design problem is solved by
escalation (Lakos, 1996): the essential elements are implemented
in RuntimeFunctions, allowing Executor to add its function
addresses one when needed. Also, Runtimefunctions may declare a
class Executor, allowing it to provide storage for pointers to
functions from that class, without having to read Executor's
header file;
State: defines the structure and facilities of States, which are
the nodes of the maze (i.e., the network);
Tools: a set of static functions simplifying, e.g., file processing;
Transition: defines the structure and facilities of transitions:
commands and instructions defining how a transition from one state to
another can be accomplished;
types: binary files can frequently use smaller data sizes than
required for int-sized values. E.g., user-IDs only take one byte
since there will be less than 250 users. Type-names for such types
(and their definitions, as well as facilities for conversions between
types) are declared in the file library/types/types.h;
UData, like OData, this class provides data and facilities for
manipulating data associated with users;
User: defines the structure and facilities of User-records found in
the binary users file.
Expr: the expression library. This is a support library for the
compiler, implementing expression handling. It contains the
following classes:
ExprData:
ExprBinOps:
ExprUnOps:
Expr:
Semantic:
user object is created or activated, and you
may enter commands to traverse through the maze. While traversing the maze you
collect points. You may also encounter problems, which may cause you to lose
points. If you do not actively participate for about five minutes you're
automatically logged out: objects you carry are left in the state you're
currently in. A forced disconnect also results in losing some points. If
that's not what you want, you can also explicitly leave the game. In the
latter case you do not lose points, but you will drop all the objects
you're currently carrying.
The maze, however, is not a static thing: in addition to traversing the maze, you can also add new states to the maze, thereby extending the maze with complete new descriptions and features. Because of the potentially very different user-contributions it's likely that the maze becomes a very varied environment. Actively contributing to the maze's contents also earns you points.