Haskell bindings for Gosu

By Maytsh Date 2010-09-15 15:41

I think I'm far enough to subject the project to a bit of commentary from the people that know Gosu... So here it goes.

I am currently thinking about how to best translate the very object-oriented approach of Gosu into something a Haskell programmer could work with. This is meant as an experiment: I don't know whether the result will actually be a usable game development environment. Especially because with all the power of functional programming you still have to live with the fact that state in purely functional languages is awkward. And games tend to involve a lot of state. We will see.

The project is registered at darcsden, in case anyone wants to have a look at it:
http://www.darcsden.org/scpmw/gosu

Actual installation should go somewhat like this:

  darcs get http://www.darcsden.org/scpmw/gosu
  cd gosu
  cabal install

(modulo cabal probably complaining about missing libraries that you need to install. Or missing Objective-C bits on Mac.)

There's also documentation, and I have started writing a tutorial in the style of the CppTutorial:
http://www.darcsden.org/scpmw/gosu/raw/doc/html/Gosu/index.html
http://www.darcsden.org/scpmw/gosu/raw/doc/html/Gosu/Gosu-Tutorial.html

The concrete status is that I have graphics, fonts and input stuff working on Linux, Windows and Mac OS X - with the latter being most problematic because I guess I will have to ship precompiled bits. Right now I'm going in tutorial order, so I will continue with the audio functions. After that I think I will polish it up and make it public (properly).

All sorts of comments welcome ;)

By AmIMeYet Date 2010-09-15 20:07

wow.. - just wow.
This is pretty awesome, although personally I can't stand to use it :P

I'll leave it to the rest to add some some more interesting comments ;)

By jlnr (dev) Date 2010-09-16 12:01

Are you planing to create CptnHaskell? I kinda enjoy looking at the Haskell game logic but I never really understand it. :D

By Maytsh Date 2010-09-16 13:44

We will see. There are quite a number of fun things you can try with this.

For example, I would be interested in seeing how I could integrate Hipmunk. If I'm reading the wiki page correctly, this would be even more natural for Haskell, as splitting the model (= data structures) from view/controllers (= controls) is something you will end up doing anyway. In this case, you have a great example why this is a good idea: Because you can use Hipmunk as a drop-in-replacement for your model, and have physics essentially for free :)

By jlnr (dev) Date 2010-09-16 14:14 Edited 2010-09-16 14:27

Speaking of spitting view and controllers—does it actually help that all rendering in Gosu can be done in a very functional style? I mean, it's not *really* side-effect free, but it somehow feels very close to it. At least I seldom have any side effects in rendering code except the actual .draw calls.

I also wonder if in a pure-Haskell Gosu, the actual Z ordering could easily be transferred to some optional monad so that people can ignore that feature more easily.

The idea of actually returning DrawOperation objects (without side-effects so far) instead of calling image.draw is one I had a long time ago anyway, mostly to make client/server coding more DRY. Not sure if that has much practical value though.

By Maytsh Date 2010-09-17 21:49

The framework uses the same GosuIO for drawing as for the rest... You could model it as some sort of pipeline with variable values going in and draw calls going out. But typical draw routines are so simple anyway that you don't have much room to exploit this kind of thing. Especially because this small sub-domain isn't really worth changing all the language rules for.

What exactly do you mean by "optional monad"? In my mind, the big upside of having the Z-order defined like this is that you don't have to order your draw calls explicitly. Your suggestion sounds like you want to un-do that?

By jlnr (dev) Date 2010-09-17 23:40

> In my mind, the big upside of having the Z-order defined like this is that you don't have to order your draw calls explicitly.

Well, half-way. In C++ and Ruby, stuff rendered on the same Z level is still drawn in the order you call draw(). So if you have a composite object and can predict the Z order, you don't need to actually increase the value for each draw op. This also means that for simple games you may not even need Z ordering (but Gosu still requires you to pass 0 or some number for every call).

I was just wondering, if—given Gosu couldn't do Z—the whole draw op ordering could be done more beautifully on the Haskell side or not. As I understand it, Haskell has pretty well-established mechanisms for that kind of ... well, ordering of side effects? :)

By Maytsh Date 2010-09-21 12:07

Well, yes, that's monads. They are pretty powerful in that you can write series of "statements" like "do bla; blub; bla" and have that "sequencing" mean whatever you want it to mean. Just look at GosuIO, which I use to have all statements pass the global state to each other so the programmer doesn't need to pass the "window" parameter manually (plus some more internal state).

But this isn't the magic solution for everything... The programmer wants to specify the drawing order, but also wants this to be fully composable. But this is hard: If one element has three draw calls "1 > 2 > 3" and another three others "1' > 2' > 3'", how do you compose them? Concatenation (1>2>3>1'>2'>3' or 1'>2'>3'>1>2>3) is the standard approach and not be flexible enough. The only possible way an upper layer can order the drawing calls without knowing anything about the lower elements is by using markers - just the way it is now.

Only thing I could think of would be to make the markers less global - provide some abstraction that automatically and dynamically gives you Z-levels by "splitting" levels. But to me, this doesn't sound very useful - typically your Z-levels are pretty static and having them as a top-level list actually makes the program easier to understand.

By Maytsh Date 2010-10-14 18:41 Edited 2010-10-16 13:49

Btw, here is my current stab at a translated captain game. Including strange comments, I was writing most of it on a night train. For your looking pleasure ;)

By Maytsh Date 2010-10-14 18:45

... and just realized that I actually implemented gem drawing twice. Oh well.

By erisdiscord Date 2010-09-16 13:26

You are insane. Take this as a compliment, please.

By Maytsh Date 2010-11-06 16:51

Okay, I now would expect the bindings to build on all platforms. So if someone has a Haskell installation lying around (or is willing to get one), it would be nice to know whether the following works:

  darcs get --lazy http://www.darcsden.org/scpmw/gosu
  cd gosu
  cabal install

... or more realistically: Exactly how horribly it fails. ;)

By jlnr (dev) Date 2010-11-09 17:18

581 MB for GHC alone? Is this the new TeX? :S …I know why I used to have my tiny cute hugs89 ;)

Can you post a ZIP or tar ball for those of us who don't have darcs installed?

By Maytsh Date 2010-11-10 11:59

Huh? Which one did you try? The platform on Mac is about 130 MB. On Windows it might be a bit more because it needs to bundle MinGW.

And hm, yes, but I would have to find some way to host it. Plus darcs is only "cabal install darcs" away, is that really a problem?

By jlnr (dev) Date 2010-11-10 12:06

Yeah the packed download is small, but the installer for GHC told me it'd install stuff just short of 600 MB :) If that's true then it must be something that compresses very well.

I can't wait to play around with it. I have no idea about darcs or cabal so that was not an obvious command for me to try :)