------------------------------------------------------------
NB. If you wish to get hold of Bzip2, please pop along to...
http://www.muraroa.demon.co.uk/
------------------------------------------------------------

Okay. Basically, what works well as of the current version is map
generation, line of sight (everything not in LOS is greyed out) and config
file for key setup. The player, item and inventory structs and functions
have been started. Spells, monsters and combat are just stubs.

- Map generation is by far the most complex part of this. The GenerateRoom
routine (in map-internal.c) creates weird cave-looking rooms by a
conceptually simple method:

 //pseudocode
 while (room < target_room_size and squares_left)
  pick_random_square_from_stack_and_delete_from_stack
  add_surrounding_squares_to_stack

(actually, I use one stack and an array of pointers to places in that
stack, but the above is the underlying principle)

- config.c implements a simple parser for configuration files, that
probably can be extended to other uses than key configuration.

- The Player and Creature structs have identical upper parts, so that
one can use most routines for both by typecasting (Creature)player ...

- Almost everything in the game is in a linked list or contains one or
more linked lists. See lists.c and lists.h .

- One of the last things I did to this source was rewriting many routines
to use a "tagitems" calling convention, that is:

  createBlah (TAG_UGLINESS, 500, TAG_MONTY_PYTHON_FACTOR, 2.1);
   // (identifier, value) pairs, instead of fixed parameters that will
   // change dozens of times during developement

- creature.c allocates the correct amount of memory for a creature, but
does nothing more as of yet.

- pl_item.c and item.c is in its infancy. It has a demo item defined, and
allocates it to the player, and successfully displays it in the player's
inventory. Fragile. But item.h is quite well-developed, and ought to give
anyone ideas...

- lists.c contains your basic single-linked lists code + the NextTagItem
code.

- magic.c, help.c, combat.c, timer.c are just stubs.

- output.c / output.h / ncurses.c  encapsulates most of the
ncurses-specific stuff for easy porting.

- map.c ... Map_Scanfor was designed to scan for any interesting parameter
inside maps, but are currently not used for much besides finding a good
place for a corridor. map.c contains all routines that should be visible
outside map generation. GenerateCorridor currently uses a hit-and-miss
approach (copy map to temp_map -> run generatecorridor -> if grind to a
halt, try again -> if not copy temp_map to map) and can be improved much,
I suppose.

- types.h defines own UBYTE, BYTE, ULONG, LONG etc. types, also for easy
porting.

- I'm currently undecided on what's the best approach: Defining "id" in
all object structures or defining it in the "node" structure. It must be
defined in any case, so we can find a specific object that we don't have a
pointer to by some FindObject routine (to avoid passing a million pointers
around). (started, see FindWindow in output.c)

- writing colored strings to the screen is currently accomplished by
calling WriteStr as usual, with strings of the format "<White>Bob
<Yellow>the Big" ... WriteStr does not do %s and such expansion, so
sprintf() ing a string before passing it to WriteStr is a good thing. Look
to the bottom of player.c for an example.