brandon-rhodes / python-adventure

Original Colossal Caves adventure game, but in Python 3

Welcome to the git repository for the Python 3 version of Adventure! The project README is one level deeper, inside of the package itself:

adventure/README.txt

python-adventure's Issues

Explicit grant of license

The code base is subject to copyright, but there is no copyright notice and no explicit grant of license. Recipients of the work can reasonably assume they have no valid license to copy, modify, and/or redistribute the work.

Please make an explicit grant of license in the work itself, citing specific license terms, and clarifying the grant is from the specific copyright holders.

Clean up save file during Doctest

The Doctest in the README.txt generates a save file, and fails to clean it up. This causes problems during automated build and testing: the tree is left in a dirty state.

Instead, it would be better if the test run cleans up after itself by deleting the generated file.

Tags from Bitbucket repository

Please add to this repository the tags that were in the Mercurial repository at Bitbucket.

Move one-time setup out of ‘loop’ function

The adventure.loop could be a proper Read-Eval-Print Loop for the program, by refactoring the one-time setup out of that function.

Please refactor the adventure.__main__ module so that loop reduces to a function that takes a single parameter, the already-initialised Game instance, and just plays the game on that instance.

Include non-program source files in the source distribution

The source distribution created by Distutils has some useful defaults for which files to include. These are not perfect, however, and should be customised by a MANIFEST document.

The MANIFEST document can be generated by Distutils at build time, from a MANIFEST.in template. See the MANIFEST.in section of the Python Packaging User Guide.

Please add a MANIFEST.in template to specify explicitly which non-program files to include in the generated source distribution.

Obtain program's command name from command-line argument list

When the stand-alone program has an arbitrary file name (for example, when issue #8 is accepted), the command to invoke the program may change.

The command that was actually used to invoke the program is available, at index 0 of the command-line arguments.

By getting argv[0] as the command name, this can then be provided to the argparse.ArgumentParser instance as its prog parameter, and hence have the correct command name appear in the parser's output messages.

Set terminal to upper case while program is running

For greater verisimilitude with the original ADVENT, the command-line program could set the terminal attributes to force all text to upper case while the program runs.

This would mean the user's own typed text, while it is received in the program however the user types it, would appear on the terminal in upper case.

KeyError in describe_location on user movement

Hey Brandon--

I hate to open an issue on code that hasn't been touched for two years, but I was playing python-adventure today (I recently watched your python/unix keynote and was so happy you ported adventure to python) and hit a bug.

I was going to try to do some debugging myself but I saw a few too many spoilers in the source code.

The exception didn't crash the game but it did occasionally reoccur. I tried rerunning python-adventure with the same sequence of commands a few times but didn't see the error again. I believe the error has to do with the random dwarf movements.

I've attached the markdown snippet of the first error traceback. I also have a gist of the complete game session as well as a filtered version with just my python commands.

This obviously isn't very important, but I thought you may want to give it a look!

 >>> down
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "~/personal/python-adventure/adventure/prompt.py", line 18, in __repr__
    output = self.game.do_command(self.words)
  File "~/personal/python-adventure/adventure/game.py", line 437, in do_command
    self._do_command(words)
  File "~/personal/python-adventure/adventure/game.py", line 506, in _do_command
    self.dispatch_command(words)
  File "~/personal/python-adventure/adventure/game.py", line 553, in dispatch_command
    return self.do_motion(word1)
  File "~/personal/python-adventure/adventure/game.py", line 701, in do_motion
    self.move_to(move.action)
  File "~/personal/python-adventure/adventure/game.py", line 186, in move_to
    self.move_dwarves()
  File "~/personal/python-adventure/adventure/game.py", line 325, in move_dwarves
    self.describe_location()
  File "~/personal/python-adventure/adventure/game.py", line 379, in describe_location
    self.write(obj.messages[prop])
KeyError: 0

Can we create our own adventure?

Can we?

Avoid traceback/name errors

It would give a better "flavour" if the program did not respond:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'ws' is not defined

or

  File "<stdin>", line 1
    open grate
             ^
SyntaxError: invalid syntax

when a faulty input is given. Perhaps:

SORRY, I DO NOT UNDERSTAND "ws"

would be a better response.

KeyError crash issue near Y2 rock.

> n
YOU ARE IN A LOW N/S PASSAGE AT A HOLE IN THE FLOOR.  THE HOLE GOES
DOWN TO AN E/W PASSAGE.

THERE IS A SMALL WICKER CAGE DISCARDED NEARBY.

> n
Traceback (most recent call last):
  File "/usr/games/adventure", line 9, in <module>
    load_entry_point('adventure==1.4', 'console_scripts', 'colossal-cave-adventure')()
  File "/usr/share/colossal-cave-adventure/adventure/__main__.py", line 101, in main
    loop(game)
  File "/usr/share/colossal-cave-adventure/adventure/__main__.py", line 79, in loop
    baudout(game.do_command(words))
  File "/usr/share/colossal-cave-adventure/adventure/game.py", line 437, in do_command
    self._do_command(words)
  File "/usr/share/colossal-cave-adventure/adventure/game.py", line 506, in _do_command
    self.dispatch_command(words)
  File "/usr/share/colossal-cave-adventure/adventure/game.py", line 553, in dispatch_command
    return self.do_motion(word1)
  File "/usr/share/colossal-cave-adventure/adventure/game.py", line 701, in do_motion
    self.move_to(move.action)
  File "/usr/share/colossal-cave-adventure/adventure/game.py", line 186, in move_to
    self.move_dwarves()
  File "/usr/share/colossal-cave-adventure/adventure/game.py", line 325, in move_dwarves
    self.describe_location()
  File "/usr/share/colossal-cave-adventure/adventure/game.py", line 379, in describe_location
    self.write(obj.messages[prop])
KeyError: 0

Happened on stream at 23 minutes if you want to check it out too. I'll see if I can figure out how to reproduce it.
https://www.twitch.tv/videos/709451376

Parameterise the command-line arguments container

The adventure.loop function unconditionally reads command-line arguments from sys.argv (via the default behaviour of argparse.ArgumentParser.parse_args).

This makes it more difficult to treat the loop function as a testable function.

Please allow this dependency to be explicitly provided to the function, via an argv parameter that is then used as the command-line arguments list.

Install stand-alone program via Setuptools “entry points”

The Setuptools “entry points” feature parses a specified Python callable, and will at install time set up external entry points. For “console scripts” this installs a stand-alone program for the specified entry point.

Please add a “console_scripts” entry point to install a stand-alone ‘adventure’ program.

'walk' command in -m mode crashes game

64-bit arch linux (up to date), XTerm(309), and python 3.4.1.

I downloaded a new clean version (adventure-1.2) to make sure I hadn't changed anything.

Here's my xterm session:
aaron% python -m adventure
WELCOME TO ADVENTURE!! WOULD YOU LIKE INSTRUCTIONS?

no
YOU ARE STANDING AT THE END OF A ROAD BEFORE A SMALL BRICK BUILDING.
AROUND YOU IS A FOREST. A SMALL STREAM FLOWS OUT OF THE BUILDING AND
DOWN A GULLY.

north
YOU ARE IN OPEN FOREST, WITH A DEEP VALLEY TO ONE SIDE.

south
YOU'RE IN FOREST.

walk
Traceback (most recent call last):
File "/usr/lib/python3.4/runpy.py", line 170, in _run_module_as_main
"main", mod_spec)
File "/usr/lib/python3.4/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/aaron/adventure-1.2/adventure/main.py", line 43, in
loop()
File "/home/aaron/adventure-1.2/adventure/main.py", line 40, in loop
baudout(game.do_command(words))
File "/home/aaron/adventure-1.2/adventure/game.py", line 432, in do_command
self._do_command(words)
File "/home/aaron/adventure-1.2/adventure/game.py", line 501, in _do_command
self.dispatch_command(words)
File "/home/aaron/adventure-1.2/adventure/game.py", line 611, in dispatch_command
method = getattr(self, method_name)
AttributeError: 'Game' object has no attribute 'i_walk'

Add original documentation for data file parser

The data file format is described in specific detail in the original Fortran code.

We can take those original comments and turn them into a docstring on the handler for each section.

Move main-line exception handling to custom ‘main’ function

The adventure.__main__ module has top-level code which catches any EOFError and simply discards it (with a pass statement).

try:
    loop()
except EOFError:
    pass

What is the purpose of that? Is there any condition where EOFError is not a bug; and if so, why not handle that condition specifically?

Maintain separate change log document

The change log is currently tacked onto the end of the README document, down in the Python module. I think the information deserves a top-level change log document.

This would also allow expanding the format of the log: a separate section for each version, specifying release date and maintainer, with a bullet list of user-visible changes in each version.

Use ‘cmd’ module to provide interactive command line

Would it be against the intent of this package, to improve the interactive command interface?

Python's standard library cmd module provides a much nicer interactive command line than the basic input function.

But perhaps the intent of this code is to mimic as closely as possible the limited features of the original. I'd love to know which is the case.

Allow import of ‘adventure.__main__’ module

The adventure.__main__ module cannot be safely imported; it goes ahead and begins the game loop.

This behaviour foils the ability to unit-test the code in that module. It also prevents setting an “entry point” to import, then run a function.

Please move the top-level main-line code to a if __name__ == '__main__' block.

Migrate VCS ignore patterns to Git

Please migrate to a Git ignore file, and drop the unused Mercurial ignore file.

Add a Unix manual page for the stand-alone program

The program invoked to run the game (with the name colossal-cave-adventure, for example) should have a Unix manual page describing what the program is.

This allows someone whose only interface to the program is that command, to get information from a standard location about the program and its significance.

Please add a Unix manual page for colossal-cave-adventure as user documentation.