Usage

The Dark Forest adventure game was very simple and intuitive to use. The instructions in the README.md file worked the first time I tried, although I had to be careful to add the ‘-n’ flag so denote a new user to the game. The commands I ran to run the program were:

$ make
# ./Forest -n

I didn’t notice any erros when compiling the program or running it. I encountered an invalid input situation when I played the game, but the creators had already taken that into consideration (After I created my account, I typed ‘Let’s go!’ to start the game, while it only accepts single characters and then the enter key to start).

Style

For the most part, all of the variables and/or functions have very intuituve names and helpful comments stating their purpose. The actual function of the program makes sense as well- the gameplay functions are contained in adventure.cpp, the authentication functions are contained in authentication.cpp, the text for the adventure is contained in story.rjar (as a record jar) and the README and Makefile files contain all of the proper information. Each cpp file also has a header file containing the declarations for each function as well. The only confusing part to read is the authentication part, but that isn’t crucial to the game’s operation- it’s mostly just a neat thing that the program also has in it. The story functions and elements are very easy to follow.

Some issues I have-

-While some of the files are commented very well (main.cpp, adventure.cpp, action.cpp) most of the authentication process is not commented and pretty hard to follow at a glance. Comments would be very helpful to both reviews/users like me and to the original authors if they want to come back and take a look at their work later.

-In terms of the actual gameplay, there is a hint to accept hugs at the main screen for stat boosts. Well, looking at the code…there’s no end. You can boost your stats to infinity. I accepted 5 hugs and never even got below 50 health in the game, nor lost more than 1 sanity (some of those events are creepy, but I didn’t lose any sanity- maybe I just made really good decisions?).

-There’s some occurances of railroading- I couldn’t move onwards until I found a very certain object or action, but I’m going to let it slide because there’s 1455 lines of code in the story.rjar file and frankly, nobody’s perfect. This was a damn good game- I played it once and got to the “left smoke cabin” and I feel like that was one of a few major branches in the game. I’ll excuse the fact that I had to go to the basement, etc. to win the game instead of leaving the cabin and exploring the “right smoke” or somewhere else because the game isn’t 100% perfect, but it’s really good nonetheless.

Philosophy

Well, I’m just going to say now- I’m not really an expert on Unix design philosophy, but I have a feeling that it follows the design principles pretty well. It follows the ed pattern- take input, modify something, display output, prompt for input, repeat. The pattern is perfect for the game- it is a text-based adventure after all. I’m not sure where it stands with the Rule of Silence, however- I don’t think I encountered that situation, it being a text game and all. It follows the Rule of Least Surprise fine- instructions were either displayed on the screen (help, exit) or were one of the answer choices (a,b,c, etc). The Rule of Modularity seems to be implemented very well here, other than the little issue with the comments in the verification files (see above). All in all, this program seems to perform very well both in practice and in accordance with Unix philosophy. I’m sure that if I tried long enough, I could find some way to break the program, but I didn’t do so in ordinary operation, and all of my input errors were accounted for appropriately. Overall, great job!