CS 380 2024fall ibarland

home—lectures—recipe—hws—exams—D2L—zoom (snow day)

hw04: structs
…for Pac-Man

Due:

• Questions 1-6 are due Sep.24 (Tue) in class; no hardcopy.
• The remaining questions are due Sep.26 (Thu) in class, with hardcopy.

Standard instructions for all homeworks:

• Your name, the assignment-number, and the URL of this assignment must be in a comment at the start of the file.
• Any code which results in syntax errors will generally not earn more than 50% of the points-possible. For grading, I will ignore any commented-out code (unless the problem is explicitly asking for commented-out code, ’course).
• If your hardcopy is more than 1page, it must be stapled.
• Format well (in particular, each open-paren should be preceded by a space or start-of-line, for now).

part (a)

1. Complete the short fill-in-the-blank questions on the D2L quiz hw04a. Your answers should be valid racket expressions. Do be sure to answer what the question is asking.

part (b)

(This is the completion of hw04a, from D2L.)
Consider the following information, which might be part of a sports-simulation:

A team is:

• a name (non-empty string), AND
• an offense rating (real number), AND
• a defense rating (real number).

2. Give a datatype definition (including examples of the data, and the template for any function which processes a team), as per steps 1-3 of the design recipe. Give at least three examples of a team.

3. We’ll say one team is greater than another if its offense is higher than the other’s defense, and its defense is higher than the other’s offense. Write the function team>? to implement this. Follow all the steps of the design recipe¹. As always, be sure to think about enough test-cases to cover the interesting situations (half of the pts). (In this case, six or seven should suffice, if they each cover a different situation.)

part (c)

Familiarize yourself with the arcade game Pac-Man. We will write our own version, starting with this homework (structs) and finishing with next homework (lists). In our simplified version: We will write a simplified version which only needs to deal with: the pacman, ghosts, a few walls, and optional eating dots. It does not need to deal with: score, number-of-lives, having more than one level, wrapping around, power-dots, or ghosts becoming temporarily vulnerable.

There are three types of things (objects) which our program will need to model: pacmans, ghosts, and walls.

Racket & Java

4. Give a Java record and a racket struct for a pacman.

   In addition to this datatype-definition, give at least two example pacman objects/structs, and the template for functions-handling-a-pacman (That is, don't ski; the design recipe's steps #2 and #3, in either language).

   hint: Thoughts/advice on fields below.

   Consistency: Your Java and racket should directly correspond t each other, nearly word-for-word. In particular, use the same field-names (except for idiomatic differences like using camelCase/snake_case for Java vs. kebab-case for racket).

5. Write glide-pacman which returns a new pacman object/struct one tick of time later, ignoring any exterior factors like walls or key-presses².

   The Java and racket versions should both work in the same way: returning a new object, rather than mutating any fields (Cf. how we did enbiggen in both racket and java).

   Note: This method has nothing to do with a gui or drawing. Updating the pacman's fields is about the model, not the view. (Later we will write draw-pacman below, though in racket-only.)

Racket only

6. Define structs for ghosts. (Of course, still complete steps 1-3 of the design recipe.) Two examples-of-data will suffice.
7. As above, but for wall.
8. Write glide-ghost, similar to glide-pacman above.
9. Write draw-pacman : (-> pacman image image) which draws a pacman onto the provided background-image.

   Note: The background passed in might be any image. For example you can test with , which is exported from videogame-helpers.rkt as house-with-flowers.

10. Write pacman-handle-key, which takes in a pacman and a key-event?, and returns a new player which has processed that key-event.
11. Write pacman-overlap-wall?.

    Note: You are free to use the provided helper-function overlap? in videogame-helpers.rkt. It takes in any two rectangles; your pacman-overlap-wall can be a thin wrapper around overlap?.

12. Write draw-wall and draw-ghost.
13. Write ghost-overlap-wall?.
14. Write ghost-spin which simply returns a ghost which is rotated a quarter-turn (either clockwise or counter-clockwise, or even randomly).

You are not required to implement dots or power-dots. But if you want to, make structs and similar draw and overlap? functions for them. (It's not extra credit, but it's not too difficult and will make your game much more fun.)

Design considerations

Many fields have multiple possible representations. For example, for a pacman facing/moving toward the top of the screen, I could see using 'north, or 270°, or 0,-1 as two fields, or a single fields (make-direction 0 -1) (if I defined a new struct direction), or the key-event? "up". These all have their strengths and weaknesses.

One thing guiding our choice might be the libraries that we want to interact with. In this case, we'll be using the 2htdp/image and 2htdp/universe libraries, so I'll point out the following:

1. The function place-image places an image's center at a specified coordinate. (This differs from some drawing libraries that use an image's northwest corner as its location.) In addition, the provided overlap? also wants coordinates-of-centers of rectangles. I strongly suggest you use this convention in your fields.
2. For drawing Pac-man, the image-library's function wedge might be helpful.
   (You can make Pac-man look very non-traditional, but it should have a mouth that opens & closes.)

   According to Wikipedia, the original Pac-Man's color was rgb (251,244,31). This is very close to gold (rather than yellow).

3. For deciding how wide-open the mouth should be at any given moment, feel free to use the function sawtooth provided in videogame-helpers.rkt. See that function's test-cases (and purpose-statement) for how it works.
4. I suggest using simple shapes (like mere rectangles) for all your drawing-functions for the game. You are welcome to be much fancier, though it won’t earn you additional credit. You are welcome to use jpg/png/bitmaps, but make sure you have the legal right to copy them — e.g. from sites like classroomclipart.com or libraries like planetcute . (Too bad we don't have the rights to street-artist @shok_1's take³.) Please cite your source, of course!
5. Optional: You might find struct-copy helpful; it copies a structure, letting you change a few fields: (struct-copy book my-book [num-pages (add1 (book-num-pages my-book))] [author "me"]) is equivalent to (make-book (book-title my-book) "me" (add1 (book-num-pages my-book)) (book-is-copyrighted? my-book)).

home—lectures—recipe—hws—exams—D2L—zoom (snow day)

This page licensed CC-BY 4.0 Ian Barland Page last generated

Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu