Computer Game (Alien Phenomenology?)

(Bear in mind that I hold myself utterly unaccountable for the random philosophical and idiotic ramblings I write here. It’s the only way to keep going.)

I’ve been reading Ian Bogost’s Alien Phenomenology the last couple of days, but even before this I’ve been wondering about a game for your computer rather than for you. (Probably this has been done a million times? I’ve of course read Juul’s Zero-Player Games and looked at some approaches to this like 4’33” of Uniqueness.) I like the idea of a game that your computer plays entirely without you.

But what that “means” is a pretty big question. What does it mean for a computer to “play” a game in the first place? It seems an odd thing to say. For instance, how would the computer “guess” an answer to a trivia question, say (just a random number?). How would a computer move its paddle to the “right” place in PONG? Perhaps we can appeal to Bernard Suits’ idea of “inefficient means” to claim it’s fair to (in code) hobble the computer’s ability to play perfectly?

So can we have a computer playing PONG without you? I guess we can. But will that be “interesting” for the computer? The game is deterministic, and the computer would just be “playing with itself” which sounds boring (well I mean in the most direct reading of that phrase – and as to the other reading, what the hell is that?). But if we don’t involve a human player, who could the computer play with? Or can we say that a computer can have a “split personality” and thus successfully play itself? Threaded play?

Could we involve processing time as a kind of limiting factor on the computer’s performance to make the game “more interesting” for the computer to play? Could we make it related, for instance, to the time the game loop takes to complete, rather than tying it to a framerate, for instance? Would that be “more fun” for the computer to play at if it involved the computer’s “ability” to process the game loop as fast as possible? (Or at least as fast as the declared framerate?)

Could we use the webcam or keypresses or some other input device to allow the human to provide “non-deterministic input” into the computer’s play, so that it might be “surprised” by what happens in the game?

I have no idea. The end.

(I had a pretty major gin and tonic before I wrote this. Can you tell?)

Hitting the Wall of Boring Code

Screen Shot 2015-01-19 at 18.14.51I’ve been prodding at making Sound System II over the past couple of days and not having much luck with it. The weird frustration here is that I have a pretty clear idea of what the game is meant to be in terms of its technical specifications and in terms of its conceptual “point”, but the actual task and process of writing the code to make those things is killing me with its dullness.

Hilariously, the times I feel more like this about a game I’m making is when I’m making an effort to implement something more or less “game-like” instead of my usual “game-esque” affairs. So this game involves something that looks like gameplay, has avatar movement and “enemies” moving in patterns and so on. And that’s what’s driving me mad with boredom. Likewise, all the game-like parts of, say, Jostle Parent and, frankly, all of You Say Jump I Say How High, to give two other examples, were the things that massively slowed me down. I just seem to find it very hard to care about traditional gameplay stuff, even when I need it for a game and it feels like it multiplies production time by a substantial factor.

This could be a defensive boredom, perhaps? As in, I’m bored to avoid facing the horrible truth that I’m horrible at this kind of coding? These “simple but not actually easy to achieve” effects are not for the likes of me. I look at something like Michael Brough’s Helix, for instance, and shudder with how complicated all the code for the little moving enemy things and the calculation of the circling look to me.

What is the solution to this? In the end, I’m guessing I can do this stuff I need to do, but wow how I wish I didn’t have to.

But what the game demands, the game gets, right?

4 Minimal Game Designs

I’m slated to talk about “minimal game design” during the talky bit before the global game jam kicks off at the Institute of Digital Games here in Malta. So I need to think about what that is, and how to talk about it in a way that might be helpful to a room full of people just about to make various games for two days.

My initial feeling was that I wanted to talk about ways to make games that would show how you could prioritise radically different perspectives – essentially so that everyone there (writers, coders, sound people, artists, etc.) could feel like they could “own” a game concept or be its core driving force, and to move away from the idea of “design” as this actual thing that someone should be doing – just seems so stuffy, especially in that context.

But that talk hasn’t been coming to me. Or rather, to do that talk I feel like I’d have to make games that proved this point, and while I’ve made some games that might fit the bill, it felt forced. So I think I’m not doing that one.

Instead my thought is to profile the last four games that I’ve released, Get X Avoid YMANIFESTSound System I, and Let’s Play: Let’s Play: Ancient Greek Punishment: Art Edition Edition since each one seems to have the qualities of “minimal design” and, really, each of them could have been produced as a jam game I think. They’re all very, very tightly scoped and while I did spend more than 48 hours on each of them, it probably wasn’t much more in most cases and I didn’t have (or want!) a team on any of them.

So these games should serve what is always the most crucial game jam rule: make something reallyreally small and then build outward if you manage to finish that very small thing. Or just stop and relax, you know? Anyway, probably not enough to just say “I made these four games”, I should also think of things about each game that’s interesting or helpful in some way. Look at me, using this blog post to sneakily stream-of-consciousness my way to talk content. So here’s an attempt.

Get X Avoid Y. Code reuse! I had thought about including PONGS as a lesson in small variations of simple code, but this game is almost better because it’s large (aesthetic) variations on exactly the same code. Great game for artists (including sound if it had sound effects!) because it’s really just a content-production exercise. Great game for a programmer to have a fairly calm experience of the jam. So one good jam style game is to make a very small thing that focuses on content.

MANIFEST. No gameplay at all! It’s possible to come up with a game concept that basically doesn’t require any effort whatsoever to accomplish because it doesn’t actually do anything. I think this is pretty inspiring stuff! It’s another encouragement for non-coders in a way – you barely even need code. You could probably make this game in PowerPoint?

Sound System I. Working from aesthetics rather than mechanics/code! This game was developed entirely from a drawing of a coloured circle laid over a William Turner painting. For realsies. Then it was a question of “how is this picture going to be a game”? Just add awesome sounds and physics and some conceptual work involving John Cage and you have something.

Let’s Play: Let’s Play: Ancient Greek Punishment: Art Edition Edition. Pick one neat tech trick and enjoy it! This game revolved around the idea of a game with a generated reflection – that’s what made me love it as a cohesive thing. It also started from an aesthetic proposition: I had a photo of a screenshot of one of my games displayed as a print in a gallery and wanted to suck it back into gamefulness – almost like a “found object” game. But it was the technical detail of the webcam/video that makes it really work. So there’s hope for the technical types yet!

Anyway that there is some thinking about four small games and how they can serve as a useful guide/set of tips for people about to set out on a game jam.

What do you reckon? Do you buy it?

Let’s Play: Let’s Play: Ancient Greek Punishment: Art Edition Edition

It’s a game! In a painting! On a wall! In a gallery! In a game! Or something! Marvel as you once again confront that most boring question! Are games art?! Is art some kind of a damn game to you?!

Let's Play Let's Play Ancient Greek Punishment Art Edition Edition

Let’s Play: Let’s Play: Ancient Greek Punishment: Art Edition Edition was written in JavaScript with the excellent Phaser game framework. It is mobile and touch-screen friendly, but it is best played on a desktop/laptop computer in Chrome, Firefox, or Opera (so that you can use the webcam).

You can read my writing about Let’s Play: Let’s Play: Ancient Greek Punishment: Art Edition Edition on my blog, or even read the Let’s Play: Let’s Play: Ancient Greek Punishment: Art Edition Edition press kit.

Play Let’s Play: Let’s Play: Ancient Greek Punishment: Art Edition Edition in your browser

Got Me By the Technicals

I’ve been working on a new game (called Let’s Play: Let’s Play: Ancient Greek Punishment: Art Edition Edition) over the last couple of days – it should be out tomorrow evening. I’ve returned to HTML5 so that it’s mobile-friendly and so on, but I’ve also been forced (by the nature of the game) to engage more heavily in various new technical details than I normally bother with. This is the price of the “new aesthetics” I’m trying to use so that I don’t just turn into Sierraman or Atariguy or something.

This particular game involves including video from the players webcam as part of the visuals, and this took me into a (for me) complex world of browser hell. See, things don’t “just work” in this world, there are a million exceptions for the things you want to do. Webcams work in Chrome, Firefox and Opera on desktop only, for instance. But then it didn’t even work in Firefox because there was a weird bug that meant you need to slightly delay the webcam stream or you get an error.

So without webcam available for all browsers (and especially not on mobile) I needed a fallback. So then you try to include video that approximates the kind of thing you’d see through a webcam (me, in this case). But of course different browsers support different video formats (in this case I used webm and mp4). And then different platforms (like phones) only support specific encodings of specific video formats. In fact I fought so long and unsuccessfully to get video in the mobile version that I ended up needing a third fallback, an animated set of photos of me blinking!

So when you try to do anything technical like this you suddenly end up catering to many different versions of the simple thing you’re trying to make. You have multiple codecs, multiple representation options, you need to switch between them sometimes (e.g. from video to webcam if the player enables their webcam, so they don’t see nothing before that). And on and on. I spent quite a lot of time learning and failing. But I ended up getting it to work.

At which point I marvel: wow, what a huge amount of work to do something so absurdly simple. What an annoying medium it is we work in with games for the web. And I ask: what influence does all this technical stuff (particularly the long bouts of fighting for a single inch of technological territory) have on the actual games we make? By which I don’t even mean the subtle and interesting rhetorical powers of the tools we use, but just literally the labyrinths of technical know-how required just to do one, atomic thing (like show a bloody moving picture on the screen).

So, was it worth it? Just how different are the animated image, canned video, and webcam versions of this game? Did I waste my time?

You be the judge, tomorrow probably.