| To the faculty page of James Tam | Return to the course web page |
Due at 4 PM. For assignment due dates see the [main schedule] on the course webpage. Because we are coming to the end of the semester, unlike what may have occurred with previous assignments you should not count on receiving an extension for this assignment for a reason other than medically related ones. This means that you should expect the [regular late penalties] to be applied. The program must be written and run under python version 3.X and run on the computers in the tutorial labs.
Only new concepts that need to be applied in the assignment are listed, concepts previously applied in other assignments may need to used in the implementation of your solution.
Write a simple a text-based fight simulator [just for fun: here's a "2-person" fight sequence]. (In-depth martial arts knowledge is not mandatory to complete your assignment, you just have to make sure your program meets the design requirements and implements the functionality as specified).
There are two simulated opponents: an attacker (that only launches attacks) and a defender (that can only defend against the attacks). There's types of attacks categorized by height: low, medium and high (JT: to fulfill style requirements you need to use the global constants: LOW = 1, MED = 2, HIGH = 3 to represent each type of attack [see the ['Globals.py'] file]). To use these constants from another file/module you can use the following import: "from Globals import *" (or you can import the constants individually).
Similar to the attacks there are three types of defenses: low, medium and high. If the heights of the attack-defense match (e.g. both attack and defense are high) then the attack is blocked. Otherwise the attack is counted as a 'hit' (e.g. the attack comes in at medium height while the defender blocks either high or low).
Pseudo-code outline of how the program runs:
Prompt the user for the number of rounds (1-100) that the simulation will run.
Prompt the user for the proportions of low, medium and high attacks (the sum of the three proportions must equal 100%)[1]
The program will determine the height of the defense. The basic defender has roughly and equal chance for each type of defense to occur (e.g. 33% high, 33% medium, 34% low or some other roughly equal combination that sums up to 100%)
The simulation runs a round and the results of the attack-defense is tracked
by the defender.
The actual attack height will be generated each round according to the user specified probabilities.
The height of the defense will be generated each round with a roughly equal probability for each height.
The result of the attack-defense is displayed onscreen and its tracked by the program. (Both are same height means a 'block' otherwise the attack has 'hit').
The number of hits vs. blocked attacks are tracked and displayed oniscreen.
After the specified rounds have run then a report is written to a text file that summarizes the results.
After getting the turns and proportions, the program will then randomly generate attacks and defense. If you are unclear of how to write a program that generates some random events based on probabilities of those events then see the lecture and tutorial examples such as the following: [forest fire simulator]. A quick summary: Similar to the example programs the proportions for the type of attacks will specify the probabilities for each type of attach occurring:
e.g. 1: If the high, medium, low proportions are 100/0/0 then 100% attacks will be high
e.g. 2: If the high, medium, low proportions are 50/0/50 then each time an attack is generated there is a 50% high and 50% it will be low.
Program output is critical: The program will produce a number of statistics and display them during each round and at the end of the simulation. To make marking reasonable (and for you to be awarded credit) here is the information that MUST be generated by your program. (It is not reasonable for the marker to spend time hand tracing your program in order to evaluate functionality if your output doesn't present the required information).
Each round: the round number, the type of attack and defense chosen, the result of the attack-defense combination (showing the probabilities for the 3 types of defenses would be useful if you implement an [intelligent defender]).
General format (italics you have some flexibility in output, non-italics indicates exact text is required):
<Round #> ATTACKER: <Attack height> DEFENDER: <Defense height> <Result of attack-defense combination>Examples:
MK round 1: ATTACKER: low, DEFENDER: low .........Blocked
Here is a file that captures the output from my solution: [Round-by-round output]
At the end of Mortal Kombat, write to a (hard-coded file = always writes to this file without prompting the user for the name) called "summary.txt" the following information (exception handling via try-except must be implemented).
Total hits: <Total number of hits> Total blocks: <Total number of blocks>General format (italics you have some flexibility in output, non-italics indicates exact text is required):
Example:
Here is my ouput file: [Summary
at the simulation's end] The total number of successful attacks and blocks and the
probabilities of each type of attack-defense at the end (the values for the
attacker won't change but an [intelligent defender's] proportions should go
from equal values to more closely reflect the proportions of the attacker). These
outputs must not only present the needed information but must also be
reasonably formatted. Floating point values must display with two places of
precision. The program output is even more crucial when you have implemented
an intelligent defender. The marker must be able to see the effects of the
defender adapting to the pattern of attacks otherwise you may not get credit
for your work. The marker won't have the time to trace through your
program or program output if things are not explicit in your output.
The program must be split into multiple modules/files: Attacker, Defender, Manager and
the Driver. [Click here
for an overview] of these three classes. You will also refer to the constants
defined in the Globals module. Make sure you not
only submit each module individually. (You can submit multiple files in the D2L
Dropbox this term and latest versions of each of the 4 python module files are
the ones that will be marked). To make things simple
for your marker please submit the Globals module
(even if you don't modify it) along with the modules that you write yourself
(this will ensure that this module will be automatically included in the
folder/directory where your other program code resides when it's downloaded by
your marker).
Driver module: it must be
implemented in a separate file which is called 'Driver.py'
The starting execution point for the program, contains the start() function
(it's a function since you don't need to define a class in this module).
It will instantiate an instance of the Manager class
and call the appropriate method to run the simulation. There will
likely be very little code in the start function e.g. def start(): aManager = Manager() aManager.runSimulation()
Because this is an Object-Oriented
assignment: in order to get credit for the features listed below (under the
class definitions) the functionality must be implemented as class methods.
No credit will be awarded otherwise e.g. functions are used instead of
methods, or neither functions nor methods are used. Should this unfortunate
situation occur then the student will be awarded minimal marks for other
marking criteria if appropriate (e.g. documentation). The marking
spreadsheet linked in under the heading [marking
and grading] illustrates exactly what grade you should expect if you
ignore this requirement (look especially at the comments in Cell
E49 in the marking sheet)
Manager class: it must be
implemented in a separate file which is called 'Manager.py'
It manages or runs the simulation. Tasks that must be implemented by this
class include but are not limited to:
Feature 1:
prompting for the number of turns to run the simulation.
Feature 2: The prompt
for the proportion of high, medium and low attacks. They
must be implemented by a method that is recursively called.
Each of the three proportions for the height of the attack is an integer
value from 1-100 and the sum of the three proportions must equal 100. If
these conditions (3 integers in that are not only the correct range but
also sum to 100) have not been met then the program will keep prompting
for the attack proportions. If you don't implement recursion properly
then you can still get credit for the rest of the program but you
will only be awarded half credit for Feature #2. Also to be
awarded full credit your program will use exceptions (or a string method) to
recover (i.e. not crash with a run time error) if the user enters non-integer values
for the proportions (otherwise you will be awarded 75% credit even if recursion is employed).
Program design
Feature 3: running the simulation for the specified number of turns (main program loop).
Feature 4: during each turn getting the attacker to attack and the defender to generate a defense.
Feature 5: determine the result of the attack-defense and generate the appropriate per-turn report.
Feature 6: at the end of the simulation the manager will generate the appropriate end-of-simulation report and the very end write the end-of-simulation report to a file.
Each task will be implemented as one or more methods. This class will likely be one of the larger ones for this simulation. However, the code for this module (like the other modules) must still conform to good style conventions you have been taught during the term e.g. the principles of good design for functions applies to methods: implement one well defined task and not exceed one screen length, do not use global variables (constants are okay) except for debugging flags etc. To fulfill style requirements this class should consist of at least 3 methods (including the constructor).
The minimum attributes for this class should include:
an Attacker object,
a Defender object
Attacker class: it must be implemented in a separate file which is called 'Attacker.py'
This class is responsible for generating an attack based on the [probabilities provided by the user]. The minimum attributes for this class should include (you will likely have many more):
The probability of low attacks occurring,
the probability of medium attacks occurring,
the probability of high attacks occurring,
a tally of the number of low attacks that occurred during the simulation,
a tally of the number of medium attacks that occurred during the simulation,
a tally of the number of high attacks that occurred during the simulation.
To fulfill style requirements this class should consist of at least 2 methods (including the constructor). The methods used in these tallies cannot be token implementations that perform no real task (e.g. declare a few identifiers).
Defender class: it must be implemented in a separate file which is called 'Defender.py'
This class is responsible for generating a defense. For a basic defender it's based on roughly equal values. The probabilities of the defense types of an [intelligent defender] will adapt to the pattern of attacks. The minimum attributes for this class should include (you will likely have many more):
the probability of low defenses occurring,
the probability of medium defenses occurring,
the probability of high defenses occurring,
a tally of the number of low defenses that occurred during the simulation,
a tally of the number of medium defenses that occurred during the simulation,
a tally of the number of high defenses that occurred during the simulation,
the result of the attack-defense combination (important: it's mandatory to be here and not the Manager class because an intelligent defender needs this information).
To fulfill style requirements the basic Defender should consist of at least 2 methods (including the constructor). The intelligent Defender should consist of at least 3 methods. The methods used in these tallies cannot be token implementations that perform no real task (e.g. declare a few identifiers). Since the information for the attacks and defense combination must be tracked by this class the methods for displaying the round-by-round report and writing to a file the end of simulation report need to be implemented here.
Note: your program needs to be designed such the information about hit-miss tallies and the method for displaying the reports is part of the Defender class even if you have no intention of implementing the intelligent defender.
Intelligent defender (Bonus feature: may allow students a grade point higher than 4.0 up to a maximum of 4.3. Conversely implementing all features except for this one but with no style & documentation issues may allow for a maximum grade point of 4.0)
The default non-intelligent defender will only generate defence with roughly equal values. A program that implements an 'intelligent' defender will analyze the pattern of attacks for ten turns and adjust the probability of each type of defence being employed from turn eleven onward. (For example if the attacker always throws high attacks then the defender will eventually extrapolate the pattern and use high defences more frequently).
In order to 'prime' the simulation the defender will generate defences with an equal chance of each defence type the first ten turns of the simulation. From turn eleven onwards, defender adjusts to the pattern of attacks. Because an intelligent defender will run as a regular defender for the first 10 turns there is no need to explicitly implement the non-intelligent defender if you choose to implement an intelligent one.
Exactly what constitutes 'intelligent' for this assignment? Because this isn't a formal class in Artificial Intelligence the definition is fairly broad: as long the program demonstrates the ability to somehow adapt to the pattern of attackers and the marker can clearly see the pattern as the program executes (the display of statistics each round will be very useful for communicating this). If, for instance, the attacker throws only medium attacks, after the learning period is over the defender should eventually employ only medium height defences (or at least have an extremely high probability of employing this type of defence).
You can either come up with your own algorithm for the defender or you can freely research algorithms online. In the latter case make sure you clearly cite all your sources. (Failing to list a source may be regarded as academic misconduct).
As in the case with the rest of your program it is imperative that you have an output for an intelligent defender that matches the results show in my [output report].
To help you visualize how instances of the 3 classes call each other methods as well as what information needs to be passed to an object here is a [PDF file overview].
exit()', 'quit()' functions anywhere in the program.General programming style requirements (-0.1 penalty for each violation of a category, for this assignment there is no maximum cap on the number of style penalties that may be applied (8 categories of penalties means a penalty of -0.8 will be applied)
- #1: Naming conventions: You should employ good naming conventions for identifiers (variables, constants and even the name of the files containing the program) as covered in the "Intro to programming" section of the course.
- #2: Named constants should be used as appropriate (and if they aren't a penalty will be incurred).
Yes do it this way! No. Not this way! LEFT = 0
RIGHT = 1
CENTER = 2
if (silverLockPosition == RIGHT):if (silverLockPosition == 0): #What does 0 stand for???
- #3: The program code should have appropriate white space (specified in the "Intro to programming lecture') and alignment (specified throughout the lecture notes).
- #4: Code is self documenting e.g. Clear expressions (e.g. mathematical, Boolean). Expressions should be clear and simple (break up or restructure complex expressions). Good variable names and the use of named constants are examples of writing self documenting code but specifying clear expressions is important enough to be included in a separate category.
- #5: The program should not employ abnormal termination mechanisms e.g. something such as a 'break' instruction for loops or calls to the '
Method and function specific style requirements (principles of good design for functions) -0.2 penalty will be applied for each of the 3 function specific style requirements that have been violated.
- #1: Functions/methods are one screen in length (normal screen 40 lines max of code (the count excludes whitespace and documentation).
- #2 Functions/methods implement one well defined task (e.g. processLivingRoomCommands vs. processlivingRoomRunIntroductionRunConclusion).
- #3: Code in one function/method is not duplicated in another function (not in the notes but this is just common sense that you don't write two functions where there's overlapping code - the overlap should likely be taken out of both functions and moved to another separate function).
- Violating any of the function/method specific style requirements will result in a -0.2 penalty for a violation in each of the 3 categories. E.g. a program that includes a function that exceeds the maximum length and implements two or more tasks would incur a -0.4 penalty.
Documentation requirements:
Header documentation: This should be specified in the header of the program (very top of each file/module at Python documentation). The basics of documentation were covered in the "Intro to programming" section of the course. Later lectures may specify additional information that needs to be provided in the documentation.
- Identifying information: All assignments should include contact information (full name, student ID number and tutorial section [Here's a link if you don't know how to find this information]) at the very top of your program.
- Program version. (version date or version number).
Under the version you should specify which assignment features were implemented in that version as specified in the "Intro to programming section"
- Any program limitations or weaknesses.
New documentation requirement starting with A2 and applies to all successive assignments: Just before the header definition of the function: list the features of the assignment (e.g. checking list bounds, displaying the list etc.) that were implemented in a particular method/function, the return type(s) as well as the type(s) of the arguments. Greater details are provided in the functional decomposition lectures.
Program functionality (implementing working program features)
Test your program: Because the assignment description (along with required features) is posted ahead of time if you test your program thoroughly before submitting the final version then you should get a pretty clear idea of "how you will do". Also because the marking key will be posted under the ["Marking and grading section"] of this assignment. if you test your program thoroughly before submitting the final version then you should get a pretty clear idea of "how you will do".
Style and documentation (non-functional assignment requirements)
- Style and documentation requirements were introduced early in the semester in the [last part of the "Intro to programming"] section of the course. Additional requirements may be added as new sections are covered (e.g. documenting functions that you write your yourself). Each assignment will specify these requirements specific under the [non -functional assignment requirements (style and documentation)] to that graded component. Again you should refer to the [marking key] in order to determine how style and documentation will affect grading for a particular assignment.
Assignments must reflect individual work; group work is not allowed in this class nor can you copy the work of others. Some "do nots" for your solution: don't publically post it, don't email it out, don't show it to other students or even verbally discuss solutions to any graded work (i.e. you can't do this in an exam so you can't do this for assignments). And unless otherwise told you should not use program code for other sources (which include but aren't limited to: tutors, artificial intelligence programs such as ChatGPT). For more detailed information as to what constitutes academic misconduct (i.e., cheating) for this course please read the following [link].
You are to submit your assignment using D2L [help link]. Make sure that you [check the contents of your submitted files] (e.g., is the file okay or was it corrupted, is it the correct version etc.). It's your responsibility to do this! (Make sure that you submit your assignment with enough time before it comes due for you to do a check). If don't check and there were problems with the submission then you should not expect that you can "learn your lesson" and simply resubmit. Whatever you submitted into D2L by the final due date is what will be marked.
|
Submission received: |
On time |
Hours late : >0 and <=24 |
Hours late: >24 and <=48 |
Hours late: >48 and <=72 |
Hours late: >72 and <=96 |
Hours late: >96 |
|
Penalty: |
None |
-1 GPA |
-2 GPA |
-3 GPA |
-4 GPA |
No credit (not accepted) |
Unless otherwise told you are to write the code yourself and not use any pre-created functions (or methods). For most assignments the usual acceptable functions include: print(), input() and the 'conversion' functions such as int(), float(), str(),
len(). In addition you use functions or methods with text formatting capabilities such as 'format()', the 'write()' method of the 'sys' library module or the methods of the 'random' library module. You can use any method that you wish (e.g. using format specifiers or the 'format' method) to set the precision for the output. String methods and operators that you have been taught can also be freely used. Look at the particular assignment description for a list of other functions/methods that you are allowed to use and still get credit in an assignment submission. If it's not listed then you should assume that you won't be able use the function and still be awarded credit.1 In case you don't understand what the term 'proportion' means