Un-lazy-fying clojure

I’m finding Clojure has a similar feel to C++ about it – it requires a higher degree of understanding of the underlying implementation than I think is probably optimal. Partly this could be because it’s a new language – but it’s also what makes it interesting.

A common problem I’m having is running out of Java stack due to lazy structures – this is a problem in a game or simulation loop such as Germination X, where if the values are not used by something they are never evaluated (which saves cycles) and hang around (using up memory).

Luckily Clojure comes with (doall) which forces the evaluation of a lazy sequence – however it’s not recursive and *only* works on sequences. This function is recursive, and also calls itself on all the values contained in hash-maps:

; force all sequences and maps to un-lazy
(defn doall-recur [s]
   (map? s) (reduce
             (fn [r i]
               (merge {(first i)
                       (doall-recur (second i))} r))
             {} s)
   (seq? s) (doall
             (map doall-recur
   :else s))

Clip Kino

Last week I attended a Clip Kino event at Alto University’s Media Factory. Clip Kino is a concept to use online video as a focus for events and talks via informal screenings. The ease of access of vast amounts of online video makes this a fast way to research ideas, and doing it in small groups means that a conversational approach quickly emerges – which worked well in this event, called Clip Camp:

Clip Camp is a format that merges open sharing events, such as BarCamp, with online video culture. The event is an experiment in methodology, creating a cross between a seminar room, a short video-clip festival and an offline discussion forum about online materials.

There is a good write up of the presentations on the media factory blog.

Game designin’ (GX)

Before I can make full use of the characters in Germination X, I need to think about the game itself, the social aspects – and how this interacts with the theme of companion planting.

This could be a very rich area to play around with, but it needs to start as simple as possible. I’m lucky in that I can make a lot of use of the research we covered as part of the Naked on Pluto project, and as ever, I have to start with plenty of drawings.

The design is focused on three main priorities:

  • Getting people working together (co-operative play).
  • Do this in a world organised by companion planting.
  • Integrate the world with the FAtiMA AI system, and make use of the notions of social awareness encoded within it

I’m also trying one well used casual game mechanic – a time based restriction, where some “energy” or “karma” is used up by actions (planting), and then slowly recharged. This is required in order to make cooperation necessary – people will be able to request help from other players who have more energy/karma and may choose to plant beneficial companion plants near to their ill plants. This could perhaps be rewarded by being given a larger reserve of planting energy if you do this.

I’m particularly interested in the interaction of these game mechanics, and finding some sort of minimum to achieve engagement. For example I’m quite against explicitly punishing “bad behavior” (in this case planting harmful plants near other player’s plants) and seeing how this might be explored by players in practice.

“Emotional colours” in Germination X

Most of the work on Germination X over the last two weeks has been upgrading FAtiMA to the new modular version developed for Lirec. This uses a little more memory than the previous version, so I’m only running one spirit in the game at the moment. I’ve also made a fix for Internet Explorer which wasn’t working properly with the game.

Over the last few days I’ve had some time to try using some of the non-facial emotional cues I talked about previously – specifically the use of colour. In the screenshot above the character is emitting coloured particles based on it’s predominant emotion (in this case Joy). One of the areas I want to focus on over the next couple of months is how to express emotions with these simple characters in ways that may be quite abstract.

Scheme Bricks on Android

A screenshot of scheme bricks running on android. Its actually the next version of scheme bricks really, as it’s been subject to a major rewrite. The original was pretty cluttered with lots of last minute pre-going-on-stage hacks and additions. As in the original, the touchscreen expression selection works by ray casting into the 3D scene with (geo/line-intersect) which is now part of android fluxus, but no dragging or dropping – the fun bit – or even fonts yet.

Still it’s somewhat satisfying to work on fluxus scheme code that runs on Linux, Mac, Windows, Android and PS2!

Reading/writing clojure

Revisiting my clojure frustrations, I was having problems getting things saved out to be recreated properly when loaded back in. This is something you take for granted perhaps, as a scheme programmer – but by restricting the set of containers I use, I’ve managed to get the right behavior from clojure.

user=> (def a (hash-map :number 43 :list () :string "hello"))
user=> (spit "test.txt" a)
user=> (slurp "test.txt")
"{:string \"hello\", :list (), :number 43}"
user=> (read-string (slurp "test.txt"))
{:string "hello", :list (), :number 43}
user=> (:number (read-string (slurp "test.txt")))

As originally suggested by Sam – if I save a hash-map, I get one back when I parse the text – same for lists or normal data. This isn’t the case for struct-maps or records which I tried before. I can also do versioning with hash-maps, where one of the fields is the version number, and structures can change without breaking file compatibility. When you load an old version, you can automatically detect this and convert it on the fly by adding default values for new data, or removing old stuff.

This is essential for production work, especially with an online game – as you need to keep file formats and data structures flexible while doing the upgrades in an quick automated way to match the code which is running.

Here is a section of the Naked on Pluto code (in scheme, but the process will be similar in clojure for Germination X) it gives you an idea of the kind of changes we made throughout the development process:

(let* ((f (open-input-file filename))
         (l (read f)) ; read the file
         (v (car l)) ; first item is the version
         (g (cadr l))) ; second item is the graph
    ; the version allows us to preprocess the graph to fix
    ; things which have changed. do this here.
    (let ((g (if (< v 1) (add-vocab-to-nodes g) g)))
      (let ((g (if (< v 2) (add-message-types g) g)))
        (let ((g (if (< v 3) (add-bot-timers g) g)))
          (let ((g (if (< v 4) (add-old-messages-to-nodes g) g)))
            (let ((g (if (< v 5) (remove-dir-from-edges g) g)))
              (let ((g (if (< v 6) (add-hatface g) g)))
                (let ((g (if (< v 7) (add-votes g) g)))
                    ; g is now up to date, whatever the version was we loaded