DrRacket代写: CISC 108 Project 1: Fish World

University of Delaware CISC 108: Introduction to Computer Science I Fall 2016

Project 1: Fish World

1. Assignment Goals

• To write programs using a combination of lists and structures
• To practice using the design recipe to organize a nontrivial program
• To design an interactive program in which the “state of the world” is a data structure of

  arbitrary size

  2. The Assignment

  Your job is to create a simple interactive version of a game called Feeding Frenzy. In this game, fish of various sizes move around in a 2d-rectangular scene. You control one of the fish, which is special and a little di↵erent from the others; from now on we will refer to that fish as the “Player” fish. The other fish are the “Enemy” fish. If the Player comes in contact with an Enemy that is bigger than it, the Enemy eats the Player, and you lose the game. When the Player comes in contact with an Enemy that is smaller than it, it eats the Enemy, and you accrue a certain number of points. Each time your points exceed a certain threshold, the Player’s size increases, giving it the ability to eat more fish. Your goal is to maneuver the Player to avoid getting eaten, and eventually to eat all the other fish, at which point you win.

  Now for the details:

  (1) The Enemy fish come in three sizes: Small, Medium, and Large. You should find or create a di↵erent image for each. (For example, you could use a shark for the Large size.)

1

2

2. (2)  The Player also comes in three sizes called Small, Medium, and Large. However, all of these sizes are slightly larger than the corresponding sizes for the Enemy: the Player’s Small size renders as something approximately half way between the Enemy’s Small and Medium, so a Small Player can eat a Small Enemy. Similarly, the Player’s Medium size falls about half way between the Enemy’s Medium and Large sizes, so a Medium Player can eat a Medium or Small Enemy. A Large Player is larger than all other fish and can eat anything. The Player should look distinctly di↵erent from the other fish, and the three di↵erent sizes of the Player should all look the same, except of course for their size.
3. (3)  In the initial state, a certain number of each size of Enemy fish are created. These numbers are determined by named constants in your program. All of the fish (including the Player) appear at random positions in the initial state, but there should be some minimum distance between the Player and the other fish.
4. (4)  The Enemy fish can move in any direction (not just left/right/up/down). An Enemy fish that is moving according to a certain velocity vector (vx,vy) will tend to continue moving according to that velocity vector, but at certain random times, its velocity vector changes to a new randomly-selected vector.
5. (5)  The random times at which a fish’s velocity vector changes are infrequent. They should only happen with some low random frequency, determined by a constant CHANGE-FREQUENCY defined in your program. A good value for this constant might be something like .02, indicating that a change in direction will only happen approximately once out of every 50 clock ticks, but some experimentation will be necessary to find an appropriate value.
6. (6)  At any time, an Enemy fish’s velocity vector (vx, vy) will satisfy SPEED-BOUND  vx, vy  SPEED-BOUND, where SPEED-BOUND is another constant you must define.
7. (7)  The Player can only move up, down, left, and right. Unlike the Enemy fish, it does not have a velocity: it stays still unless an arrow key is pressed. Pressing the “up” arrow causes it to move up STEP-SIZE pixels, where again STEP-SIZE is a constant. Similarly for left, right, and down arrows.
8. (8)  The Player fish must always point in the direction it is moving (up, left, right, or down).
9. (9)  The act of “eating” can be rendered by just making the fish that is eaten disappear.
10. (10)  Number of points: You start o↵ with 0 points and get 1 point for each small fish you eat, 2 points for each medium fish you eat, and 3 points for each big fish you eat. But use

    constants instead of 1, 2, and 3.

11. (11)  When your points exceed THRESHOLD-1, the Player’s size changes from Small to Medium.

    When your points exceed THRESHOLD-2, the Player’s size changes from Medium to Large.

    Define these constants, and experiment to find appropriate values for them.

12. (12)  Rendering: In addition to displaying the Enemy fish and the Player fish, the screen will

    display your current score (number of points) at all times.

13. (13)  A fish that moves o↵ the right side of the scene re-appears on the left; a fish that moves o↵

    the top of the screen re-appears on the bottom; etc.

14. (14)  If the Player is eaten, the words “You Lose” will appear in large letters over the final scene

    and the game terminates.

15. (15)  If you win (eat all the other fish), the words “You Win” will appear in large letters over

    the final scene and the game terminates.

    3. Suggestions

3.1. Software Engineering Strategy. If you and your partner prefer to work separately, work out and agree on the data definitions first, then proceed to work on the rest of the code (together or independently). In a professional setting, one person or team is responsible for each data definition

and all the functions that operate on that data definition. Function signatures become literal contracts between you and your teammates.

Implement the game in stages (“increments”), not all at once.

Start with a simple version—perhaps one that only has one size of fish. Once you have that working, add the various sizes. Once that is working, add the directional rotation of the fish. Get the game to terminate correctly. You will get more credit for a fully-working, well-designed solution to part of the game than for a non-working solution to the whole game.

4. Milestones and Grading
After one week: the following must be complete for Lab 5 (Wednesday evening):

• Complete data definitions for the Player, Enemy, and FishWorld.
• The Player must appear at some random position against the background in the initial

  state. (The Enemies do not have to appear.)

• The Player must move left, right, up and down when the corresponding keys are pressed.
• The Player must also point in the direction it moved when the key is pressed.
• The Player must “wrap around” in the x- and y-directions. I.e., when it moves o↵ the left

  edge, it appears on the right, etc.

  It goes without saying that your program must include complete unit tests and documentation. Call this file lab5.rkt and submit via Sakai to Lab 5 Assignment. Make sure that both students’ names are in a comment at the top of the file. If submitted late, a penalty of 15% will be applied. Solutions will not be accepted after 24 hours after the deadline for Lab 5.

  After two weeks: the following additional features should be implemented:

• The Enemy fish must appear in random positions at start.
• The Enemy fish should include some mixture of di↵erent sizes.
• The Enemy fish should move according to their randomly chosen velocity. (However, they

  do not yet have to change velocity vectors.)

• The correct score should be displayed in the upper right corner of the screen (but does not

  necessarily have to change yet).
  After three weeks: the following additional features should be implemented:

  • Each Enemy can change velocity at random low-frequency times.
  • If an Enemy intersects with Player, then one of the two is eaten.
  • If the Player is eaten, the Game Over appears and the game ends.
  • If the Enemy is eaten, the Player accrues points and the score is updated appropriately. • If the Player score passes a threshold, the Player size is increased appropriately.

  • If all Enemy fish are eaten, the game ends with “You win”.

  After four weeks: Finish any unimplemented features. Turn your program into a complete soft- ware product: refactor to eliminate repetitive code; re-write and simplify code using new language features you have learned where appropriate; double check that all code is covered by tests and that test oracles (expected results) are correct; make sure the code is easy to read, broken up into sections in a logical way with copious documentation, and indented correctly. Turn in a single file project1.rkt containing all code and documentation for this assignment to Project 1 on Sakai. Make sure that both students’ names are in a comment at the top of the file.

  4.1. Hints. You will be graded primarily on the structure of your code, not on e ciency. Don’t worry about e ciency. Your computations to check when one fish eats another do not need to be

3

4

exact (i.e., don’t waste time on getting these expressions correct down to the pixel). If the resulting game play looks plausible, we won’t care about the precise formula you used.

4.2. Extra Credit. Optional feature. Don’t do this until you have everything else working!!!. An Enemy fish must always point in the direction it is moving. (A function to rotate an image might be useful for this.) If you implement this feature, you will probably have to worry about performance, since rotation is computationally expensive. Consider caching the images in the Player and Enemy structures so that they only have to be rotated when a fish changes direction, not every time the fish is rendered.

You can use your creativity or speak to the TAs or instructors for other extra credit ideas.