[Haskell-cafe] Implementing PacMan

Ryan Ingram ryani.spam at gmail.com
Wed Dec 17 03:14:47 EST 2008

Oops, misread a bit.  I thought this was your series of posts, Andrew!
 But other than that, my points stand :)

  -- ryan

On Wed, Dec 17, 2008 at 12:13 AM, Ryan Ingram <ryani.spam at gmail.com> wrote:
> In the last "episode" you talk about an entity's update being a function like:
>> input_state -> (output_state, [event])
> for some suitably defined types of input state, output state, and event.
> Connecting together functions with types like this is exactly what
> Reactive does well.  You have an event stream representing the
> behavior of the user during the course of the game, and you use that
> to construct other values representing the *behavior* of the game.
> The key difference is that instead of the game's behavior being a set
> of functions from input to output, it is functions from one behavior
> to another, eventually culminating in something like
>> -- "user input", "clock tick"; output a new display list at each clock tick
>> game :: Event UserInput -> Event () -> Reactive [RenderCommand]
> In fact, I think your analysis in the first message is somewhat right
> on; this exercise is somewhat like "writing a novel without using the
> letter 'e'".  The benefits you get from a pure language are not
> necessarily "lack of effects", but rather, "explicitly mentioning
> where effects happen".
> That said, I'm curious where you are going with it.  I'd love to see
> the game running & take a look at your code!
>  -- ryan
> On Tue, Dec 16, 2008 at 12:43 PM, Andrew Coppin
> <andrewcoppin at btinternet.com> wrote:
>> 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?
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list