ITEC 380 2023spring ibarland

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

list processing
pac-man cont.

Mar.02 (Thu) 09:30: questions 1-5;
Mar.14 (Tue): the remainder.
For each part, your hardcopy only need include the code for the new requirements, but the D2L version should have all files needed for running (as individual files, not a .zip).

Reading: §6.6, and §10.1–10.3.1.
(Additional recommended, but not required, background reading: all of Chpt.6, and §10.3. Additional, non-required, challenge-reading: § 10.5.)

All problems are to be written in Racket. Do not call any of the following functions:

• list (except when making test-cases)
• append (unless you write it yourself)
• remove/remove* (unless you write it yourself)
• place-images (plural) (unless you write it yourself); calling place-image (singular) is fine/intended.
• any functions with a “!”, such as set! and set-rest!.

Your name and the assignment-number must be in a comment at the start of the file All functions/data must include the appropriate steps¹ of the-design-recipe.html. In particular, test cases alone might be worth 40-50% of the credit for a function. Have enough test cases to cover different corner cases; often 2–3 can suffice.

1. Write the function count-bigs : (-> real? (listof real?) natnum?, which takes in a threshold and a list of numbers, and returns how many of them are larger than the threshold. To help you out, here are some test cases; no further ones are required. (The data-definition for list-of-number has already been given in lecture, so you don't need to repeat steps 1-3 of the design recipe for list-of-number.)
   

   Remember: We can't re-assign to variables, in functional programming. So we won't have a counter which we increment, like you might in your imperative-programming class. Instead, be sure to follow the design recipe, and after copying the template, think about the inventory-with-values (assuming we call our parameters “thresh” and “nums”): if we call count-bigs with the particular inputs (count-bigs 3 (cons 10 (cons 2 (cons 5 empty)))), what is…

   • thresh =     
   • nums =                                                                                                   
   • (first nums) =       
   • (rest nums) =                                                                   
   • (count-bigs threshold (rest nums)) =     

   Fill in each blank with a particular number, or list-of-numbers. Then, ask yourself: Starting with those pieces of info, how do I assemble them to get my desired result of 2?

   You don't need to include the above in your answer — it's just to remind you of what you do, for the “inventory-with-values” step of the design-recipe, #6. If you get stuck on any of the problems below, make sure you didn't skip this step; it's the one that can really make things click!

2. Write the racket function map-sqr : (-> (listof number?) (listof number?)), which squares each number in a list; do not call map . To help you out, here are some test cases; no further ones are required.

   (check-expect (map-sqr empty) empty) (check-expect (map-sqr (cons 7 empty)) (cons 49 empty)) (check-expect (map-sqr (cons 9 (cons 7 empty))) (cons 81 (cons 49 empty)))

You will not need to turn in hardcopy of things before the dividing-line if they were in your hw04 solution or in the posted hw04-soln and student-extras.rkt². Please include part A (problems 1,2) in your part B hardcopy.

3. For List-of-ghosts,
   1. Give the data-definition for list-of-ghost but no define-structs are necessary, since using the built-in cons suffices.
   2. Give at least 4 example values of this type. Your last example should contain at least four ghosts; you may use this as the ghosts in your game's initial world.
   3. Write the template for a list-of-ghost processing function.
4. Write pacman-collide-ghosts?, which determines whether a single pacman overlaps with any ghost in a list-of-ghosts.
   (Of course, you should call hw04's pacman-collide-ghost? as a helper.)

   name-change: In hw04 we actually called it pacman-overlap-ghost?, but I decided I prefer collide. You can use either collide or overlap, as you prefer.

5. Write ghosts-remaining : (-> pacman? (listof ghost?) (listof ghost?)), which returns all ghosts in the given list which are not colliding with the pacman.
   (If you are not implementing a pacman being “powered up”, then you won't use this function in your final game, but I am still requiring it. If you are implementing that feature, then the function should only remove ghosts if the pacman is currently powered-up.) Remember, do not call built-in functions like remove. Use the list template.
6. Similarly, give examples of List-of-walls. You don't need to give a data-def'n or template (since they are so similar to those for List-of-ghosts), though. One list should be what you'll use in the game, and to be interesting should have at least six walls: Four for the outer-boundary, and at least two interior ones. That lets us do something at least as interesting as, say:
7. Similarly, write pacman-collide-walls? and ghost-collide-walls?.
8. Drawing functions: Write draw-ghosts, and draw-walls . Each of these functions take a list-of-items and a background-image, and return the background image with the items overlaid on it. When creating the expected-output for your test cases, feel free to include the calls to draw-ghost (singular), etc.. Creating the expected-result for a test for a list-of-length-2 will help you understand what your code needs to do.
9. Write move-ghost : (-> ghost? (listof wall?) ghost?), which is like glide-ghost but accounting for walls:
   If gliding one step would end up colliding with a wall, then instead just³ ghost-spin (from hw04). (In this case the ghost need not actually end up moving.⁴).
10. Similarly, write move-pacman : (-> pacman? (listof wall?) pacman?).
    • Option 1: If your pacman struct includes both a current-direction and a “cached” direction-keypress, then: You should test if moving in the direction of the cached direction will avoid walls; if so then that will become the new direction. Otherwise, see if moving in the current direction will avoid walls; if so it continues moving in that direction. Otherwise, the pacman should … stop? Move in a random/next direction? It's up to you.
    • Option 2: If your earlier pacman-handle-key had a keypress take effect immediately, you can still do so. (This is harder for the player, since there is only a limited time for them to hit the direction key — as little as one frame, if two walls are exactly the width of a pacman|!) In this case, if gliding the pacman would result in colliding with a wall, the pacman should probably stop.
11. Worlds:

    1. Define a “world” structure which contains one pacman, a list of ghosts, and a list of walls.

       As usual for our data-definitions, make examples of the data (at least two).

    2. Give a template for world-processing functions.
    3. Write the function move-world : (-> world? world?) which returns a new world one tick later, where the pacman and all ghosts have moved.
12. Write the function world-handle-key : (-> world? key-event? world?) which returns a new world updated to handle the keypress. Will be easy — mostly defers to pacman-handle-key, and your test cases will largely crib from that.
13. Write the function draw-world : (-> world? image?), which draws the world onto a blank background.
14. Optionally: If implementing dots, give functions similar to the above for them.
15. Finally, write a function game-over? : (-> world? boolean?), which returns whether the game is over (that is, if the pacman is colliding with a ghost, or (optionally) there are no more dots).

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

Only after all tests pass, add

(require 2htdp/universe)

(big-bang some-initial-world
    [on-key  world-handle-key]
    [on-tick update-world]
    [to-draw draw-world]
    [stop-when game-over?])

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