Implementation notes    --------------------    Due to the long time this has been slowly evolving, it's hard to describe    quite whether it's been `implemented'. I think perhaps evolve is a better    term. I basic concept behind the program is to describe a game as a simple,    slightly cheaty, cellular automata system, with some of the transitions    bound to key presses.    For instance, assume you wish to make a boulder 'o' roll off a hill '/'    A standard automata would have 2 rules something like this:	o..			...		\..  -->  `o'		.o.  -->  `.'	...			.\.    However, the system I devised, in order to keep things small and neat(!),    was to define a 3x3 to 3x3 map (instead of the 3x3 to 1x1 shown above).    Hence:	.o.	  ...	.\.  -->  .\o	...	  ...    This does of course have the odd problem with clashes. What if we want to    roll two down boulders down simultaneously towards the same square.    I perform no buffering, and so this situation is just a 'fight it out' and    let which ever transition has priority win. Such a case may produce the    following change of maps (depending on which 'roll' transition is used    first).	o.o			..o	    o..	\./	changes to	\o/  or to  \o/	...			...	    ...    I claim that it is possible to perform all of the 3x3 to 1x1 transitions    in a 3x3 to 3x3 based system. One other feature added in is a work around    for the 'no buffering' problem. if we define an space ship (as in the    space invader example) to fly right, and we are 'walking through' our map    from top-left to bottom-right, then it is easy to foresee a situation where    our space ship would zip right as far as possible in only the one cycle    of the automata. However, a similar leftwards-bound space ship would only    move the required one square. For this reason I have two lists of    transitions and apply them independently of each other; first top-left to    bottom right, and the second in the reverse direction. This means that I    can make any 'object' move by any amount in a single transition.    Now comes the key important addition to make it 'game' worthy - the    addition of external control by the user. This is done by requesting that    some transitions are only valid when a certain key has been pressed.    So for example, if we (an @ symbol) wish to move right when the 'l' key    is hit we have a transition like:    Key: l	* * *		* * *	* @ .		* . @	* * *		* * *    Here I also use wildcards. On the match side (left) of the transition, an    asterisk will match against any character. On the update side (right), an    asterisk means 'keep whatever was here before'. So the above example    simply means to swap the '@' and '.' around when 'l' is pressed. For the    purposes of space saving, this transition is shrunk to a single line.    Key: K	a b c		1 2 3	d e f		4 5 6	g h i		7 8 9    is written as:    eabcdfghi512346789K    If there are no keys needed for this transition, the character '*' should    be used instead. Now the format of the game description file is now    the following: (angle brackets denote an 'entity' to be defined).    <top-bot transition>*\n<bot-top transition>*\n<X size>[ \t]+<Y size>\n    <map>    The <X size> should take into account the newline at the end of each line    of map, and hence should also be one larger than expected.