EECS 111: Homework 7

Purpose

To design a complex program from start to finish.

Design & Code Style

Good design and good style are essential, as always. The same rules as before still apply, but now we expect more. In addition to following the six-step Design Recipe, you should be seeking opportunities to replace repetitive code with abstractions. Don’t just write code that works—write code that’s easy to read and easy to understand.

Problem

You should have a design document from Homework 6. Please paste your design document in a #| |# comment at the end of your new .rkt file. If the actual design in your code diverges from the design in your design document—and it will!—you will need to update the design document that you include in your submission to reflect the changes.

Your assignment is to implement the space shooter game that you specified for HW6 using ISL (or ISL+λ). We have provided playable example games for Windows, Mac, and Linux/x86 (32 bit or 64 bit). (We think that should cover everyone, but if not, please let us know.)

You may reuse any code that you have seen in lecture. However, if you do so, you must comment each function from lecture to tell us where you got it. If you start with some code from lecture and modify it, that requires citation as well.

We don’t require you to implement every feature in our prototype. At minimum:

• The player should be able to control the player’s space ship. Either mouse or keyboard control is sufficient.
• The player should be able to shoot at approaching enemies. There must be some mechanism to limit shooting, either a maximum live bullet count as the prototype game uses, or an actual rate-per-time limitation.
• The game should keep score. If a shot hits an enemy, the enemy disappears and the player’s score increases.
• So long as game play continues, enemies should continue to appear at the top of the screen in random locations.
• Enemies should move toward the bottom of the screen.
• If an enemy reaches the bottom of the screen, the player should be informed that the game is lost.
• No magic numbers: It should be easy to tweak fundamental quantities such as the world size.

You may implement enhancements as you wish, provided that they don’t significantly impair the game play as described above. For example:

• The enemies may move in more complex paths, take evasive action, or even shoot at the player.
• Enemies or the player may take multiple hits rather than one.
• You may have different kinds of enemies.
• The game may become progressively harder as the score increases, or you may add levels.
• You may implement better animation than ours.
• You may implement pausing, an opening screen, level selection, and such. Level selection as part of the game UI is better than level selection when calling the function to start the game.

What you do is not limited to the above. There may be a small amount of extra credit available for games that impress our graders; keep in mind, however, that extra features won’t make up for the basic game play being broken.

You must include, in a comment at the top of the file, instructions on how to start your game. This should be something short, like (run GAME0), rather than something long involving big-bang. Grading will be done primarily by playing the game, so we recommend that you turn in code that runs and is somewhat playable.

Good luck and have fun!

Turn In

Write your program in one .rkt file. Be sure to list both partners’ names and email addresses in a comment at the top. Then submit your file through Canvas.