Hunt the Wumpus

Last Thursday night was the monthly meeting of the London Python Dojo. The Dojo is a club for Python developers to get together, learn new tools, techniques and libraries for Python or just share experiences. Tim Golden described what happened at a previous Dojo, which paints a picture of the general mixture of things that happens at one of these events.

Recently the Dojos have often had a mild game programming theme, and this is understandable: game programming is more light-hearted than the kind of tasks most of us do for a living, and stretches to cover many facets of Python. This Dojo there were a number of projects proposed and voted on, but a Hunt the Wumpus game seemed to have substantially better support than the other options.

Nicholas Tollervey explained the basic rules for the Hunt the Wumpus of this challenge:

• There is a labyrinth of rooms through which the player can move.
• There is a "wumpus" that also moves through these rooms.
• If the player is in a room adjacent to the "wumpus", the player can hear it.
• The player wins if he and the wumpus are in the same room.

With a mere hour and a half's coding time this was a relatively steep challenge, but the five teams each produced something of an interesting nature. One team demonstrated efficient maze storage using simply a python set of 2-tuples (the room coordinates). Another demonstrated a talking wumpus using Mac's say command.

Our team was able to demonstrate a graphical (ASCII-art) implementation of these rules, including random maze generation and a roaming wumpus (and a knowledge of pig latin):

#####################

#     #   #         #

# # # ### # ### ### #

# # #   #   #   #   #

### ### # ### #######

#   #   # #   #     #

# ### ##### ### ### #

# #         #     # #

# ##### ##### ##### #

#     # #     #     #

# ### # # ###########

# # # # #   #       #

# # # ##### # ##### #

#   #     # #     # #

### ### ### ##### # #

# #   #     #   # # #

# ### ####### # ### #

# #   #       #     #

# # ### ########### #

#    W P#           #

#####################

ouyay ancay earhay a umpusway omingcay!!

terenay a irectionday:

I feel our team benefitted strongly from splitting efforts into two streams, one working on bottom-up datastructures for representing and modifying the maze, player and wumpus, and the other researching maze generation on Wikipedia and then implementing it (instructively slowed down so that the algorithm could be seen working), and crafting the game loop and I/O.

I think the most impressive creation was the entry that replaced high-brow notions of mazes and even game state with heavy use of Python's random module, and simply delivered the requisite user experience:

You are in a maze of twisty passages, all alike. Where's the Wumpus..?

Which direction ['e', 'n', 's']? n

You hear the Wumpus....

You are in yet another dark mysterious room.

Which direction ['n', 'w']? w

You hear the Wumpus....

You are in yet another dark mysterious room.

Which direction ['e', 'n', 's']? e

You hear the Wumpus....

You are in yet another dark mysterious room.

Which direction ['e', 'n', 's', 'w']? n

You are in yet another dark mysterious room.

Which direction ['n', 's', 'w']? w

You hear the Wumpus....

You are in yet another dark mysterious room.

Which direction ['e', 'n', 's', 'w']? w

You are in yet another dark mysterious room.

Which direction ['n', 'w']? n

You found the Wumpus! Well done!

It even delivers the user experience of running successful nosetests.

Though most attendees found this a very humorous approach, I think there's a really powerful lesson here. For Hunt the Wumpus, this incarnation genuinely delivers a better play experience than any of the others. Why? Simply because there is a hard upper and lower bound on how many moves a game will take, which means you are guaranteed a reward after 7 to 12 moves - and that's a better balance of reward to chore than any of the other games.

As game programmers we only need to create the illusion that the world works a certain way, and we should be free to look for ways to do it more cheaply or for better control over the user experience.