ECE 2524

Introduction to Unix for Engineers

Reviewing the Combat Simulator

Usage

The Combat Simulator (https://github.com/bt2016/combatSimGithub) was very easy to get running. Being a Python program I simply needed to find the main python file and run it. The README indicated that this file was userInterface.py so once I had cloned and went into the git repository I ran the command: $ python3 userInterface.py and the program started.

Style

I was very impressed with the style of the code. First of all it implemented an efficient usage of record_jar data formatting throughout the game. This was useful for an adventure game type with a pre-designed world interface and statistics that were updated throught the gameplay. Reading through the code I was able to identify the implementation of many aspects of the game. When the code seemed to look complex there were comments that summarized the general equations being performed by the code at that point. With this I was able to see how the battles in the game were run and coded. It was also quite clear in the code how all of the playable commands in the game were interpreted. Overall, I think it was well written.

Philosophy

I think the toughest aspects of a third-party user playing a text-based game are intially understanding how to play and comprehending what is going on during game play. In my intial play of Combat Simulator, I was very quick to pick up what was going on. I believe this was a result of proper usage of the Rule of Silence. The game showed me just enough information so that I was rarely ever confused and not an excessive amount to overwhelm me.

Another important issue to observe in a game like this with multiple algorithms to run gameplay and stat updates, is code/design complexity. Looking through the Combat Simulators code, I can say that the code complexity was kept to a minimum. In reflection, the code followed two additional rules of the Unix Philosophy fairly well, the first of these being the Rule of Transparency. The game utilized many different classes and files. Each of these classes and files however were named appropriately according to what they contain and what they do. This eliminates a lot of potential confusion. The second of these additional rules followed is the Rule of Composition. With all these different files and classes, the program still runs efficiently because these objects work well together. There are multiple instances throughout the code where certain files and classes are accessing actions of other classes and files and it all works in unison. With that being said, the modularity of the game is very good. It is divided up into different parts but all-in-all everything works well together.

Potential improvements: - Maybe provide a way that users can see the different affects of the different weapons if there are any.