ECE 2524

Introduction to Unix for Engineers

Freedom of Choice

Usage

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

    Include more about the game, less about the assignment! It was easy enough to get started, but there was no information about building or running the game.

  • The program compiles/runs without errors:

  • The program worked as advertised:

    Can't get past the 'fight or run' descision. Pressing Ctrl+d will go into an infinte loop.

Style

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

  • Variable and function names are meaningful:

  • Comments are used where appropriate:

Philosophy

  • The program most closely follows the ed-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:

    I think some of the control code could be moved into a separate module, simplifying the UI code.

  • This program follows the Rules of Representation and Simplicity:

    I think having three separate states for creating weak, medium and strong enemies is not necessary and increasses complexity. All three states are doing the same thing, just with different data. Similarly with fight1,fight2,fight3. Extend what we did to transform the weapon choice complexity into a simple list-search problem to eliminating some unnecessary states. Be careful not to abuse your objects. While the 'fight' or 'run' decision is similar in game play to the 'choose your weapon' decision, 'fight' and 'run' aren't weapons and so shouldn't be Weapon objects. If 'fight' and 'run' are just used to control next state, why not make the decision list a std::vector<string>?