ITEC 380 2024spring ibarland

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

hw04b,c: structs
…for Snake (gridless)

• I recommend finishing #1 and #2 by Feb.09 (Fri) morning, so you have time to clarify any issues during office hours.
• The remaining problems are due Feb.13 (Tue) 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 (b)

Familiarize yourself with the arcade game Snake. We will write our own version, starting with this homework (structs) and finishing with next homework (lists). We will write a simplified version which only needs to deal with: the head, segments, and fruits. However, our snake will not be on a grid: it can wiggle in any direction (steered by the player). To make our lives easy, it will still advance by one segment each tick. If we moved only a few pixels, we'd run in to our our own most-recent segment immediately, which wouldn't be good! It does not need to deal with: score, number-of-lives, having more than one level, or walls/barriers.

There are three types of things (objects) which our program will need to model: heads, segments, and fruits. In particular, we'll view the snake as just its head, separate from the rest of the segments.

Racket & Java

1. Give a Java record and a racket struct for a head.

   In addition to this datatype-definition, give at least two example head objects/structs (the design recipe's #2,

   examples of the data
   ), and the template (the design recipe's #3).

   hint: Thoughts/advice on fields below.

2. Create (in both racket and Java), a function glide-head which takes in a head, and returns a head one tick of time later, ignoring any exterior factors like encountering segments or fruits or key-presses. Do account for wrapping around the screen; you can (should) have a couple of named-constants for the screen's height and width (perhaps 800x600 or so).

   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 head's fields is about the model, not the view. (Later we will write draw-head below, though in racket-only.)

   You might want to review how moving at some angle corresponds to changing its x- and y-coordinates.

part (c)

Racket only

The following functions only need to be done in Racket (not Java).

3. Define structs for segments, and for fruits. (Of course, still complete steps 1-3 of the design recipe.) For each type of data, make four examples-of-the-data: two
   before
   versions, and two corresponding
   after-gliding/aging
   versions. (This will help with test cases.)
4. optional If you would like to implementing walls, then give a data-definition and examples.
5. Write age-segment, and age-fruit, similar to glide-head above.

   Note: We will not be using struct-inheritance, so these functions might be very similar to each other.

   Note that all threetwo of these functions are similar: they handle
   what happens to this struct, in response to time-passing (a
   tick event
   )?.
6. Drawing functions: Write draw-head : (-> head? image? image?) which draws a head onto the provided background-image. Then do similarly for draw-segment and draw-fruit.

   notes:

   • 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.
   • The library function place-image can be helpful.
   • If the head is entirely off the background, then it's reasonable to say it wouldn't be shown in the result (which is what place-image does, since it crops the result to the background).

7. optional If you would like to implementing walls, then write draw-wall as above.
8. Write head-handle-key, which takes in a head and a key-event?, and returns a new head which has processed that key-event.

   notes:

   • Playing the demo above, we see there are only two key-presses that do anything (perhaps four, if you have a way to speed-up or slow-down). key-presses that actually do anything .
   • You can compare two key-event?s with string=?, but key=? (from (require 2htdp/universe)) is more appropriate. Equal credit will be awarded, either way.
   • Note that a key-event does not move the player. Only clock-events (ticks) actually move the player; the key-events are instantaneous in the game-model.

9. Collision detection: Write head-collide-segment?, which returns a boolean.
10. optional If you are implementing walls, also write head-collide-wall?.

Design considerations

When declaring fields, give them good (and perhaps short) names. Do remember to indicate their units (if appropriate), along with any other non-obvious info.

Many fields have multiple possible representations. For example, for a head's direction you might use an angle what units? what does angle 0 mean?, or a pair of coordinates, or even those two coordinates further wrapped inside single field of type coordinate-point (if I defined my own new struct for that). 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, so I'll point out the following:

• The image-library's function rotate uses degrees, so that's a convenient unit for your own code/fields to use. But if calling (say) cos be sure to convert deg->rad!
• The function place-image wants an x/y offset as two separate coordinates (and not a single, bundled coordinate-point struct), so our representation might follow that lead. It also uses the standard computer-graphics conventions that 0,0 means the upper-left corner, and +y means downward. Yeah, it's low-key annoying that these two computer-graphics conventions defy standard pre-algebra's more reasonable conventions.
• Note that 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.
• The student-extras.rkt includes the functions modulo/real: e.g. (modulo/real 3.5 2) returns 1.5.
• 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 . Please cite your source, of course!
• You might find struct-copy helpful; it copies a structure, letting you change a few fields: (struct-copy 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