In the last weeks I've been re-structuring FunGEn completely (that's why it is taking so long for version 0.2 to be released). I read Mark's CGL (Clean Game Library) thesis and found a lot of useful information and ideas. The main objective is to make FunGEn a engine that deals much more with worlds/leves/objects SPECIFICATIONS rather than programming all the stuff in a IMPERATIVE way (actually, its first version had a little bit of it).
BTW, I've got no FunGEn feedback at all (apart from Sven's notes just after releasing)... :(
Sorry, I booked it as "great, but not down my alley" - didn't reckon that a game engine would build on a kind of scene graph as well, even if in 2d. How do you deal with animating the scene graph? The combination of declarative descriptions of scene graphs, animation, and reactivity were just what Fran was designed for, but it has traditionally posed some problems in efficient implementation. I think those have their source in unfortunate aspects of Fran's design which I'm currently trying to overcome. Guess I'll have to take a closer look at your stuff soon, but from your FunGEn 0.1 example at http://www.cin.ufpe.br/~haskell/fungen/example.html it seems you've got separate data structures describing the game resources, the collections of game objects and the possible inputs (the later bundled with their callbacks). The timing functionality looks like a thin wrapper around the two GLUT timing callbacks? The game object actions are then written as monadic actions with easy access to other objects' properties. If that summary is not too far off, FunGEn 0.1 is still a mixture of declarative and imperative descriptions. Will that change with FunGEn 0.2? Game hackers might welcome the familiar style (as long as noone tells them they'd be using monads;-). Cheers, Claus