I started this compo months in advance – I had been working on some libraries that I thought would be really useful for making games. I had written a soft FRP lib and a 2d vector-ish graphics library. I spent a LOT of time on those! Mostly reading white papers about polygon decomposition, path rendering and rasterization. I thought I would have very nice looking 2d vector graphics for my FRP game simulation.

At the last minute I read this post linked on reddit about an entity component system using extensible effects and I decided to try to use that as well.

I ended up loving the component system (though I’m still figuring out how to handle and sequence events). I ended up barely using my libraries *at all*. I think I had been a victim of depth-first development. I got really deep into figuring out how to decompose polygons and do very low-level things when I should have been thinking about Haskell game dev as a whole. I should have been writing one specific game, then writing another specific game (and then another) and then library-izing the parts that are shared and good. Instead I had an idea like “hey, this would be cool to use for game dev – I’ll dive deep into building this out.” I also had strong intuitions about what a good API would be for those libraries and I worked hard to materialize them. I thought “yes! this is pure and clean and good!” – but once I started the compo I realized that I wasn’t using the libs in the way I had written them. I had over-theorized! What I really needed were dirty tricks and quick get-er-dones! This is a hard lesson and one that (admittedly) I’ve learned before.

In the next couple months I’ll be dedicated to developing games rather than developing libraries for games. By the next ludum dare I’ll hopefully have accumulated some tried and true techniques and dirty tricks.

To see the code I accumulated you can visit my github: https://github.com/schell/ld31.