REV0 C++ (Visual Studio on Windows) 405
#include"stdafx.h"
#include<stdlib.h>
#include<time.h>
int main(){srand(time(NULL));char i,h=rand()%19,w=rand()%19,p=19,d=0,q,e,m[]="e@LwQMQOSOLT";while(p-h&&p-w){for(i=3;i--;){q=(p+m[p%4*3+i])%20;if(q==w)puts("you smell a wumpus");if(q==h)puts("you feel a breeze");}scanf_s("%d",&i);e=(d+i/10)*m[p%4]%3;q=(p+m[p%4*3+e])%20;if(i%5){if(q==w){puts("YOU KILLED THE WUMPUS!");h=p;}else{puts("arrow missed");w=(w+m[w%4*3+rand()%3])%20;}}else{p=q;d=e;if(p==h)puts("YOU FELL IN A HOLE!");}if(p==w)puts("THE WUMPUS GOT YOU!");}}
Below is a playthrough, demonstrating that (provided you don't start right next to a hazard) with correct play you can always win. The player feels a breeze, turns back and does a complete counterclockwise loop. As it takes him exactly 5 moves to feel a breeze again, he knows the hole to his right, and gets as far away as possible. Similarly, when he smells the wumpus, not knowing whether it is right or left, he turns back and does a clockwise loop. It takes him 5 moves to smell the wumpus again, so he knows it is to the left and shoots with certainty.
If he had looped the other way he would have found the wumpus sooner and known it was in the same direction he was turning.
REV1 C (GCC on Cygwin), 431-35% bonus = 280.15
#define u(t,s,c) if(t){puts(s);c;}
i,d,e,a,b;main(){srand(time(0));char q,p=19,h=rand()%p,w=rand()%p,*m="e@LwQMQOSOLT-\\/\n \v ";
while(p-h&&p-w){
for(i=3;i--;){q=(p+m[p%4*3+i])%20;u(q==w,"you smell a wumpus",a|=2<<p)u(q==h,"you feel a breeze",b|=1<<p)}
for(i=20;i--;)printf("%c%c",i==p?m[d+12]:48+(a>>i&2)+(b>>i&1),m[i%4+15]);
scanf("%d",&i);e=(d+i/10)*m[p%4]%3;q=(p+m[p%4*3+e])%20;
if(i%5){u(q-w,"arrow missed",w=(w+m[w%4*3+rand()%3])%20;a=0)else u(1,"YOU KILLED THE WUMPUS!",h=p)}
else{p=q;d=e;u(p==h,"YOU FELL IN A HOLE!",)}
u(p==w,"THE WUMPUS GOT YOU!",)}}
Newlines added for clarity. The changes from Rev 0 are as follows:
A big thankyou to @Dennis for recommending GCC compiler on Cygwin Linux emulator for Windows. This compiler does not require the include
s in the rev 0 program, and it allows default int
type for variables and main.
This is a life-changing golfing tip!
Additionally running in Linux means that \f
does cause the cursor to move down without doing a carriage return (unlike in Windows where it just produces a printable symbol.) This has allowed considerable shortening of the printf statement that prints the board
Several additional tips from Dennis in the comments, and one of my own: change of condition when checking if arrow hit the wumpus: if(q==w)
>if(q-w)
(..else.. is reversed)
Addition of graphic display showing the information the player knows about where a wumpus is smelt / a breeze is felt to claim the 35% bonus. (I deleted the old debug version of this which showed the exact position of the wumpus and hole. It can be seen in the edit history.)
REV2 C (GCC on Cygwin), 389-35% bonus = 252.85
#define Q(N) (N+"QTLOQMQOSOLT"[N%4*3+e])%20
#define P printf(
i,d,e,a,b;main(){int p=19,q=srand(&p),h=rand()%p,w=rand()%p;
while(p-h&&p-w){
for(e=3;e--;){q=Q(p);q-w||P"You smell a wumpus\n",a|=2<<p);q-h||P"You feel a breeze\n",b|=1<<p);}
for(i=20;i--;)P"%c%c",i-p?48+(a>>i&2)+(b>>i&1):"-\\/"[d],"\n \v "[i%4]);
scanf("%d",&i);e=(d+i/9)*"edde"[p%4]%3;q=Q(p);
if(i%5){e=rand()%3;w=q-w?P"Your arrow didn't hit anything\n",a=0)&Q(w):(p=20);}
else p=q,d=e;
}
P p-20?p-w?"YOU FELL IN A HOLE!\n":"THE WUMPUS GOT YOU!\n":"YOU KILLED THE WUMPUS!\n");}
Thanks again to Dennis for refactoring my code:
Char constant m[]
replaced with literals (I didn't know you could index a literal.)
Seeding of random numbers with stack variable (system dependent, some systems randomise memory allocation as a security measure.)
Macro with puts
replaced with a macro with printf
and additional code which must be executed when the message displayed placed inside printf
arguments (advantage taken of the face that printf does not print the last few arguments if there aren't enough format specfiers in the format string.) if
replaced by ||
Calculation of new position of player/wumpus placed inside new macro.
Win/lose messages placed outside while
loop. if
replaced by conditional operator.
Use of conditional operator in line for shooting arrow. If the player misses, this requires both printing a message and adjusting wumpus position. Dennis offered a couple of ways of combining printf
and the calculation of wumpus position into a single expression, but I have gone with one of my own. printf
returns the number of characters printed, which for Your arrow didn't hit anything\n
is 31 (11111 binary.) So, 31&Q(w)==Q(w)
.
My other contribution to this edit has been elimination of some unnecessary brackets.
Output
Here the player has already found where the Wumpus is, but chooses to do a thorough explore to find out exactly where the pit is, too. Unlike my old debug version which showed where the wumpus and pit were throughout the game, this shows only the rooms where the player has visited and felt a breeze (1) smelt the wumpus (2) or both (3). (If the player shoots an arrow and misses, the variable a
containing the wumpus position info is reset.)
ICOSAHEDRON REPRESENTATION
Note: this section is based on rev 1
My star feature! There is no graph in my code. To explain how it works, see the world map below. Any point on the icosahedron can be represented by a latitude 0-3 and a longitude 0-4 (or a single number, long*4+lat
.) The longitude line marked on the map passes only through those faces with longitude zero, and the latitude line passes through the centre of the faces with latitude zero.
The player can be oriented on 3 possible axes, represented by the symbols as follows: north-south-
northeast-southwest\
northwest-southeast /
. In any given room he has exactly one exit on each of these axes available to him. In the display shown the player makes a complete clockwise loop. It is generally easy to identify from the player marking where he came from, and therefore where he is allowed to go to.
The one case that is a little difficult for the uninitiated eye is the fourth one. When you see a slant in one of these polar rows, the player has come from the polar cell nearest the outside end of the slant and is facing generally towards the equator. Thus the player is facing southeast and his options are: 15(SOUTH, the cell to the right) 25(northEAST, the cell above) or 35(northWEST, the cell below.)
So, basically I map the icosahedron to a 5x4 grid, with cells numbered 19 to 0 in the order they are printed. The move is made by adding or subtracting from the current position, depending on the player's latitude and direction, per the table below.
If the player goes off the bottom (west) of the board, he comes back on the top (east) side and vice versa, so his position is taken modulo 20. Generally the moves are coded into m[] by adding ascii 80 (P
) to the raw value giving the characters shown below, but principle any multiple of 20 can be added without affecting the operation.
Table of addition values for moves
Direction Symbol Latitude 0 1 2 3 Latitude 0 1 2 3
0, N-S - 1 -1 1 -1 Q O Q O
1, NE-SW \ -4 1 -1 4 L Q O T
2, NW-SE / 4 -3 3 -4 T M S L
The player's input (divided by 10 to remove the second digit) is added to his current direction and taken modulo 3 to get his new direction. This works fine in the majority of cases. However there is an issue when he is in a polar room and moves toward the pole. It will be clear when folding the map below that if he leaves the room facing "northeast" he will enter the new square facing "southeast" so a correction must be made. This is done in the line e=(d+i/10)*m[p%4]%3;
by the multiplication by m[p%4]
. The first four values of m[] are selected such that, in addition to their function above, they also have the characteristic m[1]%3==m[2]%3==1
and m[0]%3==m[3]%3==2
. This leaves the direction alone for the equatorial rooms and applies the necessary correction for polar rooms.
The logical time to do the correction would be after the move. However to save characters it is done before the move. Therefore certain values in m[] must be transposed. So the last 2 characters are LT
instead of TL
per the table above for example.
UNGOLFED CODE
this is rev 1 code, which is less obfuscated than rev 2.
This will run on GCC / Linux. I have included in the comments the extra code needed to make it run on Visual studio / Windows. It's a big difference!
//Runs on gcc/linux. For visual studio / windows, change printf(...)
//to printf(" %c%c%c",9*(i%4==1),i==p?m[d+12]:48+(a>>i&2)+(b>>i&1),10*!(i%2)) and uncomment the following lines
//#include"stdafx.h"
//#include<stdlib.h>
//#include<time.h>
//#pragma warning(once:996;once:430) //allow the use of scanf instead of scanf_s, allow default type=int.
//Though rather than using the pragma, it is shorter to follow compiler recommendation and use scanf_s and int.
#define u(t,s,c) if(t){puts(s);c;} //if(test){puts(string);additional code;}
i, //player input, loop counter
d,e, //current and proposed direction
a,b; //bit flags for where wumpus smelt / breeze felt
main(){
srand(time(0));
char q,p=19,h=rand()%p,w=rand()%p, //Initialise player, hole and wumpus. q stores proposed player position.
*m="e@LwQMQOSOLT-\\/\n \f "; //Chars 0-11: movetable. Chars 12-14:symbol for player. Chars 15-18: graphics format.
while(p-h&&p-w){
// Print warnings
for(i=3;i--;){q=(p+m[p%4*3+i])%20;u(q==w,"you smell a wumpus",a|=2<<p)u(q==h,"you feel a breeze",b|=1<<p)}
// graphic display
for(i=20;i--;)printf("%c%c",i==p?m[d+12]:48+(a>>i&2)+(b>>i&1),m[i%4+15]);
// Get player input and work out direction and room
scanf("%d",&i);
e=(d+i/10)*m[p%4]%3;
q=(p+m[p%4*3+e])%20;
// i%5 is false if player inputs 5 (move player) otherwise true (shoot arrow)
if(i%5)
{u(q-w,"arrow missed",w=(w+m[w%4*3+rand()%3])%20;a=0)else u(1,"YOU KILLED THE WUMPUS!",h=p)}
else{p=q;d=e;u(p==h,"YOU FELL IN A HOLE!",)}
u(p==w,"THE WUMPUS GOT YOU!",)
}
}
ISSUES AND CURIOISITIES
I have taken advantage of the point mentioned by @professorfish, if the wumpus and pit start in random places, there is no need for the player to start in a random place. The player always starts in room 19 facing north.
I understand that as the wumpus is "unaffected by the pit" the wumpus can start in, or enter the room where the pit is. In general this simplifies things except for one point. I have no specific variable to indicate the game is over; it is over when the player coincides with the wumpus or pit. So when the player wins I display the winning message but move the pit to the player to kludge out of the loop! I can't put the player in the pit as the wumpus might be there and I would get a message about the wumpus that I don't want.
The rev0program worked perfectly in visual studio, but the IDE said "stack corrupted around variable i" on exit. This is because scanf is trying to put an int
into a char.
Dennis reported incorrect behaviour on his Linux machine because of this. Anyway it is fixed by use of the correct type in rev 1.
The line for displaying the board in rev 0 is clumsy and appears slightly different on other platforms. In printf(" %c%c%c")
the middle %c is the printable character displayed. The last %c is either ASCII 0 or ASCII 10 (\n, newline with carriage return in Windows.) There appears to be no character in Windows that works in the console, that will go down a line without giving a carriage return. If there was I wouldn't need the first c% (ASCII 0, or ASCII 9 tab before latitude 1 character. Tabs are notoriously undefined in their behaviour.) The leading space improves formatting (puts latitude 3 & 2 characters nearer latitude 1 character.) Rev 1 has a revison of this line which uses a \f formfeed character and therefore needs no format character at the start of the printf. This makes it shorter, but the \f does not work in Windows.
Is it fine if there are parts of the program which terminate almost surely? For example, if I need to move the wumpus, due to a missed arrow, it would be easiest for me to search for it by looking at random rooms until I've found it. In theory this process could go on forever (with probability zero though), but in practice this will always find the wumpus quite quickly.
– Martin Ender – 2018-02-11T12:17:45.977Some clarifications: 3. if the wumpus was not in that room it is startled and moves to one of the THREE rooms.. so if you fire an arrow and miss, the wumpus may come and kill you, right? And the wumpus will only move if startled, otherwise it just stays put? 6. I understand the player's heading is determined by the room he came from. So if he came from the south his options would be 1.northeast 2.northwest 3.south and if he came from the north it would be the opposite. Also your rules seem simpler/golfier than the reference program (which I haven't investigated in detail yet.) Am I correct? – Level River St – 2014-04-21T22:38:39.050
Argh! I can't find any pictures of the dual graph of an icosahedron anywhere on the net. – Jack M – 2014-04-21T23:35:34.693
1@steveverrill Yes, if you spook it, it may come and kill you. If you don't spook it, it doesn't move. There are many variations on the game; many versions allow arrows to circle around and kill you, for example. I've pared that out. – Michael Stern – 2014-04-21T23:47:24.107
What is the meaning of "left, right, back", exactly? If I keep going back, will I rewind through my entire path from the beginning of the game? – Jack M – 2014-04-22T00:29:37.573
3
@JackM the map of the faces of an icosahedron is identical to the map of vertices of a dodecahedron, and that graph is easily found. Try for example https://www.wolframalpha.com/input/?i=DodecahedralGraph+edgerules or the equivalent Mathematica command GraphData["DodecahedralGraph", "EdgeRules"]. Either way you get {1 -> 14, 1 -> 15, 1 -> 16, 2 -> 5, 2 -> 6, 2 -> 13, 3 -> 7, 3 -> 14, 3 -> 19, 4 -> 8, 4 -> 15, 4 -> 20, 5 -> 11, 5 -> 19, 6 -> 12, 6 -> 20, 7 -> 11, 7 -> 16, 8 -> 12, 8 -> 16, 9 -> 10, 9 -> 14, 9 -> 17, 10 -> 15, 10 -> 18, 11 -> 12, 13 -> 17, 13 -> 18, 17 -> 19, 18 -> 20}
– Michael Stern – 2014-04-22T00:35:46.357@JackM It should be clear if you look at the faces of an icosahedron (or equivalently, the vertices of a dodecahedron). Every time you step into a room, you have a three doors, one to the front left, one to the front right, and the door you just walked through, directly behind you. For the first room, put a random door at the player's back. – Michael Stern – 2014-04-22T00:39:54.530
@MichaelStern So my interpretation is right - you'll need to store the player's entire history? – Jack M – 2014-04-22T00:51:20.670
2@JackM No, "back" implies turning around and walking back the way you came. If you hit "back" twice, you end up where you started. No need to store earlier game states. – Michael Stern – 2014-04-22T02:16:32.207
@MichaelStern from the WolframAlpha data, how do you find which way is left or right? – None – 2014-04-22T08:59:09.807
@professorfish If I understand your question correctly, the graph is symmetrical; establish either convention and it should be correct as long as you use it consistently. – Michael Stern – 2014-04-22T10:00:47.623
@MichaelStern I'm probably being a complete n00b here. For example, if you're in room 16, and the room "behind" you is room 8, how do you tell which of 1 and 7 is "left" and which is "right"? – None – 2014-04-22T14:04:42.457
@professorfish Below the list of connections, the Wolfram Alpha page (wolframalpha.com/input/?i=DodecahedralGraph+edgerules) displays graphics showing how the nodes connect. – Michael Stern – 2014-04-22T18:29:04.787
How flexible is the exit numbering? To explain what I mean, are there 20 possible states for "Where the player is" or 60? And must the numbering correspond to group operations or can e.g. the default be that
1
goes to the lowest numbered of the adjacent rooms? – Peter Taylor – 2014-04-25T21:05:16.957Michael, your answer to @PeterTaylor could save me over 20 characters. If I don't store the player direction it simplifies many formulas. Instead of 1=right 2=left 3=back, I can have 0=N/S 1=NE/SW 2=NW/SE directly. Moreover, as I was going for the 35% bonus, I don't have to display the player orientation either. I don't think it'll be enough to win against the latest golfscript answers, but I'd prefer your confirmation before I post my 35% bonus answer. – Level River St – 2014-04-27T11:38:48.243
Two more points: are quotation marks for string literals included in the byte count? for example is
"you smell a wumpus"
1 byte for the text, or 1 for the text + 2 quote marks = 3 total? (I have assumed 1.) Also, is it acceptable to have the player manually seed the random number generator like this:srand(getchar())
? This would save me a lot of bytes. – Level River St – 2014-04-27T11:45:19.847(1) My original answer to @PeterTaylor, that there are only 20 player states, was incorrect. Thinking clearly, there must be 60. (2) quotation marks are included in the one byte. (3) I think external seeding would be OK. Some of the original 1970s implementations did it that way (CP/M, I'm looking at you). – Michael Stern – 2014-04-27T19:01:54.753
Related: A Wumpus remake is featured in Land of Lisp. Here is the Common Lisp Source and the whole chapter in PDF
– Sylwester – 2014-05-05T23:59:28.997