Reference no: EM132663130

CP1401 Fundamentals of Problem Solving and Programming - James Cook University

Task - Run the Risk!

For this assessment, you are to plan and then code a medium-sized console-based program in Python 3. This assignment is designed to help you build skills using:
• As in assignment 1: Input, Processing and Output; Decision structures; Repetition structures
• New in assignment 2: Functions and random numbers; Lists

Problem Description:

Run the Risk is a game that's totally not about gambling... but rather about risking digital "cash" to win or lose based on random chance.
The program starts with a welcome, some instructions and $1000. Then there's a repeating menu with the following options:
• (P)lay
o Pressing P (or p) plays a turn of the game where you can choose an amount of cash to risk between 0 and your current balance. You can then choose from 3 risk-reward levels, as shown in the sample output below. Notice the error checking looping on both the risk amount and the risk option. Notice also that we have explicitly taught how to handle errors like this using the error checking pattern:

Instructions
o This prints the instructions for the program. Notice that the instructions references values like the percentages for chance and reward, and remember that we've taught you about using CONSTANTS in places where values appear more than once - like in print statements and in calculations.
• Display report
o This displays a report of all the results from the game so far (unless there are no results yet). You will need to use a list to store the results of each turn. Notice how the dollar values are formatted and line up neatly.
• Show statistics*
o *This option is a challenge and will be marked as a separate criterion. Please do it only after completing the rest of the program. This displays statistics about the turns, including, but not limited to, those in the sample output: minimum, maximum, percentages, and the results in sorted order. Notice that the normal report maintains its chronological sorting.
• Quit
o Choosing this option will end the main menu and then display the report again. Notice that you have been taught how to write menus and you know that (Q) should not be a separate option within the menu, but rather the quit condition with final actions coded outside the main menu loop.

The sample output below will help you understand the requirements in detail. Make sure you understand how the program should work (that's the "analysis" step in program development) before you plan it ("design" step), then code it ("implementation"). Don't forget to test your program thoroughly, comparing it to these requirements.

Coding Requirements and Suggestions:
• Make use of named constants as appropriate, e.g. for things that would otherwise be "magic numbers", like the chance and reward percentages. Remember the guidelines for constants: if you use a value more than once, it should probably be a constant, and if you have a constant then you must use it in all places that you reference that value.
o A very good way to test that you have used constants properly is that you should be able to change ONE value in ONE place to make the game have a 99% chance of getting the silly reward... and the instructions should correctly show this. That's what constants are for.
• You are expected to include two kinds of useful comments in each of your program:
o Every function should have a """docstring""". See the subject teaching (checkpoint
2) for how to properly write docstrings.
o Use # block comments for things that might reasonably need a comment. It is not acceptable to have zero block comments.
Do not include unnecessary or many comments as these are usually just "noise" and make your program harder to read.
• Functions should be used for sections of the program and repeated tasks as you have been taught. Follow the DRY (Don't Repeat Yourself) principle and consider turning repeated code into functions. Here are some possibilities for functions:
o displaying the report is done the same way in multiple places
o playing a turn is a significant section
o displaying the instructions might only be one print statement, but it's quite large, so turning this into a function makes the main function easier to read
o the main menu and one-off program behaviour (like the start and end) should all be part of the main function - again, like our examples and teaching
• You do not need to handle incorrect types, like the user entering "money!" as their risk value. Another issue you do not need to handle is near-zero amounts - values less than $0.01. For this assignment, you can just pretend that all values will be in whole cents.
• Sample output from the program is provided. You should ensure that your program mostly matches this and definitely does in terms of meeting the requirements. But you are allowed to be a bit creative and customise the interface as you wish. So, please understand - you can change small details that don't break the requirements, but if you change it substantially you may miss some of the required aspects and lose marks. E.g. you could display the gain/loss messages differently, or express your creativity in the instructions, but you could not change menu options and you could not choose to allow negative risk amounts. Please ask if you are unsure.

We suggest you work incrementally on these tasks: focus on completing small parts rather than trying to get everything working at once. This is called "iterative development" and is a very common way of working, even for the professionals. A suggested approach to this is described below.

1. Start with planning and pseudocode - this is important for your process as well as your journal (see below for details about recording your process in your journal).

2. Start coding with the main function and creating a working menu using the pattern you've been taught. For each menu item, just print something (like "... play...") as a placeholder.

3. Choose one function at a time to implement. E.g. start with the function to play a turn and get this working, then call the function from your main menu.

4. When you do a larger section that's a bit more complex, keep it simple first, then add complexity. E.g. when getting a risk amount, ignore the error-checking to start with. Get it working properly, then add error-checking.

5. When writing the function to play a turn, start with just generating and displaying a random number between 1 and 100... but notice this is never printed... so print it as a helpful debugging output until your function is working correctly, then remove the print statement.

6. When writing and testing code with randomness, you can encourage it towards what you want to test by modifying your constants or starting values. E.g. when you want to test what happens the user is successful with a (s)illy risk, change the constant from 5 to 99 to make sure they get it. Then change it back. Don't waste time running your program many many times to hopefully get the random scenario you want to test.

This is not an exhaustive list of thoughtful ways to iteratively develop the program. Hopefully you've paid attention to the examples and teaching to see how we develop programs step by step and you have learned and practised this approach.

Attachment:- SP2 Assignment.rar