Hi,
What do we think of this, folks?
http://prog21.dadgum.com/23.html
(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: http://www.haskell.org/haskellwiki/Frag 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 entities themselves. 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: http://www.haskell.org/sitewiki/images/f/f0/TMR-Issue12.pdf For a game like PacMan, I should think collision response is fairly straightforward, though! Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@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.