Mrs. Peacock, in the dinning room, with the candlestick!
Usage
-
The README contained everything I needed to easily use the program:
-
The program compiles/runs without errors:
rename
Makefile.txt
toMakefile
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.