[Haskell-cafe] Implementing PacMan

[Ryan Ingram]

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
>>
>