The farm area that is operated on during the game is comprised of a two-dimensional grid of cells, each representing a plot of land. These cells are referenced by a coordinate pair; e.g. (2, 3). This land can be used to cultivate crops or graze livestock in order to generate revenue; however there are costs involved in preparing the land and maintaining it on a monthly basis.
The game board should be able to calculate a sum of all costs and revenues associated with its constituent land plots. In the object design, the farm area specification must not be specific to one specific kind of implementation (hint: define an interface for all actions that are required of it.) Land plots can be either owned by the player, or available for sale to the player. At the start of the game, a certain number of plots of land are owned by the player; other plots can be bought as the game progresses. Each piece of land has a purchase price (these prices are the same for all plots of land in the farming grid.) Only owned land can be used for producing revenue. It is only possible to purchase land that is adjoining a plot of land that is already owned. Land that is owned by the player incurs a monthly cost to represent the task of maintenance. Owned land can be sold to generate revenue; when this happens, the land is made available for future purchase. If an occupied [with produce] plot of land is sold, the produce on that plot is surrendered, and the land becomes polluted. Land may also be polluted from either dead crops or livestock use (explained further in the specific sections below); when this occurs, the land must be recultivated before it can be used again. Land status is persistent (for example, selling polluted land and then re-purchasing it will not recultivate it to a clean state.) Each land plot must be able to report its status (clear, polluted, or occupied by a particular produce type.)
Produce Types All produce types have a name, and have the ability to report:
• Preparation costs
• Monthly maintenance cost
• Monthly revenue
• Current sale valueFrom this base definition, specific produce types are defined. In addition to the basic produce functionality listed above, crops must follow the following rules, and such functionality should be added to allow the following:
• Crops have a set preparation and monthly maintenance cost.
• Crops have no monthly revenue.
• Crops must have been bought and grown for a certain number of months before they are mature for sale. Crops that are not yet mature have no value.
• Immature crops can be abandoned by attempting to sell them - in this case, they are Sold with no value, and the land must be recultivated before it can be used again.
• Mature crops are considered commodities: all crops of a certain type have the same value, and this value varies from month to month. (The value variance will be implemented through the use of a mathematical formula.)
• Some time after crops reach maturity they die, and lose all their value. Furthermore, if crops are left to die on a plot of land, that land must be recultivated before it can be used for any other activity. If crops are sold before they die, no recultivation is needed. There are two kinds of crops in the game: wheat and apples. The object design should be written so that it is conceptually easy to add more crop types in the future. Livestock The specific attributes of livestock are as follows:
• Livestock have a set preparation and monthly maintenance cost.
• Livestock generate a constant monthly revenue (e.g. cow's milk, sheep's wool, etc.)
• Livestock are also considered commodities: they can be sold at a market price, that varies monthly.
• Livestock last forever. There are two types of livestock in the game: cows and sheep. As with crops, the object design should make adding more livestock types in the future easy to implement. Game Calendar The calendar is based on a yearly cycle of 12 months, stored as a simple integer count. The number 0represents January 2000, 1 is February 2000, 12 is January 2001, and so on. It is not possible to go back in ti me. It is only possible to move forward one month at a time. At the signal to move from one month to the next, all costs and revenues must be calculated and applied. Events such as the maturity or death of crops for the coming month should be acted upon at this time. Sales and purchases occur instantly. Events and Priority Queue In order to track events, a priority queue must be maintained, based on the month. This is a data structure which stores a number of events, each of which is made of an event type, the produce that is affected, and the time at which it is supposed to happen. The data structure will be able to keep everything in chronological order, and return all the events that are going to occur at a particular month. The following events must be tracked: • When a crop becomes mature
• When a crop is almost about to die (one month's warning)
• When a crop is going to die
• Any other events (if any) you consider appropriate. At the beginning of each month, it is intended that the program would query the priority queue for any events that are pending, and apply those changes to the land as necessary. Events must be able to distinguish between crop cycles; for example, if a plot of land is used for crops and successfully sold, and then re-established as a new crop field, the death event for old crop should not apply to the new crop in the same location. Important Note: you do not need to worry about how the priority queue will work internally; for the design it is only necessary to consider what kinds of operations (add, delete, etc.) the priority queue should offer. Like the land plot collection, in the object design, the priority queue should be defined as a generic interface of all operations that are required of it, and not based on a specific internal implementation The controller uses the other functional areas of the design in order to encapsulate and implement the game logic. The ultimate object of the game is to build a profitable farm. If the player goes bankrupt, the game ends. The available transactions the user may take are as follows:
• Purchase, sell or recultivate a land plot
• Buy or sell a particular crop or livestock at a land plot
• Move to the next month The controller, when issued with these instructions by way of a method call, should interact with the other parts of the program where relevant in order to complete the task. The game is turn-based; the user commands the program to move from one month to the next once they have finished making decisions for that month. There is no limit to the number of transactions a player can make in any one month.The controller is not the user interface; it is the code that the user interface will interact with in order to control the game in progressoriented concepts such as composition, inheritance, method overriding, abstract classes, interfaces wherever appropriate.
Further Questions
You will also need to answer the following questions with respect to your design.
1. Explain how the events in your design are going to know what produce type to affect, and how these changes are going to be implemented.
2. In your design, explain how the events will not affect different crop cycles (for example, the crop cycle scenario presented in the problem description above.)
3. Explain how your object design is going to handle the following operations: a) The preparation of a land plot for produce. Being able to maintain the crop life cycle of preparation, maturity, and death, and updating factors such as value, land status, etc. appropriately. c) The monthly calculation of all costs (land and produce maintenance costs) and revenues (monthly produce revenue) for the farm