Planet Open Ghana

In two weeks, the eighth „Gulasch-Programmier-Nacht“ will be held in Karlsruhe, a yearly geek event  by the Entropia e.V, which is the local CCC club. It will, as usually, offer a lot of interesting talks and events. One of my personal highlights have always been the programming games: Games, where you write your own code to compete against others, while the playing field is projected in the hacking area. The last few years, dividuum has done a great job providing these (as regular readers of my blog might remember).

This year, I’m trying to follow in his footsteps and will provide the programming game, called „L-seed“. This blog post is an introduction (and a call for contribution, at the bottom of the post :-))

The idea

The participants will write code (the „genome“) that describes how plants (the biological type, not the industrial) will grow. The plants will grow simultaneously on the screen (the „garden“), will compete for light and will multiply. The players can not change the code of a growing plant, but they do have the chance to update their code for the next generation – when a plant drops a seed, it will run the newest code. All in all, the game aims to be slowly paced and relaxing, something to just watch for a while and something that does not need constant attention by the players. The score is based on the total amount of biomass produced, but I expect (and hope) that some players will aim for the most beautiful or weirdest shapes.

The plant code

In contrast to the previous years, this year’s game will not allow player to use a full-fledged Turing-complete programming language, but a rather minimalistic rule based language to describe the plant’s growth. Especially, it will be hard to coordinate different branches of the same plant: Information mostly flows from the leaves to the root, and not the other direction.

The simplest plant is based on this code:

// This is the trivial plant, which just grows and grows
RULE "Very simple Rule"
GROW BY 1

You can see that each rule has a name (which is purely informational), and an action which tells the current branch to, well, grow by one. The syntax allows for Java-style comments, whitespace and newlines are insignificant and the reserved words are case-insensitive. The result will be a plant that just grows straight up, for ever and ever. A more complex rule might be this:

RULE "Start"
WHEN Length <= 0
GROW BY 1
SET TAG = "Root1"

RULE "Story 1"
WHEN TAG = "Root1"
// No Percentage means 100%
BRANCH ANGLE = 70°, LENGTH = 2, Tag = ""
       ANGLE = -70°, LENGTH = 2, Tag = ""
       ANGLE = 0°, LENGTH = 1, TAG = "Root2"
SET TAG = ""

RULE "Story 2"
WHEN TAG = "Root2"
BRANCH AT 100% ANGLE = 70°, LENGTH = 1.5, Tag = ""
               ANGLE = -70°, LENGTH = 1.5, Tag = ""
               ANGLE = 0°, LENGTH = 1, TAG = "Root3"
SET TAG = ""

RULE "Story 3"
WHEN TAG = "Root3"
BRANCH AT 100% ANGLE = 70°, LENGTH = 1, Tag = ""
               ANGLE = -70°, LENGTH = 1, Tag = ""
               ANGLE = 0°, LENGTH = 1, TAG = "Root4"
SET TAG = ""

RULE "Story 4"
WHEN TAG = "Root4"
BRANCH AT 100% ANGLE = 70°, LENGTH = 0.5, Tag = ""
               ANGLE = -70°, LENGTH = 0.5, Tag = ""
               ANGLE = 0°, LENGTH = 0.5, Tag = "Tip"
SET TAG = ""

RULE "Star"
WHEN TAG = "Tip"
Blossom

I added a picture with the resulting tree. The yellow blob at the top is a not-yet-polished rendering of a blossom. At the right, there is already the first offspring of the plant. One thing to keep in mind while writing a genome is that rules are applied to single branches, and not the whole plant. The program will, for each branch individually, check which rules apply and choose one.  I’ll skip a detailed description of the syntax here, eventually you will find proper documentation on the entropia wiki page. You can find more examples in the source repository.

The gameplay

The players will register at a website providing the usual CRUD functionality for their code, with integrated syntax checking. They can have more than one code at the same time, but only one can be marked as „active.“ The program actually serving the projector will regularly fetch the active code and run a around (called „season“) of the game. Whenever a new seed grows, the program will get the possibly updated active code of that user and use that. A season will probably last for a fixed amount of time, and at the end the total biomass accumulated by each player is added up and written back to the database.

The game code

You can fetch the source code from my git repository and browse the haddock documentation. Unsurprisingly, it is written in Haskell. To compile it yourself, you will need the GHC Haskell compiler, parsec version 3 and for the visualization the gtk2hs package, all of which are packaged in Debian unstable. The main.hs is the interesting program. You pass it one or more plants as an argument, and it will start the simulation. If it’s too slow for test runs, then reduce the dayLength variable in Lseed/Constants.hs. If you have trouble getting it to run, just talk to me.

The call for help

As you can see in the picture above, the graphical output is not very aesthetic. I am no artist, and I don’t pretend to be one. So, if you think you have the right touch, maybe know OpenGL and a bit of Haskell, I’d be very grateful if you make it look better. The UI interface is quite simple: You need to have a module that returns an Observer value, which contains a few callbacks for various situations. The code in Lseed/Renderer/Cairo.hs can of course be used as a guideline. I’m suggesting OpenGL because my code is not only ugly, it is also too slow very quickly. If you need any help, just contact me by mail or jabber.

I’m also interested in comments about the game balance, and the expressiveness of the programming language. If you play around with the code and discover that there are missing features in the language, or that your plants grow too fast or too slow, or when you discover bugs, please also tell me.

Thanks

L-seed is based on an old idea of mine, advanced together with Cupe, Sven Hecht is programming the web interface, and Lay is testing the game and bugs me about it to keep the motivation going.

Update: I uploaded the package to hackage, to encourage contributions.

My contribution to the programming contest held by the German „FreiesMagazin“ got a third place out of 13 submissions. This is quite good, considering that I only wrote a small wrapper around the generic game-tree Haskell library by Colin Adams, and hardly gave any serious thought into the problem.

All entires are available for download. I have annotated the table containing the results with the line count as given by ohcount:

Note that the line count for my haskell program includes the game-tree library, which I bundled in my submission. Without it, it’s 156 lines of code I had to write, which is second best in the code golf category.

If you look at the timing statistics, you will see that my program took the longest. When the contest was started, the timelimit was one minute per round – which I of course tried to use as much as possibly, by increasing the search tree depth. Later into the contest, the rules were changed to limit it to one minute for a whole game, and that long-running programs will get points deducted. I did some minor changes based on a profiling run, but did otherwise not care too much about performance. I would have tried to improve the runtime by using Haskell’s good ability for parallelization. But when I asked on what kind of machine the code will be run, but they would not tell me. They said that this is a hobby programmer’s contest where allowing for parallelization were not fair, so I did not work in that direction.

All in all it was a positive experience, showing of Haskell’s qualities as a language that you can quickly get good results with.

Thanks Behdad for pointing out this interesting advertisement campaign by HSBC. I’m very surprised how a word, printed on top of an image, can completely reverse the impression that the image makes on you.