RU beehive logo ITEC dept promo banner
ITEC 380
2020spring
ibarland

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

list processing
Pac-man II

Feb.28 (Thu) 11:00: questions 1-4 5;
Feb.29 (Fri) 23:59: 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:

If you want to use let* (as mentioned in class), you can require "let-for-bsl.rkt".

Your name and the assignment-number must be in a comment at the start of the file All functions/data must include the appropriate steps1 of the design recipe. 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, list-of-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 “threshold” and “nums”): if we call count-bigs with the particular inputs (count-bigs 3 (cons 10 (cons 2 (cons 5 empty)))), what is…
    • threshold =     
    • 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 : list-of-number → list-of-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)))
Copy your hw04(structs) racket file to one that we'll use for this one. Add a very noticeable dividing-line (say, 80 ;s) between old code and the new.

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-soln2. Please include part A (problems 1,2) in your part B hardcopy.

  1. 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. Make some examples of List-of-walls and List-of-dots.
      (You don't need to give a data-def'n or template (since they are so similar to those for List-of-ghosts), though.)
  2. Collisions: For each of the functions, have (of course) 2-3 test cases. Two tests suffice for individual-collisions, since we have a well-tested helper overlap?collide? (from prev.hw); for lists, three tests should suffice: lists of length zero, one, and “many”. And the tests for list-of-length-0 is trivial, and the test for list-of-length-1 is similar to your earlier tests.
  3. Drawing functions:
  4. Write move-ghost : ghost, list-of-wall → ghost, which is like glide-ghost but accounting for walls:
    If gliding would end up colliding with a wall, then instead just4 set the ghost's direction to be the next direction from the list (cons "up" (cons "down" (cons "left" (cons "right" '())))). (In that case the ghost need not actually end up moving.5).
    Note: In lecture this week, we may writewrote straightforward functions for index-of and get-at, which then make writing a get-next easy.
  5. Similarly, write move-pacman : pacman, list-of-wall → pacman.
  6. Worlds:

    1. Define a “world” structure which contains one pacman, a list of dots, 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 update-world : world → world which returns a new world one “tick” later. For the moment, update-world can ignore collisions with dots, and it can leave the fleet-direction unchanged. We’ll fix those below.
  7. Write the function world-handle-key : world, keypress → world which returns a new world updated to handle the keypress. (Should be easy — mostly defers to pacman-handle-key, and your test cases will largely crib from that. Firing, however, will be part of this function.)
  8. Write the function draw-world : world -> image, which draws the world onto a blank background.
  9. 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 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?]
          )
and you can play your game.

1 Your final program doesn't need to include any "transitional" results from the template: For example, you don't need the stubbed-out version of a function from step 5. However, you should still have passed through this phase.      ↩
2 Your hw05 may use any/all of the hw04-soln; of course, cite any code you use like this (including a URL), just as would do for any purpose, hw or not.      ↩
3 But with higher-order-functions, you can still do some refactoring: you can say “we always do something with the two parts from the template: we either cons them together, or we return-second-arg-ignoring-first.” Personally, I think that refactoring does not make the code any simpler/clearer, but you're welcome to try it for your own personal practice (requires Intermediate Student). Anonymous functions can be helpful here.      ↩
4 If you want to have the ghost move “intelligently” so it chooses a direction that moves it towards the pacman, that's great!, but not required.      ↩
5 You are welcome to still have the ghost move when it hits the wall, but it's tougher because you might need to try several next directions until you find one that works. That would be easy enough with a helper function, but it's also find to pretend that after bumping their head on a wall, the ghost is momentarily stunned.      ↩

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

logo for creative commons by-attribution license
This page licensed CC-BY 4.0 Ian Barland
Page last generated 		Please mail any suggestions
(incl. typos, broken links)
to ibarlandradford.edu		 Rendered by Racket.