Note: the word "produce" is used here as a noun, not a verb. So, plants generate produce… fresh produce. 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 "produce" 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 produce the plants generate, but if you don't get enough rain, a random plant will die. When you have enough produce, you can spend some to buy new plants. To increase biodiversity, you can't buy plants you already have. The program starts with a welcome, some instructions and four plants. Then there's a repeating menu with the following four options: • (W)ait o This simulates a day starting with rainfall between 0 and 100mm (think about constants). If you get less than 30mm (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 produce according to the formula: (random percentage between 1/2 rainfall and actual rainfall) * length e.g. if rainfall is 70, a "Sage" plant (4 characters) would generate produce between 0.35 and 0.7 * 4 = between 1.4 and 2.8 as an integer so 1 to 2 • (D)isplay plants o This simply displays the plants in your garden. • (A)dd new plant o You can only add plants if you have at least 10 produce. You can have infinite plants. New plant names must be between 1 and 10 characters (including spaces). When you input a plant, the name is 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. When you add a plant, the name length is deducted from your produce. • (Q)uit o 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 produce. The sample output below will help you understand these details. There is also a video demonstration available. 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. CP1401/CP1801/CP5639 Assignment 1 © Information Technology @ James Cook University 2/8 Coding Requirements and Suggestions: • 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. • 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 for how to properly write docstrings. o Use # block comments for things that might reasonably need a comment. Do not include unnecessary or many comments as these are 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 plants is done the same way in multiple places o adding a plant is a significant section o getting a plant name looks very similar to the kind of thing we wrote functions for in the teaching (getting a valid string) o simulating a day is a nice-sized section for its own function 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 plant names that aren't plants. It's fine to have a "1401 Rocks" or "Monty" plant. • 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 plants differently, or fix the "1 plants" output to be "1 plant", 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