[Haskell-cafe] Implementing PacMan
nhn at Cs.Nott.AC.UK
Tue Dec 16 16:27:16 EST 2008
> What do we think of this, folks?
> (And the rest in the series, obviously.)
> To me, it seems that this plan would *work*... but it wouldn't be
very > eligant. You'd have the code to respond to user input and move
PacMan > in one place, the code for collision detection in other place, the
> code that decides what to *do* about a collision somewhere else, the
> code for drawing the animations in yet another place... If you wanted
> to change one game element, you'd have to make changes scattered all
> over the place. The whole thing seems messy, non-modular and
> non-composible to my ears.
> Thoughts, people?
Functional Reactive Programming (FRP) tends to, in principle, work
pretty well for this kind of application. At least it allows for
code that is very modular in many ways, includig when it comes to
the game state. See e.g. the paper "The Yampa Arcade" or the Haskell
game Frag which uses FRP for the game logic:
The page you referred to didn't seem to consider FRP?
Don't know if FRP would address all of your concerns. But as to
collisions, we can observe that this involves two or more entities and
is, from the perspective of each entity, something external. Thus
I don't think it's unreasonable that code handling collision detection
is done "somewhere else", meaning outside the code describing the game
As to how to respond to collisions, that can be
a great deal trickier, and may involve devising suitable interfaces
to allow the proper interaction of a set of object to be computed,
e.g. in a physical simulation, the masses and velocities of the
involved objects must be known. There was an interesting article
about building a "Physics Engine" in Haskell in issue 12 of the
monad reader that touched on physical collision detection and response:
For a game like PacMan, I should think collision response is fairly
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
More information about the Haskell-Cafe