WARNING: This is a development post. So if you're not into programming, you might find it pretty boring...
 
Some days ago, I wrote a data type and an equality-like function similar to this:

data Edge a = Edge {from :: a, to :: a}

(=~=) :: Eq a => Edge a -> Edge a -> Bool
a =~= b = from a == to b && to a == from b

Then I wrote a short comment about what the function does:

-- a =~= b = from a == to b && to a == from b

Then I realized, I had just exactly reproduced the functions implementation in the comment. Hurrah for Haskell! (once again)

WARNING: This is a development post. So if you're not into programming, you might find it pretty boring...
 
I am glad, I am not the only one thinking that Haskell can be very complicated at times. This is an error message the ghc just gave me:
 

My brain just exploded.
    I can't handle pattern bindings for [...]

WARNING: This is a development post. So if you're not into programming, you might find it rather boring... although this time, we also have a nice video!
 
Currently we are working on moving platforms. Everybody who played 2-dimensional platform games knows them and surely we wanted to include them in our game. So we were faced with the question of how our platforms should be modeled, or more precisely, how the behavior of our platforms should be programmed. The naive approach would be to just calculate the position from a given platform path and then set the position every frame. This does not play well (and wouldn't feel right) with a physics engine, though. So we have to come up with a way to control our physical object without being to intrusive. Most of the times, this boils down to manipulating neither the position nor the velocity of an object, but apply a force to it. So, when modeling platforms, we currently have three forces:

• anti-gravity - Since we don't want our platforms to fall down and just lie on the ground, we apply a force, that is exactly the negative of the gravitational force. At first sight, that sounds very fancy. And of course, it is.
• drag - This is the force that slows down a moving object in a fluid or gaseous medium. (German) wikipedia says it has either a linear or a quadratic dependence on the velocity of the moving object. (Well, at least approximately.) Of course, Wikipedia only talks about 3-dimensional physics - in heavy violation of their neutral point of view policy ;). So what about 2-dimensional fluid drag? Any ideas? Anybody wants to conduct experiments involving two close glass plates with a fluid and flat objects between them? Sounds like fun. I digress.
• magical pushing-where-the-platform-should-go force - well, yeah, that's what it is.

This video shows an early version of the platforms:
 

 
The lines on the left depict vectors for debugging purposes:

• yellow is the velocity of the platform,
• blue the applied drag and
• red the applied force towards the intended position.

As you can see, the platform is moving rather awkwardly and can't support Nikki's weight yet. So there is still some tweaking to do, to make platforms behave nicely. But we believe that our approach is right: Interfering with a physics simulation while running in order to control its objects is always a bit strange and deus-ex-machina-like. But if you try to realize a concept in a physically sound way, you have the chance of getting something that still feels very natural.
 
We will talk about this again, as soon as the platforms are looking better!

WARNING: This is a development post. So if you're not into programming, you might find it pretty boring...
 
When programming, I am not using an IDE, but a combination of programs. These include of course a text editor (kate) and a shell (zsh with this configuration). But there are also a lot of little helpers besides an editor and a shell, that can make your life a lot easier. I already wrote about graphmod, but due to popular demand (just kidding) I intend to write some blog posts about other little helpers that I find useful. (And that aren't all haskell centric, like graphmod.)
 
The first one is ack. It's a replacement for grep. It has colored output, and you can specify, that it should only look for e.g. haskell source code files. Another nice option is --smart-case, which searches case insensitive, if there are no upper case characters in the search pattern. The debian package is called "ack-grep", due to a name clash, I think.
 
So, if you are feeling experimentational today (assuming you are a grep user and experimentational is a real word) give ack a try.

WARNING: This is a development post. So if you're not into programming, you might find it pretty boring...
 
In the last days, I tidied our code. One part was about restructuring the haskell modules. I used a tool called graphmod, that was (and still is) terribly useful. It allows you to create graphs showing the module dependencies of a haskell project:
 

 
That's already useful, but the graph is very big and therefore it's quite time consuming to analyse it. But as graphmod is free software, it was easy to modify the tool to be able to generate graphs that show only certain aspects of the module dependencies. Even better, the creator of graphmod, Iavor S. Diatchki, modified graphmod to accommodate my needs. (Thanks for that.) So now, graphs can be generated, that provide insights into the project structure, that are also easy to read. This one shows an overview of our project:
 

 
And this one shows only the Game module:
 
The tidying is not done, but it sure is more fun than it would have been without graphmod. Also, free software FTW!

For the next couple of weeks, we will be working together from Berlin and from Osaka. We are trying out Google Wave to bridge the long distance between Germany and Japan. We have only just started creating some waves, but it really looks like a very nice tool!

WARNING: This is a development post. So if you're not into programming, you might find it pretty boring...
 
Over the last weeks, I tried to find a good library for sound output. The library should be able to do the following:

• compile on all relevant platforms without to much hassle
• play background music from compressed files
• play sounds triggered by input events without notable lag (for jump sounds, etc.)

First, I looked at Phonon, which is a multimedia API that is part of Qt. But -- apart from being not quite finished and still somewhat buggy -- it's an API for playing multimedia content. That does exclude playing sounds in real time, which is of course something we need.
 
Then I gave SDL a try. On Linux it works very well. But I found compiling SDL on Windows XP rather painful, and I didn't manage to get it compiled with the DirectSound backend, which seems to be necessary to get a low latency for triggered sounds. (I think the backend that was used, is called "waveout", and always has a latency of at least 250ms).
 
At that point, I was not sure, if a nice and easy solution could be found at all... till i tried out SFML. It's meant to be a modern replacement for SDL. It's written in C++ (but has complete C-Bindings) and the project looks very alive. As usual, triggered sounds on Windows XP were being played with a lag. But the people at the SFML forums were quite helpful and suggested using the svn version. That version works fine both on Linux and Windows XP. So, after a long and painful search, Joyride Laboratories proudly presents the sound library, that we will most probably use:
 
SMFL 2.0
 
That is, if it also works nicely on Windows Vista, Windows 7 and Mac OS X.