Usage

• The README contained everything I needed to easily use the program:

• The program compiles/runs without errors:

  rename Makefile.txt to Makefile and address the compile warnings (probably would be addressed automatically by following the Rule of Representation and moving data into a separate file).

• The program worked as advertised:

Style

• The code is cleaning divided into modules and multiple files:

  While there is a Room class, data for rooms seems to be spread across different areas. There are several other opportunities for improved modularity, for example, it's common to prompt the player for a choice, the code for this could be placed in a module to reduce the amount of repeated code that all does the same thing.

• Variable and function names are meaningful:

  It seems like roomlistError() isn't named appropriately for what its function is.

• Comments are used where appropriate:

  the code was easy to follow without comments, but some docstrings would have been useful to document the API.

Philosophy

• The program most closely follows the ed-like interface pattern:

  The interface would have been cleaner with less prompting and instead using a command-based interpreter like bc. This would also help shift complexity into the data (Rule of Representation, see below).

• This choice of pattern is a good one for this application:

  this is a good interface style for this type of program.

• This program follows the Rule of Silence and Least Surprise:

• This program follows the Rules of Modularity and Composition:

  A clearer separation between game data and interface would allow for more flexibility, e.g. network and multi-player possibilities.

• This program follows the Rules of Representation and Simplicity:

  All game data was included in the source code (there are some separate map files but they didn't appear to be used). In addition, all direction choices are also hard-coded in, rather than extracting that information from the data.