From 155a1edae29fb351bd9656150f086d244fc672a6 Mon Sep 17 00:00:00 2001 From: Cody Boone Ferguson <53008573+xexyl@users.noreply.github.com> Date: Fri, 14 Apr 2023 05:55:23 -0700 Subject: [PATCH] Update 1993/rince Rename rince.design design.md. Format fixes in README.md. --- 1993/rince/README.md | 170 +++++++++++++++++++++------------------- 1993/rince/design.md | 100 +++++++++++++++++++++++ 1993/rince/rince.design | 84 -------------------- 3 files changed, 191 insertions(+), 163 deletions(-) create mode 100644 1993/rince/design.md delete mode 100644 1993/rince/rince.design diff --git a/1993/rince/README.md b/1993/rince/README.md index e888c94b1..1e91c8620 100644 --- a/1993/rince/README.md +++ b/1993/rince/README.md @@ -1,74 +1,81 @@ # Most Well Rounded - James Bonfield - MRC Laboratory of Molecular Biology, - Hills Road, - Cambridge, - England +James Bonfield +MRC Laboratory of Molecular Biology, +Hills Road +Cambridge +England ## To build: - make all +```sh +make all +``` [Yusuke Endoh](/winners.html#Yusuke_Endoh) supplied a patch to get this to work in modern systems. Thank you Yusuke! - - ## To run: - ./rince [cabbage] +```sh +./rince [cabbage] +``` where: - [cabbage] a CABBAGE description file (default: `rince.c`) - - - - - + +`[cabbage]` is a CABBAGE description file (default: `rince.c`) ## Judges' remarks: The author has provided several CABBAGE files for your amusement: -- `rince.data1` plays breakout. Keys are ',' for left, '/' for right, and '.' for 'fire the ball'. +- [rince.data1](rince.data1) plays +[Breakout](https://en.wikipedia.org/wiki/Breakout_(video_game). Keys are `,` +for left, `/` for right, and `.` for 'fire the ball'. -- `rince.data2` plays the old rince game from IOCCC 1991. +- [rince.data2](rince.data2) plays the old [Rince](/1991/rince/rince.c) +([README.md](/1991/rince/README.md) game from IOCCC 1991. -- `rince.data3` Sokoban screen 11. You are the 'o' character. You must push the -money 'm' into the dotted region of the screen. The game is considered finished -when all the `m`s are then `M`s. +- [rince.data3](rince.data3) Sokoban screen 11. You are the `o` character. +You must push the money `m` into the dotted region of the screen. The game is +considered finished when all the `m`s are then `M`s. -- `rince.data4` Sokoban screen 13. Same rules as above. +- [rince.data4](rince.data4) Sokoban screen 13. Same rules as above. -For a brief design description, see [rince.design](rince.design). +For a brief design description, see [design.md](design.md). The `select(2)` from SunOS says: - BUGS +``` +BUGS - ... +... - select() should probably return the time remaining from the - original timeout, if any, by modifying the time value in - place. This may be implemented in future versions of the - system. Thus, it is unwise to assume that the timeout - pointer will be unmodified by the select() call. +select() should probably return the time remaining from the +original timeout, if any, by modifying the time value in +place. This may be implemented in future versions of the +system. Thus, it is unwise to assume that the timeout +pointer will be unmodified by the select() call. +``` -Systems such as Linux does return the remaining time in timeout +Systems such as Linux do return the remaining time in timeout field (0 if no keys were pressed), but `rince` assumes that timeout remains unmodified. It has been suggested that: - select(k,&y,0,0,&v) - +```c +select(k,&y,0,0,&v) +``` + should be replaced with: - select(k,&y,0,0,(v.tv_usec=1< + + 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 a space ship (as in the [Space +Invaders](https://en.wikipedia.org/wiki/Space_Invaders) 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 `*1` should +be used instead. Now the format of the game description file is now +the following: (angle brackets denote an 'entity' to be defined). + + +``` + *\n*\n[ \t]+\n + +``` + +The `` should take into account the newline at the end of each line +of map, and hence should also be one larger than expected. diff --git a/1993/rince/rince.design b/1993/rince/rince.design deleted file mode 100644 index 67a451643..000000000 --- a/1993/rince/rince.design +++ /dev/null @@ -1,84 +0,0 @@ - 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). - - *\n*\n[ \t]+\n - - - The should take into account the newline at the end of each line - of map, and hence should also be one larger than expected.