CP1401/CP5639 Assignment 2 Task – Market Garden Simulator
Problem Description:
The Market Garden Simulator is a program that simulates the tranquil and refreshing activity of growing your own garden for fun and profit. You have a list of plants, which each generate “food” according to their name length (as everyone knows, longer plant names mean higher profit at market… but they cost more to buy). Each day when you wait and watch, it rains a random amount.
This rainfall determines how much food the plants generate, but if you don’t get enough rain, a random plant will die. When you have enough food, you can buy new plants. To increase the biodiversity of your garden, you can’t buy plants you already have.
The program starts with a welcome, some instructions and initial plants. You can choose to either load existing plants from a text file or start with four standard plants (see output). Notice the form of the prompt for this and saving plants at the end: “Y/n” means that Yes is the default. Anything other than N or n should be interpreted as a Yes.
Then there’s a menu with the following four options (read the sample output for more detail):
(W)ait
This simulates a day starting with rainfall between 0 and 128 mm (think about constants). If you get less than 32 mm (did someone say think about constants?) then a random plant from your list will die (and be deleted from the list). Each plant generates an amount of food according to the formula (same percentage for each plant per day):
percent = random value between 1/3 rainfall and actual rainfall / 128
food produced = percent * length of plant e.g., if rainfall is 90, then generate a random value between 30 and 90; let’s say it’s 42. This divided by maximum (128) is 0.328. This number would then multiply the length of each plant,so “Sage” plant (4 characters) would produce a result of 1.312 (0.328 * 4), as an integer so 1,and “Thai Basil” (10 characters) would produce 3.
(D)isplay plants
This simply displays the plants in your garden.
(A)dd new plant
You can only add plants you can afford. You can have an infinite number of plants.
New plant names cannot be blank; error-check these (see expectations below).
Plant names should be converted to title case (using Python’s .title() string method), so if the user enters “thai BAsIL”, it will become “Thai Basil”.
If you already have the plant in your list, then you will be asked for the name again.
You do not need to handle plant names that aren’t plants. Any non-empty name is OK.
When you add a plant, its name length is deducted from your total food.
(Q)uit
This will end the main menu and show the final details including the plants, the number of days simulated, the number of plants and the amount of food.
You will then be prompted to save the plants, one per line, to a file.
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:
Make use of named constants as appropriate, e.g., for things that would otherwise be “magic numbers”, like the maximum rainfall or low rainfall threshold for plant death. Remember the guidelines for constants: https://github.com/CP1404/Starter/wiki/Programming-Patterns#constants
a.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 low rain threshold 20 mm… and the instructions should correctly show this. That’s what constants are for.
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.
c.Do not include unnecessary or many 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
Error checking should follow our standard pattern:
https://github.com/CP1404/Starter/wiki/Programming-Patterns#error-checking
You may also notice 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! ?
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
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 fail mark for the functions category. Here are some possibilities for functions:
a.displaying the plants is done the same way in multiple places
b.adding a plant is a significant section
c.getting a plant name looks very similar to the kind of thing we wrote functions for in the teaching (getting a valid string)
d.simulating a day is a nice-sized section for its own function
e.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
Sample output from the program is provided. Follow this to meet requirements, but you are
allowed to be a 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 plants
differently, or use different output text when a plant dies, but you could not add or remove a
menu option and you couldn’t choose to not have plants die. Please ask if you are unsure.
a.The sample output shows “1 plants”. This is fine, but you are welcome to add the logic to make this “1 plant”.
b.There’s a comma at the end of the plants display. This is also fine. You don’t need to change it – but you can if you want to.
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:
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).
Start coding with the main function and creating a working menu using the standard pattern.
For each menu item, just print something (like “… add plant…”).
Choose one function/section at a time to implement. E.g., start with the function to display plants and get this working, then call the function from your main menu.
When you do a more complex section, keep it simple first, then add complexity. E.g., when adding a plant, ignore the error-checking to start with. Get it working properly, then add errorchecking.
When writing the function to simulate a day, start with just generating and displaying random rainfall, then add the calculation to determine plant food… but notice the random number or percentage are never printed… so print these as helpful debugging outputs until your function is working correctly, then remove the print statements.
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 when it doesn’t rain much, change the maximum rainfall to a low number temporarily (that’s how we created the 2nd sample output). Want to test what happens when you run out of plants? Change the starting list to one plant instead of four. Don’t waste time running your program many many many times to hopefully get the random scenario you want to test.
The file saving and loading can be done last as it is optional for the user. Start with the default plants until the program works, then add the file loading.