CSCI 1300 CS1: Starting Computing Fleming, Naidu, Quigley - Fall 2020 Project 3: Oregon Trail OREGON TRAIL For the Final Project you will implement a text based adventure game in C++. The game tries to closely follow the popular “Oregon Trail” game from the 1970s and 80s. Here are the original instructions: THIS PROGRAM SIMULATES A TRIP OVER THE OREGON TRAIL FROM INDEPENDENCE, MISSOURI TO OREGON CITY, OREGON IN 1847. YOUR FAMILY OF FIVE WILL COVER THE 2040 MILE OREGON TRAIL IN 5-6 MONTHS --- IF YOU MAKE IT ALIVE." The goal is to travel from Independence, Missouri to Oregon City (2040 miles) by the end of fall (November 30th, 1847). However, the trail is arduous. Each day costs you food and has risks. You can hunt and rest, but you have to get there before winter! Suggestion: As you start reading through the project description, follow along the video of one of the later versions of the Oregon Trail game from 1985. It will help you understand which tasks you need to accomplish and in which order. https://youtu.be/FfbGEP087HM. The game can be summarized by six core concepts: 1. The player buys supplies before starting the journey to Oregon. 2. There are opportunities to hunt for food along the way. 3. There are opportunities to make purchases at forts along the route. 4. The player must manage the level of supplies to avoid running out. 5. Misfortunes frequently occur. 6. Raiders attacks frequently occur. 7. The game ends when the player (and some of the companions) reach Oregon, when the player dies along the way, or when the player runs out of vital supplies (oxen, food, wagon parts). Initial conditions: ● At the beginning of the game, the player (the leader of the expedition) is asked to enter their name. ● Next, the leader is asked to enter the names of the other four travelling companions ● Team starts in Independence Missouri (mile 0). ● There are 2,040 miles to go until the arrival in Oregon City. ● Team starts with $1600 and a wagon. ● Before the start of the trip, the player can visit the store and buy supplies: food, oxen, bullets and wagon parts. More details on the “Visit the store” activity later. ● Player is given the choice to start on the default start date of 03/28/1847 or to choose a different departure date between 03/01/1847 and 05/01/1847. ○ Present the player with the option to start on the default date ○ If they refuse, ask them to choose their starting month, followed by the starting day ● The player must arrive in Oregon City by November 30th, 1847. Visit the Store: At the beginning of the trip, the player has the opportunity to purchase things they might need on their long journey. Initially, the player is presented with the information about what they might need from the store and why. Below is a modified excerpt from the original game, which you can also find in the file “store_info.txt”. (If you’re following along with the 1985 video, you will notice the store information is presented in a slightly different manner, through the store owner, Matt.) YOU HAD SAVED $1600 TO SPEND FOR THE TRIP, AND YOU HAVE A WAGON. YOU WILL NEED TO SPEND THE REST OF YOUR MONEY ON THE FOLLOWING ITEMS: - OXEN. YOU CAN SPEND $100-$200 ON YOUR TEAM. THE MORE YOU SPEND, THE FASTER YOU'LL GO BECAUSE YOU'LL HAVE BETTER ANIMALS. - FOOD. THE MORE YOU HAVE, THE LESS CHANCE THERE IS OF GETTING SICK. - AMMUNITION. YOU WILL NEED BULLETS FOR ATTACKS BY ANIMALS AND BANDITS, AND FOR HUNTING FOOD. - MISCELLANEOUS SUPPLIES. THIS INCLUDES MEDICINE AND OTHER THINGS YOU WILL NEED FOR SICKNESS AND EMERGENCY REPAIRS. YOU CAN SPEND ALL YOUR MONEY BEFORE YOU START YOUR TRIP, OR YOU CAN SAVE SOME OF YOUR CASH TO SPEND AT FORTS ALONG THE WAY WHEN YOU RUN LOW. HOWEVER, ITEMS COST MORE AT THE FORTS. YOU CAN ALSO GO HUNTING ALONG THE WAY TO GET MORE FOOD. Present the player with the information about possible store purchases. You can use some of the text in the fragment above or you can modify it to include more information or to look more like the 1985 version from the video. Then, ask the player if they wish to purchase things in the following 4 categories: 1. Oxen: a. The player must spend between $100 and $200 dollars on oxen, inclusive. b. There are 2 oxen in a yoke and the price of each yoke is $40. (The player must purchase between 3 and 5 yokes of oxen; see above). Present the oxen price information to the player and ask how many yokes they wish to purchase. c. After the purchase is in the satisfactory range, print out the current bill so far. 2. Food: a. The store owner recommends the player(s) should purchase at least 200 lbs. of food per person, at 50 cents per pound. b. Ask the player how many pounds of food they wish to purchase. c. Compute and print the current bill so far. 3. Bullets: a. A box of 20 bullets costs $2. You will need the bullets for hunting along the way. b. Ask the player how many boxes they wish to purchase. c. Compute and print the current bill so far. 4. Miscellaneous Supplies: a. A wagon part (wheels, axles, tongues) costs $20. If the wagon breaks along the way, any wagon parts will be used to fix it. b. Ask the player how many parts they wish to purchase. c. A medical aid kit costs $25. d. Ask the player how many kits they wish to purchase. e. Compute and print the current bill so far. Note 1: At any time in the buying process, if the player is attempting to buy an item (or a number of items of the same kind) whose price exceeds the total cash the player has in hand, print a message to the player informing them they do not have enough money and ask them to choose another quantity of the item in question. Note 2: The player can choose to purchase items in a certain category multiple times during the same store visit. For example, the player might choose the purchase of oxen, followed by food, then oxen again, then more food, then bullets but no medical supplies or wagon parts. After every new set of items added, your program should print the bill so far. Other stores will be available along the trail, at the forts along the way. The player will be given the opportunity to visit these stores and replenish their supplies. The prices at the stores along the trail get progressively higher as you get further along. At the first store, the prices will be 25% higher that the ones at the store in Independence, Missouri. At the second store, they will be 50% higher, at the third store 75% higher, and so on. Taking turns: ● In general, each turn represents 2 weeks of time. You typically travel between 70 and 140 miles each turn. If the player chooses to rest or hunt, the turn will not take 2 weeks. The entire trip could take 20 turns or more. ● At the beginning of each turn (and also before the start of the trip), your program needs to display a Status Update. Here are the categories you need to display: ○ Current date (mm-dd-yyyy) ○ Miles traveled (in miles from the start of the trip) ○ Distance until the next milestone (in miles) ○ Food available (in lbs.) ○ Number of Bullets available ○ Cash available (in $) Note: A screenshot of the Status Update, as it appeared on the original Oregon Trail Game, is supplied with the project files (status_update.pdf). Use it as guidelines; please note that some of the items listed in the file do not apply to our project. Each turn, the player is asked to choose between the following actions: 1. Stop to rest: a. Resting takes between 1 and 3 days. Note: a turn where the player chooses to rest does not take 2 weeks. b. The resting party consumes 3 lbs. of food, per person, per day 2. Continue on the trail: a. A turn where the player chooses to continue on the trail takes 2 weeks b. The travelling party consumes 3 lbs of food, per person, per day c. You typically travel between 70 and 140 miles per turn. 3. Hunt: a. Hunting takes 1 day. Note: a turn where the player chooses to hunt does not take 2 weeks. b. The player could encounter a rabbit, a fox, a deer, a bear or a moose, with the following probabilities: ● rabbit: 50% ● fox: 25% ● deer: 15% ● bear: 7% ● moose: 5% c. Figure out, in order, if the player has encountered each of the animals specified above (this means the player could encounter no animal, just one animal, ..., or they could encounter all 5 animals on the hunting trip) d. Present the player with the hunting opportunity, specifying which animal they have encountered. Ask the player if they want to hunt or not. YOU GOT LUCKY! YOU ENCOUNTERED A DEER! DO YOU WANT TO HUNT: (1) YES, (2) NO e. If the player chooses to hunt, but they have less than 10 bullets left, then the hunt is unsuccessful. f. If the player chooses to hunt and they have more than 10 bullets left, they must solve a puzzle (see the puzzle section later in the project description) g. If the travelling party has a successful hunt, they will improve their total food as follows: ● rabbit: 5 lbs. ● fox: 10 lbs. ● deer: 60 lbs. ● bear: 200 lbs. ● moose: 500 lbs. h. If the travelling party has a successful hunt, they will lose some of their ammunition, as follows: ● rabbit: 10 bullets ● fox: 8 bullets. ● deer: 5 bullets. ● bear: 10 bullets. ● moose: 12 bullets. i. At the end of the hunting day, the player is asked how well they want to eat. Note: this choice only happens at the end of the day when the player chooses to hunt: ● Poorly: 2 lbs of food, per person ● Moderately: 3 lbs of food, per person ● Well: 5 lbs of food, per person j. After they finished eating, you can compute the total lbs. of food the travelling party has acquired through hunting. Even with a wildly successful hunting day, the wagon cannot hold more than 1000 lbs. of food. If the total food exceeds 1000 lbs., cut the food at 1000 lbs. and print a message explaining they had to leave the rest of the food behind. 4. Quit: If the player chooses to quit, the game ends. Print a message expressing regret the travelling party had to cut their trip short. Note: As the players advance in their travels, the date changes. You will need to keep count of months that have 30 days, vs 31 days. Our suggestion: you might want to create a class to handle the date (day-month-year). Misfortunes: There is more to the game than resting, travelling and hunting. At every turn in the game, after the player chooses and completes one activity (resting, travelling, hunting), there is a 40% probability a misfortunate event might occur. Included below are the flow charts from the original Oregon Trail game. We will attempt to implement a pretty close version in this project. If a misfortune occurs at the end of a particular turn, choose one misfortune, at random, between the following options: 1. One member of the travelling party (at random) gets sick. The possible diseases are: typhoid, cholera, diarrhea, measles, dysentery (of course), and fever. Print a message announcing the misfortune: OH NO! JANE HAS THE MEASLES! ● If the travelling party has a medical aid kit, the kit will be used, but the sick player still has a 50% chance of dying. ● If the party does not have a medical aid kit, they can choose to “Rest” or “Press On!” ● If the player chooses to “Rest”, the party must rest for 3 days, but the sick player still has a 30% chance of dying. ● If the player chooses to “Press On!”, the sick player has a 70% chance of dying. ● If the leader of the travelling party dies, the game ends. YOU DIED OF DYSENTERY! 2. One of the oxen dies. Print a message announcing the misfortune: OH NO! ONE OF THE OXEN HAS DIED! YOU HAVE ... OXEN LEFT. ● The travelling party will become unable to continue their journey if all their oxen die 3. One of the wagon wheels/axles/tongues breaks. Print a message announcing the misfortune: OH NO! ONE OF YOUR WHEELS IS BROKEN! ● If the player has spare wagon parts, one will be used to fix the wagon. The number of spare Parts goes down by 1. ● If the player does not have spare wagon parts, the travelling party will become unable to continue their journey Note: If you want to implement “positive events” you are free to include those as well. For example: “The family discovered a lost pirate treasure chest. Your cash reserves increase by $1000”. Raider Attack: No two trips to Oregon were exactly the same. Players came into contact with people they didn’t know on the trail. It was more likely that you would meet with strangers at the beginning of the trip instead of the end because you a) weren’t so far from civilization so people could rob you and get back, and b) the geography was more flat and easy to survive than in the mountains. At the end of every turn, and after some unfortunate event might occur, there is a probability the player will be attacked by raiders. The original formula used to calculate the probability of being attacked by raiders was based on mileage traveled, M: Probability of meeting raiders = 0.10 −1 ((M /100 −4) +12)2 ((M /100 −4) +72)2 For values of M between 0 and 2040 miles, the result of the computation above will be roughly between the values of 5 and 50. Use this value for the probability of meeting raiders. If, using the probability calculated using the formula above, the riders attack occurs, print a message announcing the event: RIDERS AHEAD! THEY LOOK HOSTILE! The player will then be given three choices: 1. Run: ● The travelling party escapes with their lives but, in the hurry to flee the raiders, they leave behind 1 ox, 10 lbs. of food and 1 wagon part. 2. Attack: ● In order to win the battle, the player must pass a puzzle (see the puzzle section later in the project description). ● If they win the battle, the travelling party gains 50 lbs. of food and 50 bullets. ● If they lose the battle, the travelling party loses a quarter of their cash reserves and 50 bullets. 3. Surrender: ● The travelling party loses a quarter of their cash reserves. Puzzles: The player has to pass a puzzle in order to win the hunt, or in order to fight off the raiders. Every time a puzzle is required, the program must generate a random number between 1 and 10. The player has 3 tries to guess the number. If the player guesses correctly, they solve the puzzle. Note: feel free to come up with other puzzles for the player to solve. Consider the puzzle above an example. You can ask the player to solve a riddle, guess a number, solve a system of equations .. it’s your choice. Make it fun! Milestones: All the milestones are written in a file “milestones.txt”. Here is the content of the file: Kansas River Crossing 102mi Big Blue River Crossing 185mi Fort Kearney 304mi Chimney Rock 554mi Fort Laramie 640mi Independence Rock 830mi South Pass 932mi Fort Bridger 989mi Green River Crossing 1151mi Soda Springs 1295mi Fort Hall 1395mi Snake River Crossing 1534mi Fort Boise 1648mi Blue Mountains 1808mi Fort Walla Walla 1863mi Important considerations: 1. Some milestones are forts, some are river crossings and some are landmarks along the way. 2. As the player randomly generates the length traveled in a 2-week cycle, compare the total mileage with the mileposts of the next milestone. If the total travel would exceed the next milestone, adjust the traveled distance down in order to stop at the next milestone. Example: MILES TRAVELED: 0 NEXT MILESTONE: 102mi ... YOU WERE PREPARED TO TRAVEL 120 MILES BUT YOU ARRIVED AT THE KANSAS RIVER CROSSING. WHAT DO YOU WANT TO DO: (1) REST, (2) CONTINUE 2 MILES TRAVELED: 102 NEXT MILESTONE: 83mi ... ... 3. If the landmark is a fort, the player can choose to rest (repeatedly), visit the store (repeatedly), or continue the journey. 4. The last milestone is Oregon City, 2040 miles from the beginning and 177 miles from Fort Walla Walla. Game end: The player wins the game when the party (not necessarily all the members) reaches the destination before the deadline. The player loses the game when: - The party runs out of food. - The party has lost all the oxen. - The party has a broken wagon and has no wagon parts left - The first player (the leader) dies. Note: If other family members die, the leader can still push ahead, reach the destination and win the game. If the game ends, your program should print a message informing of the tragic event. YOU HAVE DIED OF DYSENTERY! , along with the following: leader name, miles travelled, food remaining, cash remaining. Note: the final stats of the game should also be saved in a file named results.txt Minimum Requirements: Your implementation of the Oregon Trail should have: ● 4+ user defined classes ● At least two classes with 4+ data members. ○ At least one class must include an array of objects from a class that you created. ● Appropriate methods for each class (including getters and setters) ● Your project implementation must include at least: ○ 6+ if-else statements ○ 6+ loops (while loops, for loops, do-while, in total) ○ 2+ nested loops ○ File IO (both reading from a file and writing to a file) ● Your project must have an interactive component (ask the user for input, create a menu for choices, ...). ● Game stats should be displayed as instructed at each turn. It’s more exciting and meaningful! Also, these stats help debug the code. Work Alone or in a Group of no more than two. For the final project, you are allowed to work with (at most) one other student that is currently in CSCI1300 this semester. You may also choose to work by yourself if you so choose. If you decide to work as a team, you must meet an additional requirement: Implement a sorting algorithm. Write your implementation of a sorting algorithm --- do not use a Library function or any outside resources) and apply it to a task in your program. One situation where the sorting functionality would be useful is for a ranking task, for example: ranking the time it took each player to reach Oregon. Note 1: If you work in a team and you do not implement a sorting task, you will be subtracted 10 points from your point total. Note 2: We expect that you will be contributing to the project equally. Both group members must submit a zip file for the project, and the solution files can be the same. Indicate your partner’s name in comments at the top of each code file. Both partners will book an Interview Grading appointment together and TAs will be grading you individually. Timeline November 12th – 18th : Project design meetings. Meet with professors/TAs/LAs to discuss your project ideas and the classes you will create and use. You should bring your class files and code (a list of classes and methods you will implement) to the meeting. During the meeting, we will go over your classes to see if they’re feasible and meet requirements. The project design meeting is mandatory, if any one of the team members scored below 50/80 on Project2-CodeRunner. We will remind you to schedule a design meeting. Prior to Wednesday, November 11th, you must have reserved a slot on the Project 3 Design Meeting Scheduler and have the meeting date reserved for a day on or before Wednesday November 18th. Thursday, November 19th, 6:00pm: Submit class files & Code Skeleton. Your .h files should be complete with all the data members and member functions you will be using for each class. For the class implementation .cpp files, you should fully implement simple functions[1] like your getters and setters. For more complex functions you can include function stubs with detailed comments. For example, if we were stubbing a function to implement bubble sort and return the number of swaps we might give in our code skeleton: /* 1. Compare adjacent elements. If the first is greater than the second, swap them. 2. Do this for each pair of adjacent elements, starting with the first two and ending with the last two. At this point the last element should be the greatest. 3. Repeat the steps for all elements except the last one. 4. Repeat again from the beginning for one less element each time, until there are no more pairs to compare. */ int bubble_sort(int arr[], int size) { int swaps = 5; return swaps; // function returns expected type (int) } Tuesday, December 1st, 6:00 pm: Final Deliverables. Your project will be due on Tuesday, December 1st, 6:00 pm. You must submit a zip file to Project3_zip assignment on Canvas, including all .h and .cpp files. The submission should compile and run. TAs will also be grading comments and style. Saturday, December 5th, 6:00 pm: Project Report. Write a 1-2 page report containing the following reflection questions: 1. How did you prepare for the project? 2. How did you develop our code skeleton? In what way(s) did you use your code skeleton? 3. Reflect on how you could have done better or how you could have completed the project faster or more efficiently? 4. In addition, write a paragraph answering the following question, in the context of the Project in CSCI 1300: Did you have any false starts, or begin down a path only to have to turn back when figuring out the strategy/algorithm for your Final Project program? Describe in detail what happened, for example, what specific decision led you to the false starts, or, if not, why do you think your work had progressed so smoothly. In either case, give a specific example. The report should be a 1-inch margin, single space, 12pt font size, times new roman. Submit a report as PDF to Project3_report on Canvas. Every team member should submit an individual report, clearly distinct in content from their teammate. Project 3 Interview Grading Scheduler (Oregon Trail) Interview grading. Oregon Trail interview grading scheduler will be available before the deadline of this project. The interviews will take place between November 30th and December 7th. If you don’t sign-up to meet between November 30th and December 7th and you miss your interview, then no points will be awarded for the project. During the interview grading, TAs will be playing your game and asking questions about your game. They will also ask about your implementations and conceptual questions. ● If you choose to sign-up for an interview on or before December 1st, your project should be submitted on Canvas before your interview appointment. ● Each time slot will be able to accommodate 2 students. If you worked in a team, look for a time slot where both “seats” are available, so you can sign up together with your partner. If only one “seat” is available, this means the slot is taken by someone who worked alone. Extra Credit (10pt): Present your project in a video. Make a 5-minute (+ or - 1 min) video explaining: ● The project idea ● Implementation and approach ● A demonstration of the working project Collaboration All work for this assignment (and of course in general) must be original work. Every project (group or single) must be original and not similar to ANY other source (internet, paid tutor, fellow student, past years projects, etc). You may collaborate and brainstorm with other people, but each assignment submission is to be the unique creation of the author(s). Your code must be original and unique. Your work may not include code taken from online resources like Chegg or StackExchange, or from other students (past or present), even with modification. Any such instances constitute Academic Dishonesty (passing off others' work as your own) and will earn you a 0 on the assignment and a trip to the Honor Code Council. If a group project is found to be non-unique and deemed worthy of being sent to Honor Code Council then BOTH parties are guilty (even if one party decides to “take the blame”). Choose your groups wisely! If you aren’t sure if something is okay, then please ask! Project 3 points Project 3 is 15% of your final grade. Here is a summary of the points. 10 points - for submitting your code skeleton and class files on time. 10 points - submitting the project report as described earlier. 30 points - Implementation requirements. The implementation requirements are specified on the 1st page of this write-up. 50 points - interview grading. - TA's questions about your project - Algorithms descriptions, comments, good style - Code compiles 50 points - project functionality - The game plays at outlined in the project description - Your solution accounts for user error Project 3 total: 150 points Note: if your code does not compile, you cannot score above 50 points for the project.
欢迎咨询51作业君
