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 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 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.
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.