ITEC 380 2021fall ibarland

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

hw04: structs
…for Frogger

Due:

• part (a) is due Sep.21 (Tue).
• part (b) is due Sep.21 (Tue): on D2L, but no hardcopy.
• part (c) is due Sep.25 (Sat) 23:59: D2L, and hardcopy of (b) and (c) at next class.

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)

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).

1. 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.

2. 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 frogger arcade game. We will write our own version, starting with this homework (structs) and finishing with next homework (lists). In our simplified version:

• The frog's goal is to kiss a prince(ss). Prince(ss) s only appear at a random location at the top of the screen, stay there for a fixed amount of time (say, 10seconds), and then disappear, with another prince(ss) appearing somewhere else.
• Trucks travel right to left, at different speeds.
• We will not worry about: rivers/turtles; having multiple frogs trying to several destinations; trucks that look different.

There are three types of things (objects) which our program will need to model: frogs, trucks, and prince(sse)s.

Racket & Java

3. In both Java and Racket, develop a datatype-definition for a truck. For each field, give a short (two-to-three word) comment describing what it stands for, and its units. Natural units for screen-based games are pixels, and ticks (where a tick is an abstract amount of time, but it’s convenient to declare it as the amount of time between two frames).

   Note: No images are involved!

1. Give a Java class (or, record) to represent a truckfrog (non-static fields and a constructor only; your constructor should take as many arguments as there are fields).

   You should have a Truck.java file (which compiles and runs, even if it doesn't print anything); it should be less than a page² of well-spaced, commented code, including tests.

   enabling assertions in Java: When running your program, the JVM's default behavior is to entirely ignore assertions (!?!). If using assert for your tests (just as we did in Book.java), run with³ java --enableassertions someClassName, or convince your IDE to do this.

   Java's `record`s: You are encourage to use record, to make your life easier (as in lecture-example).

   • It's okay if you use regular classes and don't override .equals/.hashCode; it just means your asserts involving truck objects will fail.
   • You likely need to install JDK 17 to do this by openJDK, or by Oracle. Post on discussion-board if you have (or overcome) any glitches.

2. Give a corresponding Racket define-struct statement.

   Remember: Include both field-names and their types, in racket as well as Java.

   Good style: Your racket and Java code should use the exact same field and class names, up to idiomatic differences like camelCase vs. hyphenated-names.

4. Make at least two different examples of the data; do this both in Java and in racket. (In Java, where all code must be inside a method, put these inside a static method void tests().)
5. Write the template for truckfrog-processing functions, in both racket and Java.
   (In Java, you'll have to comment out the template, since the ... won't compile.)
6. Create (in both racket and Java), a function move-truck which takes in a truck, and returns a new truck one "tick" of time later, ignoring any exterior factors like colliding with frogs or any keys getting pressed.

   Of course: The Java and racket versions should work in the same way: returning a new object, rather than mutating any fields (Cf. enbiggened books, in the lecture notes).

Racket-only

The following problems only need be done in racket.

7. model Give datatype-definitions for an frog and a prince(ss), each with at least two examples of the data, and a template.

   Note: We will not use struct-inheritance⁴ This means some of our functions will essentially be repeating code, which is indeed annoying.

   suggestion: To represent a direction, use the strings "left", "down", etc. rather than (say) the symbols like 'west or 'bottom, etc. . This will play nicely with the key-event?s of the 2htdp/universe library.

8. Write move-prince(ss), similar to move-truck. Although prince(sse)s don't usually move, they might move every 10s or so. You should test both those situations.

   Handling randomness: How can we write unit tests, if the prince(ss) makes a random move? For this assignment, I recommend actually removing randomness: instead of choosing a new x randomly, we can instead make it the old x² + 321, mod the screen-width. This can still appear random to the user, but also be unit tested. (For other approaches to testing w/ randomness⁵, take Software Testing (ITEC335)!)

9. controller Write a function frog-handle-key which takes in a frog and a key-event, and returns a new frog having responded to the keypress.

   API: Represent a key-event as a String, e.g. "x" or "right". In racket, 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.

   hint: If you want to handle stopping at the left/right edges (or perhaps, wrapping around). To do that, you need to know the size of the board. Use named-constants for that. Your unit-tests can refer to those named-constants; for convenience they can also assume that each dimension will be at least 100 pixels — i.e. they can assume values less than 100 aren't near the right-edge. Also, note that modulo can help handle wrapping (or, if not using integers, modulo/real as provided in student-extras.rkt).

10. view:
    1. Write the function draw-truck : truck, image -> image, which takes a truck and a “background” image, and returns that background image with the truck drawn on top of it.

       hint: place-image is a handy function; it is similar to overlay/xy except that it crops the result to the background.

       hint: For test-cases, include drawing a truck that is: (a) near the center of a small image; and (b) one that is mostly off the left-edge but has just a few pixels showing.

       Note: Here’s an image you may use in your test-cases, in addition to a solid rectangle or whatever else you might choose: house-with-flowers.rkt. If you place this file in the same directory as other functions, you can just (require "house-with-flowers.rkt"), and then use its exported id (house-with-flowers, coincidentally). You don’t need to print nor D2L-submit this file, if you make no changes to it.

       looking ahead: It is important that your drawing-function take in any background image. Later, when we make an overall game-object, we will initially pass in an empty-scene to draw-truck, and then use that resulting image as the background for drawing the next truck, and so on. This is also what we did for the meme-drawing functions, when we wanted to overlay two different strings on the same image.

    2. Write draw-frog, similarly.
    3. Write draw-prince(ss), similarly.

    I suggest using simple shapes (like mere rectangles or star-polygons) 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!

11. collision detection Finally, write frog-collide-truck? and frog-collide-prince(ss)?.

    You may download and (require "overlap.rkt") (but you shouldn't need to modify that file, nor print/D2L-submit it).
    Remember, don’t copy/paste a .rkt file; right-click to download, and then you can open it in DrRacket if you like.

All the above should have their tests, as well as signatures and (brief) purpose statements.

home—lectures—recipe—exams—hws—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