Existential Processing

So let me just wade into some thoughts about programming and games that I’m barely qualified to make and which I can’t seem to frame very well anyway. But since I spent part of the weekend making a little game about whistling away the darkness, and since I can’t think of anything else, here we are.

I’ve been making a little game inspired by an assignment I gave to my programming class this week – specifically, I took the theme (Extinction) and the rough dimensions (a skinny, long screen), and tried to make a thing. Started off with the idea that you get chased down a hallway by “The Darkness” (deep!) and ultimately must succumb. (Meanwhile, in the background, the word “existence” changes to “extinction”, as a kind of heavy-handed aesthetic flourish.)

That game, while it looked nice once I implemented a more interesting “bubbling” darkness, was a touch simple. So then I implemented the idea that if you hit keys really fast, you can drive the darkness back… but only for as long as you do that. Eventually, you’re going to go extinct. That was easy of course. So then I thought to myself, how do you dispel darkness? And I answered: with whistling, obviously.

So began my journey into Fourier transformations and identifying whistling based on the frequency spectrum of a sound sample. It turns out that whistling has a pretty strong signature, because it’s nice and clustered around a frequency or frequencies, rather than all over the place like most sounds. By stealing stuff from the great wide internet, and bending it to my needs, I managed to write a fairly poor whistle-detector. So now in the game you whistle and the darkness recedes, and when you stop whistling, it starts coming for you again. A little toy world that ends in your inevitable extinguishment.

All of that to say that it’s really fun and interesting to implement toy/game worlds in code. This idea of being responsible for creating everything is a remarkable one. It’s not unlike writing fiction, say, but much more systematic and reliant on literally getting things right. If you write the wrong bit of code, the whole thing fails utterly (or might behave in the wrong way, or in an unexpected way) – I find it hard to think of good analogies to this in other forms of fiction or “world generation”. You have to decide what the avatar looks like, what the dark looks like, how fast things move, what counts as whistling, what whistling looks like, what colour the words should be… everything. That level of responsibility is, of course, simultaneously awesome and exhausting, a real “yay-boo” story if ever there was one.

And this is also where Processing, the language, comes in specifically. It seems to me that unlike certain other languages I might develop a game in, such as Flash or Unity or even GameMaker, Processing provides less of a framework or even just a disposition for things to be a particular way, for worlds to have a specific genre of form and function. Our tools have vast amounts of leverage on our imaginations, and I find this especially true of programming frameworks. Processing (and other languages like C or Java etc.) doesn’t really have an establish way that you should approach things (maybe other than the ontology and other implications of object oriented programming and, in Processing, a kind of default notion of “time” implicit in the basic program flow).

In part, I’m thinking about this to assuage some of the guilt I have felt at times over teaching Processing to the designers in my class. There’s a sense in which it’s not the easiest language to write games in – you don’t get very much for free. But there’s a sense in which it’s incredibly liberating to start from absolute zero and to make your world and your game from nothing. You could do anything, and hopefully you will. Something like,

In the beginning…

20 February 2011
← next words previous words →