[Haskell-cafe] Input Handling, Callbacks, State Machines

Heinrich Apfelmus apfelmus at quantentunnel.de
Sun Nov 4 10:43:09 CET 2012


Daniel Trstenjak wrote:
> Hi all,
> 
> I'm currently struggling in the search for a nice abstraction for the
> input handling of a game (it's a simple platformer with rectangular platforms).
> 
> One good example is the level editor of the game. When pressing the left
> mouse button the creation of a new platform is started. As long as the
> mouse button is hold the platform can be resized by moving the mouse.
> When releasing the mouse button the platform is created with the current shape.
> 
> The GUI library I'm using is GLFW. There are several callbacks for key,
> mouse button and mouse move events.
> 
> Firstly I would like to be able to describe application states, like
> the creation of a platform or the definition of the movement of a
> platform. The state might add something to the current level rendering
> and it changes temporary the callbacks. 
> 
> So in the case of a platform creation, the mouse move callback would just
> resize the platform, the mouse button callback awaits the button release
> and the key callback might only allow the quitting of the current creation.
> 
> Above the application states it would be nice to be able to describe the
> transition from one state to another.
> 
> Perhaps FRP might be a solution for this. But I'm still shying away of
> it, because a game might have some hairy state changes and I still don't
> see, how FRP makes life in this regard that much easier.

Indeed, this looks like a case for FRP to me. (Well, then again, I'm the 
author of the reactive-banana FRP library.)

You may want to have a look at Andreas Bernstein's  breakout  clone

   https://github.com/bernstein/breakout

which implements a small game using reactive-banana.


As for complicated state changes, the worst thing that can happen is 
that your FRP code becomes as messy as the imperative equivalent, but 
the thing is that it cannot get any messier because you can translate it 
rather directly, so you don't lose anything.


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com




More information about the Haskell-Cafe mailing list