Originally Rob Hordijk invited me to help present his synth designs at the open house at The Villa (a local squat inhabited mostly by artists). I suggested I present the visualiser I started building in Fluxus by slowly adding bits that resulted form practising livecoding. This could react to the sound of the synths. I talked this over with Rob Bothof and we resolved more interaction would be nicer. I still had a big “emergency” red button in reserve that I found before, I could use that. Rob also had one on loan, so there could be two buttons. This led to the idea of a two button game for two players and the original plan for a visualiser was more or less lost.

While installing a installation for Nescivi (who builds rather large installations, compared to her own size!) we went over our options. Rob suggested we could use duelling cowboys as a theme, where you had to draw quickly, but not too quickly. A nice theme and simple enough for just one button each, but would it hold the attention? I suggested extending it to two catapults. Pushing your button would charge your catapult, releasing would fire. Now the question was how to keep this from degrading into just two players firing as quickly as possible; to me two player games should be about interaction. With some more coffee and brain-storming while building Nescivi’s intallation the idea of “counter-shots” emerged; instead of only hitting your opponent you would also be able to hit his projectiles so skilful reactive play could reflect shots back at your opponent. Not that far from the original “cowboy” idea, but with more space for variation.

With this we had a plan and we had a deadline. Both of us started work. I started with the curve for the catapults arm. This was a entirely arbitrary point to start out with but I felt a good curve there could make the expected trajectory clear to the player and in my experience Fluxus is good with “start anywhere and work from there” design structures as you can just update and add anything while it all runs. This is what I came up with;

In the meantime Rob started work on skyscrapers to hold the buttons;

These were meant to hold lights, indicating when a player was hit. The scope of our project was clearly escalating and I felt like I was lagging behind a bit. Most of my time was spend reading up on classes in Racket (the version of Scheme that Fluxus is based on). I felt that using classes would help prevent the code from becoming a mess.

I moved my computer to Rob’s workspace where we began to hold long (16 hour per day or so) sessions of Rob modelling scenery and me programming. Every few hours we’d import the latest version of the models into the game and discuss how it all worked out. Here is a prototype;

By now we discovered that this process of parallel  work on code and models with a very short cycle suited us. Despite a few Fluxus bugs (fixed at a matching rate by the ever-helpful Gabor Papp) Fluxus also turned out to be a great tool for this kind of process. The game-play was taking shape by now. Charging for a long time would yield a large projectile that would fly nearly horizontally and do a lot of damage. These would be easy to counter by briefly charged shots aimed for the projectile so they would be high-risk. Charging your shot  for less time would yield smaller projectiles that would fly so high they would be (nearly) impossible to counter yet in turn would be defenceless against the low, big projectiles. The aim here was a realtime version of “rock, paper, scissors”, a popular foundation for computer games from StreetFighter to StarCraft. I tested and re-balanced these mechanics playing for both sides with the mouse buttons as the actual button interface wasn’t yet ready.

Even in this early stage the game was fun, interestingly slow moving projectiles give more tension to the gameplay than fast-moving ones would. At this stage we also had some amusing debates about what behaviour was “unrealistic”, a rather vague term as all of the physics are quite unrealistic. I suppose that what we ended up with was more “consistent” than “realistic”, probably a more important factor.

With a few more days of programming to add things like destructible buildings and code to verify who would win, as well as a lot of new models for the background and different models for different projectile sizes we were ready -just in time- to present the game.

It didn’t have all the features that we wanted, but it looked good and it was fun. This was also the first time our game really got exposed to new people and it showed a few things. First of all it probably needs a small manual to show while waiting for players. Many people didn’t figure out on their own that they could hold their button for a longer time to charge-up more. The countdown timer that shows how much time is left in the match probably needs to be a lot bigger; people missed it entirely and were surprised when it ran out and the game ended. Everybody wanted to shoot the Zeppelin. Surprisingly these turned out to be much bigger issues to our audience than the lack of balance that led to rather simple strategies once more competitive and persistent players figured them out; these players still had fun perfecting those strategies.

We’ll have to fix those things, as well as “pimp” it all some more, but some things are already starting to show. Fluxus is nice for quickly designing and implementing games. Changing parts of the game, while it runs, is great fun and quite practical. It was also great to see how a very simple game, with a extremely simple interface can draw people of nearly any background in and entertain them.  Not at all bad for about a week’s work.

Thanks to all at De Villa for the space, Gabor for the quick fixes to Fluxus, Nescivi for the board we used to turn button presses into MIDI and Rob Hordijk for transporting all of the stuff and his patience when it was done half a hour late.

We’ll be back :¬).

Then there will be errors. Lots of them. And cursing.

Editors for livecoding systems tend to look flashy, presenting both the code and its results in a stylised manner, attempting to turn the whole of the programming process into a sort of play. That is; until something goes wrong, then we might feel like some piece of décor came falling down and we are exposed to  the wood and cables behind it all. I don’t think this need be that way. Errors are great; errors allow for growth, for discovery and for learning about the system we use. Errors tell us about what we thought we knew yet don’t -yet- and help us learn. If livecoding is to expose the artistic process, as opposed to merely exposing the methods employed, errors and their cousin the debug-print should demand their centre-stage role. Similarly, programmers shouldn’t need to break the flow of their process for longer than is strictly necessary to notice something is wrong, diagnose the issue and remedy it.

Let’s focus on Fluxus. I’ve been writing quite a bit of Fluxus lately and recently discovered that Scheme (which Fluxus is based on) allows us to define how we’d like to deal with errors right in the language itself. Fluxus, on top of that, provides us with ways of turning text into 3d objects placed in the Open-GL scene the system creates. With some routing and hackery we can re-route the error messages into the main scene, instead of the somewhat out of the way repl, fully exposed to the audience and without a need for the programmer to switch screens and find them in a small font at the bottom of a likely dense page where the programmer instantly finds them, leaving the audience wondering.

Here’s a example;

Here my code is in white. First it asks Fluxus to build a cube, which works fine as Fluxus knows (build-cube). Then it requests a unicorn, which fails as Fluxus doesn’t know anything about that animal. If I wanted to build one I would have to define what they are like, hence Fluxus generates a error message. My code catches this message, scales it to be as large as possible and puts it on the screen, in the editor’s font, behind the code yet before stuff like the cube. It’s still a bit crude, but it works and it’s fun.

Here’s the code; dramatic_errors

Add that to your .fluxus.scm and from there on (display) and any errors will be printed right to the scene itself. (clear-print) will get rid of them again (hopefully we’ll think of a more clever way of removing them soon). Edit, remix, debate on the list. No warranties, no refunds.

To explain for international readers ; “bouwt” means “builds”, though in Dutch, at the end of a sentence it could also be read as a order; “build!”. I made this impulsively in the then freshly squatted Asta (a former cinema, now a unused dance club here in The Hague, lately squatted,in protest, by a group of local cultural organisations). I’d like to talk for a moment about the process of making it.

Last Tuesday morning I walked into The Asta, still a bit hungover from the BBQ the night before; a BBQ that had the dual purpose of  celebrating The Asta being back in use and cooking the food leftover from the IFM festival. I had followed a call to help clean the building, cleaning isn’t much fun, but this seemed like a good moment to roll up my sleeves. Tuesday was also the day the Dutch government was set to vote on the law against squatting and some groups had called -using rather aggressive imagery and phrasings- for protests. I was instead more interested in a demonstration, a demonstration of what can be done with a empty building and little to no budget. Much like the cultural organisations who took the initiative I feel there is a urgent need for space, in the centre of the city, where artists can perform/exhibit/experiment without economic factors or the (sometimes) restrictive atmosphere of regular clubs limiting them too much.

As I walked in I saw my friend (and occasional opponent in debate) Olof van Winden being interviewed by local television. I thought it best to stand back, but the interviewer (and camera-woman) invited me to help explain the link between the (in)famous local elektro scene and squatting, as well as share the idea that it seems profoundly counter-productive to put a stop to the one kind of self-sufficient cultural institute we have in a time of proposed budget cuts on culture. De Illusie was a rather convenient example.

I  took a broom to the alleyway-entrance and the hallway. A mess there would look unwelcoming to visitors and re-enforce stereotypes visiting journalists and their audience might have. More importantly it was a obvious first step towards making the place inhabitable and usable as a stage for whatever exhibitions, concerts and performances were to follow.

After a few hours I got bored of the broom and was wondering how I could do something more interesting with the (rather large amount of) local trash so I started exploring. In a dark and messy side-room, amongst debris, I found a few old banners that I unfolded, hoping they might hold something amusing. One had the name “The Hague” (as well as a company name), another had “bouwt!” (and more advertising) and a third was rather boring to me (later its reverse side was used as a canvas). I thought about joining the two words  but wasn’t so sure I should; was this meaningful? Was it worth the effort? Contemplating this I strolled around more. I grabbed a beer and didn’t feel like joining either the people talking on the stage or the others updating social media on their laptops. Funny how everyone gravitated towards sitting on the stage, even in front of a empty floor. I wanted more activity and so took the free floor space to join the two banners (combined they were several square meter so I needed a lot of space). Spread out like that I quite liked the word “bouwt”, it seemed like a nicely constructive counterpoint to the word “kraak” (the Dutch word for “squatting”, literally; “cracking”). It seemed to me to be a pleasant contrast against the destruction implied by the mess we were inhabiting at the moment, as well as the destructive spirit, commonly, but typically mistakenly, associated with the squatting movement.

No means of stitching these together were at hand, so the only option I saw was creating a wooden frame, and bolting everything to it with screws. As I started hauling around wood (more found material) something quite interesting happened; about half a dozen people spontaneously asked me whether I needed help. Perhaps they too were looking for something fun to do. Perhaps they too liked to build stuff together and see where you end up. With this small team of welcome volunteers, some of which I hadn’t seen before, others I already knew, some having professional experience in construction, others holding a electric screwdriver for the first time, the banner was completed.

Once it was finished the simplicity and the size seemed to appeal to all, reinforcing the idea that we were constructing something together, that you can create nice things from abandoned materials and spaces, especially if you join forces.

What started as a rather simple project became – to me – a micro-level analogy for the squatting of the Asta. Sadly this is now all the more so because it’s looking like the appropriation of the building has turned into more of a message than a solution in itself; the building will have to be cleared because, according to the fire-department, it is extremely dangerous. This leaves a few questions; how did it get to be in this state that is supposed to be in grave and immediate danger of collapse, fires breaking out and heaven knows what else? Wouldn’t such a building form a danger to the surrounding buildings and the local population as well?

From that perspective we could almost call covering up the holes in the floor in a communal attempt to make the room safe a political act. To be perfectly honest though; I suspect I mainly like to build stuff.

Details on the Steim site.

Close to home we encountered a group of young men standing on a street-corner. One (of -I imagined- half Moroccan decent, aged between 12 and 15) eyed me, so I expected trouble and looked back. Instead of “trouble” I read a mixture of trouble and befuddlement in his face. We walk on and after about three steps I hear him say something behind me. “Are you brown or white?”, in an uncertain voice.  Neon street lights are great at efficiency and visibility yet weak at colour. I didn’t say a thing, but the question stuck with me. Not so much because I’m insecure about what the answer might be (facial recognition experts tell me we are -mostly- all the same colour with different saturation values, mine is fairly unsaturated) but because apparently he needed the answer to this to determine how to respond to my presence on “his” street-corner.

I imagine this must get tricky around there, a lot of the time. I’m sure worse cases than Frisian sporting ‘fro’s cross his territory on a daily basis.  Poor thing.

I’ll be presenting the “Gate” installation that I made last summer as well as project a version of my Fluxus village that should react to the sound. This will hopefully turn the exhibition onto a sort of playground. If it all gets done in time….

herderinnestraat 16 – den haag

Stop by.

Rob&me have been playing sets each using our own homebrew sequencer and taking turns playing a song. We find that more interesting than playing a solo set each; at times we challenge each other, at other moment we can act as a safety net.

Stop by if you’re around.

> Sweet, you’re trying it with LuaJIT! In the README where I say “try
> LuaJIT for extra speed” I really mean it. If you TRY it, I’m very
> interested in how it works out.

Ok, so this is “bleeding edge” in the sense that actual cutting will
be done. Ok, got that. And I don’t know Lua. And I only understand the
bits of C++ that work like ChucK. Great, business as usual, then. I’ll
try this normally first and if that doesn’t work we’ll add fire to the
situation and see whether that improves anything.