Daniel Trstenjak | 3 Nov 13:12 2012
Picon

Input Handling, Callbacks, State Machines


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're 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.

(Continue reading)

Benjamin Edwards | 3 Nov 14:09 2012
Picon

Re: Input Handling, Callbacks, State Machines

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Heinrich Apfelmus | 4 Nov 10:43 2012
Picon

Re: Input Handling, Callbacks, State Machines

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

Gmane