[PRL] Pac-Man's Ghost Behavior Analyzed and Fixed

Matthias Felleisen matthias at ccs.neu.edu
Sat Dec 4 14:51:51 EST 2010


The first para seems to be enough to suggest a contractual solution: 

> In the videogame Pac-Man (and in many of its sequels and clones), it has been previously established that the ghosts, Pinky and Inky, track Pac-Man by examining the direction he is facing and use that information as part of their determination of their respective targets.  For example, Pinky usually targets the location four tiles in front of Pac-Man's location.  However, if Pac-Man is facing up, this location becomes four up and four to the left of Pac-Man's location.  Inky has a similar change in his targeting when Pac-Man is facing up.  Why do Pinky and Inky have different behaviors when Pac-Man is facing up?


Say Pinky and Inky are instances of a class InkyPinky and that this class comes with a method that determines where PacMan is: 

 class InkyPinky 

   RegionOfLocations whereIsPacMan() 

I could imagine a TYPED solution if RegionOfLocations is a class that specifies exactly four locations. If the four are specified in such a way that they can only represent a straight line, all the information is in the type. 

If the choice is to make four independent locations, I would expect a class invariant that ensures a straight-line relationship among the four locations. This would be a contractual solution, because it would be checked after the constructor is done. 

Hope this answers your question in principle -- Matthias






On Dec 4, 2010, at 1:34 AM, Doug Orleans wrote:

> This is from a couple years ago, but I just ran across it:
> 
> http://donhodges.com/pacman_pinky_explanation.htm
> 
> It's a dissection of a bug in the Z80 programming for the "Pinky"
> ghost's behavior in the original Pac-Man.  Note that there's a slight
> inaccuracy in his description of the bug behavior; see if you can spot
> it!
> 
> I'm wondering if there's a moral in here for modern programmers (or
> programming language designers).  Like, what kind of type system would
> detect the type error in this code, assuming the programmer defined
> the types accurately?
> 
> --Doug
> 
> _______________________________________________
> PRL mailing list
> PRL at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/prl




More information about the PRL mailing list