Usage

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

  wasn't clear which program to run since both were marked executable.

• The program compiles/runs without errors:

• The program worked as advertised:

Style

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

• Variable and function names are meaningful:

• Comments are used where appropriate:

  though following a standard format to specify input/output data would aid in document generation.

Philosophy

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

  in some cases, depending on a user's terminal size, displayed text is hidden. A simple pager implementation might be a nice feature without going to a fullblown rouge-like interface pattern.

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

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

• This program follows the Rules of Modularity and Composition:

  a little more modularity could be gained by accepting a sequence of commands on standard input. There could even be a separation into a game engine that accepted commands and prouced JSON or Yaml output with information about the current state which could then be used by a light wrapper that imlemented the text based user interface. Why go through that extra work and abstraction layer? It could allow for easy expansion to a multiplayer or network based environment, or even a simple graphical interface, all running the same game.

• This program follows the Rules of Representation and Simplicity:

  nice extension of the data format we did in class to implement locked/unlocked rooms.