Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due
CP1401/CP5639 Assignment 2
Task - Risky Business:
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; Random numbers; Lists; Files
The assignment also includes a Developer's Journal – a document you complete as you plan and code your program to help you focus on and improve your process and become a better developer.
Incredibly Important: This assignment must not be where you first learn about these topics. The subject is designed to systematically teach you these principles through the lectures (first), then the practicals. You should have practised each programming concept/construct many times before you start using it in your assignment. If you get to a point in your assignment where you're not sure about something, go back and learn from the subject teaching (not from the Internet). Remember:
100% of what you need to know to complete this assignment is taught in the subject.
Problem Description:
Risky Business 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 and a main menu with the following options:
• (P)lay
o Pressing P (or p) plays a turn of the game where you can choose an amount to risk up to 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: https://github.com/CP1404/Starter/wiki/Programming-Patterns#error-checking
You may also remember that we have written useful functions for getting valid inputs before, e.g., https://github.com/CP1401/Practicals/tree/master/prac_06#example
So … follow what you've been taught and feel confident that you're on the right track!
• (I)nstructions
o This prints the instructions for the program. Notice that the instructions reference 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.
• (D)isplay report
o This displays a report of all the results from the game so far, unless there are no results
yet. Use a list to store the results of each turn. Notice how the dollar values are formatted and line up neatly. Only store each result in the list. Do not store anything else like the balance, just the result.
• (S)how statistics
o This displays statistics about the turns as in the sample output: minimum, maximum, and win/loss percentages, unless there are no results yet.
• (Q)uit
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: https://github.com/CP1404/Starter/wiki/Programming-Patterns#menus
o When the user quits, they are presented with a summary including the standard report. They are then offered the choice of saving their results to the file results.txt. If they don’t say no, the values in the results list are written to the file, one value per line.
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 Expectations:
1. 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:
https://github.com/CP1404/Starter/wiki/Programming-Patterns#constants
a. A 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 crazy reward … and the instructions should correctly show this value.
2. You are expected to include two kinds of useful comments in each of your program:
a. Every function should have a """docstring""".
b. Use # block comments for things that might reasonably need a comment.
Do not include unnecessary comments as these are just "noise" and make your program harder to read. See the subject teaching for how to properly write good comments:
https://github.com/CP1404/Starter/wiki/Styles-and-Conventions#commenting
3. Error checking should follow our standard pattern:
https://github.com/CP1404/Starter/wiki/Programming-Patterns#error-checking
4. Follow what you’ve been taught about how to write menus, and know that (Q) should not be a separate option within the menu:https://github.com/CP1404/Starter/wiki/Programming-Patterns#menus
5. 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. Do not use global variables. Any use of global variables will result in a maximum mark of 1/10 for the functions criterion. Here are some possibilities for functions:
a. displaying the report is done the same way in multiple places
b. playing a turn is a significant section
c. getting a valid risk amount and risk option could each be functions
d. displaying the instructions is large enough that turning this into a function makes the main function easier to read
e. saving to a file contains low-level detail that should be abstracted away into a function
The main menu and one-off program behaviour (like the start and end) should all be part of the main function – like in our examples and teaching.
6. Sample output from the program is provided. Follow this to meet requirements.
7. The way computers work with floating point numbers means that your results may end up with problematic precisions, so round your results and balance to 2 decimal places when needed:
balance = round(balance, 2)
We strongly suggest you work incrementally on this task: focus on completing small parts rather than trying to get everything working at once. This is called "iterative development" and is a common way of working, even for 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 standard pattern. For each menu item, just print something (like " … play …").
3. Choose one function/section 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 more complex section, 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 whathappens the user is successful with a crazy 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 times to hopefully get the random scenario you want to test.
7. The file saving can be done last as it is optional for the user.
Journal:
A significant desired outcome for this subject is you learning to develop solutions to problems systematically and thoughtfully. That is, we are not only interested in the final product but in your process and the lessons you have learned through your experience. To encourage you in learning the systematic problem-solving process, you will record your work experiences and insights in a simple journal for this assignment.
Use the template file you have been provided with.
There are three parts to your journal:
1. Assignment 1 Reflections and Lessons
2. Work Entries
3. Summary
Assignment 1 Reflections and Lessons:
Before you begin working on this assignment, take some time to reflect on what you learned about your process through assignment 1, including how you will make changes this time based on any feedback you received. You could consider your previous reflection exercise from the practicals:
https://github.com/CP1401/Practicals/tree/master/prac_07#reflection
Work Entries:
Each time you work on the assignment, record an entry in your journal that includes:
• Date and time you worked, including duration
• What you worked on with simple details, enough that someone reading it would understand
• Any difficulties you faced and how you overcame them
Please do not include multiple entries for short work sessions. If you did 7 minutes, took a break then came back and did 37.5 minutes … we don't need this level of detail – just include a single entry of about 45 minutes. The entry detail can be quite short, but make sure your focus is on your process, not your actual code/work.
Summary:
Summarise the lessons you learned about the problem-solving process (not about Python code) through doing this assignment. This is the most important part – where you reflect on your process and show what you have learned. Did anything you considered or changed based on assignment 1 reflection prove important or useful? How are you improving in terms of following a systematic development process? What would you differently next time?
Please note that the only reasonable way to write a journal is regularly, as you develop your solution. A journal that is completed at the end of the assignment after you've finished everything is not a journal and will not aid your learning experience as much.
You are not allowed to use GenAI (like ChatGPT, Copilot, etc.) for this assignment at all. Please understand that journal writing done by AI is usually very obviously written by AI as it is far too general, saying unfounded things like, “I have learned the value of breaking a larger problem into smaller parts”. We will give very low marks to journals that are not specific and personal, whether we think they are written by AI or not. So, be clear, specific, personal, and use examples.
Here is a sample journal entry that shows a 'satisfactory' level:
25/07/2025, 8:30 - 9:30am
Work: Wrote pseudocode for main function; nearly completed start and menu section.
Challenges: It took a while to remember how to deal with lists and functions in pseudocode. I checked the "Pseudocode Guide" and followed the examples, which helped.
I am so grateful for the excellent guides and high-quality teaching in this subject :)