Generating Code To Embed in an Event Loop

I've been thinking about how I could use Haskell for programming just the "business logic" for games. So for a mobile game I might use an existing library such as libgdx or cocos2d for input handling and sprite batching. Where I'd like to use Haskell is for writing the big function to process the inputs and output a sprite list and audio triggers. Why Haskell? In even a simple 2d platformer there's a lot of polish needed to get the game to feel good to a player. For instance, if I was using box2d physics to take care of movement and collisions, I might still need to detect that inputs indicate applying a force vector opposite to the player's current velocity and the player is "on the floor". A naive game would show the player moon walking. A more sophisticated game would show a skidding player sprite or animation until the player's velocity reaches 0. I was hoping to use Haskell to capture a lot of little details like that more elegantly than I can in C or Java. However, my program needs to be compiled for a mobile device. I'm wary of trying to use GHC to generate arm machine code. I've had bad luck with cross compilers. It seemed to me that I could design a GADT to model my game actors and their relationships. I would then (misused term I'm sure) "lift" my behavior functions into some context where they can produce Java or C code for use in Xcode or Eclipse. That's my favored approach. Is there some background I could look at to save myself some dead ends pursuing this? -- Darrin

Hi Darrin The more typical scenario is to embed a "higher level" scripting language within a game (Lua has been particularly popular) rather use a higher level language to generate low level code. Pragmatically, code generation works well in domains where you have a succint input format and many candidates to generate - parser generators like YACC or Haskell's Happy are prime examples. If you don't have many candidates for generating, writing good libraries in the low-level language seems a more profficient use of one's time.

On Tue, Oct 25, 2011 at 6:08 PM, Stephen Tetley
Pragmatically, code generation works well in domains where you have a succint input format and many candidates to generate - parser generators like YACC or Haskell's Happy are prime examples. If you don't have many candidates for generating, writing good libraries in the low-level language seems a more profficient use of one's time.
Can you elaborate on why? Is it because code generation is a lot harder than it looks? Or that it's a lot of tedious work for just one output program? -- Darrin

Hi Darrin I'd contend code generation isn't particularly hard or even tedious, but there are two big problems. One, its inflexible - its almost always easier to change code in the target language than a generator. Two, in essence a generator already contains the target program plus the scaffolding to generate it. If you don't have many variations to generate it is more work (often much more work) to make a generator rather than hand code the target language program. Best wishes Stephen
participants (2)
-
Darrin Thompson
-
Stephen Tetley