Let's Play: Ancient Greek Punishment: CPU Edition

Names so far:

• Let's Play: Ancient Greek Punishment
• Let's Play: Ancient Greek Punishment: Art Edition Edition
• Let's Play: Ancient Greek Punishment: Limited Edition

What to call the new one:

LEADER

Let's Play: Ancient Greek Punishment: CPU Edition

(CPU is the leading term for a computer opponent according to Twitter. I'm also drawn to it as a direct reference on the inner workings of a computer.)

ALSO

• Let's Play: Ancient Greek Punishment: Zero

• Let's Play: Ancient Greek Punishment: Zero Edition

• Let's Play: Ancient Greek Punishment: Part Zero

• Let's Play: Ancient Greek Punishment: Zero Player Edition

• Let's Play: Ancient Greek Punishment: COM Edition

• Let's Play: Ancient Greek Punishment: NPC Edition

• Let's Play: Ancient Greek Punishment: AI Edition

• Let's Play: Ancient Greek Punishment: Inhuman Edition

• Let's Play: Ancient Greek Punishment: Automatic Edition

• COM Plays: Ancient Greek Punishment

• CPU Plays: Ancient Greek Punishment

Okay so I've now got the basics of the Prometheus level all set up in terms of... well actually it just works (only with clicking for the moment). So then the question arises: how does the CPU play?

My assumption initially when coming up with the game is that it would have the same instructions (or rather, perhaps, I didn't actually think about the instructions in the first place), but does it make sense that the computer would 'read' instructions like 'rapidly click to struggle' etc.?

Perhaps also daunting: what would the CPU choose to do? Presumably they just struggle forever, meaning you'd never actually see a day/night cycle in the first place? They'd just spam the struggling... likewise for the other levels - the point is the computer would be relentless in playing the relentless game... infinite patience versus infinite labour...

But back to the instructions, does it make more sense, weirdly, to have instructions like 'rapidly call function struggle() to struggle and dislodge the eagle?' Kind of funny. Maybe better?

The flip side is to imagine it like it's the original game, in which case the computer needs to play like a human would, in that case needing to simulate clicks... can I do that? (Or simulate keypresses...)

...

So far some of this is being 'solved' by the fact I can't seem to programmatically trigger clicks (or key presses), which means that the CPU player won't be able to do that anyway. At which point I guess they just call the method? Weird... kind of appropriate for "how a computer would play", and in fact kind of nice because it means the player can actually click and just be ignored because the game only listens to the computer...

...

Okay, so it's 'solved' in the sense that I can't emulate/simulate/trigger events anyway. So it will be that the computer calls the function struggle(), which is funny. AND rather importantly, there's a kind of necessity here - when you ask the question "how would the computer play the game" it has to be something technically feasible. Thus this simply is how the computer would play, because it's the only way that work.

...

New niggling problem is the oddity of why one would display instructions - the computer doesn't read them or need them, so they're really for the human player watching the game. But that in itself is kind of nice. And I guess it's still true that you can display instructions whether or not the player needs to read them? And without that it does start to look pretty animated gif.

...

I'm surprised by how affecting (in some way) watching the computer playing the game actually is. Prometheus keeps struggling over and over again, and you know he won't stop, but in some ways it enhances the pathos of the game - the real relief in the game is when you give up and let the eagle eat you, allow yourself to be 'done to', but in this version of the game the tension of the struggle is never-ending.

...

Apparently Hercules rescues Prometheus. I think I knew that, but I was reminded just now on Twitter. I think I don't care though. Hah!

So v r 3 isn’t strictly speaking finished, but it’s at least out with a couple of people for testing (yes, it’s with my parents) for now. Restless guy that I am, I started working on a new thing yesterday because otherwise my self-worth would pour out of my eyes as bitter tears. The new thing is yet another iteration on my exciting franchise Let’s Play: Ancient Greek Punishment. I actually kind of like the vague intimation with all these follow-up versions that I’m somehow “chasing the magic” of the first game, which was really “successful” in terms of traffic and attention. I don’t think I am, but maybe I am.

The new version uses the format to explore a particular extreme, which is the idea of a game you don’t even get to play – instead the computer plays the game itself. It’s related to Best Chess in a way, with the player in the role of observer (and admirer?) rather than active participant, but it cuts out the player entirely – you don’t even make a move. It also summons to my mind Jesper Juul’s writing on Zero-Player Games, though I haven’t read that recently enough to be able to comment on resonances between this game and Juul’s thoughts (I’m sure they’ll be there, and I’ll re-read the paper sometime soon I swear). So the setup is, to be clear, we have a game that is more or less identical to the original (in terms of the code and its possibilities), but instead of player input triggering things in the game (like Prometheus’ writhing), the computer triggers those aspects itself as well.

That raises a few different things to think about, and I will try to write something about those things next week. I can’t be bothered right now, but rest assured it’s going to be super interesting when I get to it. This is just a project announcement. Consider yourselves warned.

I finished making the Prometheus level/version/minigame of Let’s Play: Ancient Greek Punishment: CPU Edition the other day, which means I’ve now had a chance to go through various of the required conceptual grapplings involved in this particular edition of the series. As per usual, my assumptions going in have been kind of rejected/realigned thanks to the realities of actually sitting down and building the game itself – perhaps the most important argument for making games a reality even if they just seem like a ‘funny idea’ or whatever. You may not entirely know what you’re doing. I rarely do.

Going into this game my idea was that the code would be more or less identical to the original game, except that I would disable user input and instead would have computer code (running on some kind of timer) triggering the required inputs – generally speaking this would mean the computer alternately triggering keypress events for ‘g’ and ‘h’ over and over again. It turned out, however (for me at least), that simulating keypresses (or mouse clicks) didn’t actually work out (fast enough) for me. I struggled with it for while, doing the usual trawling of the internet, but never found a satisfactory approach.

But the very fact it wasn’t working kind of fits into the narrative of the game, I guess. If I can’t get the computer to do things that way, then that’s simply not how the computer would play the game. It’s kind of a truism. Rejecting the kind of human-centric idea of the computer having to trigger keyboard input meant I could rethink how a computer might interact with the game, at which point it seemed suddenly very clear that the computer would simply call a function to cause Prometheus to struggle. Why would it bother to go a circuitous route? Above I called the method struggle() but now I’m calling it INPUT() for sheer computeriness.

Thus the game work by loading the game as per usual, but instead of allowing for human input, there’s just a function you need to call again and again to struggle (or push a boulder or run a race etc.) and that’s what the computer player does, in the form of JavaScript’s setInterval() function, which runs the same code repeatedly with some interval in between. That’s the ‘AI’ of the CPU player in this game. I did think for a while about the idea of the CPU player being a kind of separate script from the game proper, so it was like the CPU was playing the game ‘from the outside’, but I don’t think that’s necessary for the game to make sense.

Perhaps most importantly, when I run the game and watch the little Prometheus struggling bravely (forever), it seems to feel like something. It’s weird to look at, knowing the the code is both generating the situation and the response to the situation at the same time, kind of eery and wrong. Which is great, obviously.

So: so far so good and thanks for asking.

Just reporting in. I've now got Danaids and Zeno working fine. I've done both by essentially cutting and pasting in the ActionScript and translating from Flixel/AS to Phaser/JS, which has been remarkable easy, thank god. Bodes kind of well for potentially porting a bunch of my other work at some point I think. The underlying structures do 'just work' and nothing I ever do is really complex enough to worry about too much. So that's a plus, and makes me feel less like my games are being lost in the mists of time? Though of course just changing to ActionScript doesn't exactly guarantee longevity?

Anyway things are working. By the end of the week I'd expect the game will be completely done. And v r 3 will also be tidied away with its press kit and everything. I guess my aim will be to contact press on Thursday or Friday for a Wednesday release next week.

Have been beetling my way through the different parts of Let’s Play: Ancient Greek Punishment: CPU Edition over the last days, now through with Prometheus, Zeno, the Danaids, and Sisyphus. Just Tantalus and the menu system to go, really, before it’s basically a finished product (though I need to think a bit about having a CPU indicator in the game, as I think that would look nice – though it’s proving annoying to think of how to do it).

Today’s entertainment was while working on Sisyphus. That level has a really specific ‘fail state’ animation where, if you’re not pressing the buttons fast enough while Sisyphus is pushing the boulder uphill he starts getting pushed backwards back to the bottom. I was working away on the code for this and then tried to test it only to realise that this can never happen to the CPU playing the game – it’s always going to be ‘pressing the buttons’ fast enough, it will never be pushed back down the hill (except by the automatic fail state at the top of the hill). So I actually had to deactivate the computer player and implement controls for a human player specifically so I could test what happens when there is a fail state.

As it happens, this revealed that the fail states weren’t working at all – Sisyphus would jump all over the screen in whacky ways. Again, this behaviour is invisible when the computer plays because the fail states aren’t triggered. So I had to debug all the failure stuff by testing with my pathetic human ability to fail, fixing the code up so it reflects the original game faithfully and well. So in the end I spent most of my time working on the Sisyphus level actively engaged in writing and fixing code that will literally never be processed by the game once its’ complete. But, of course, it has to be there for reasons of authenticity – if the failure code weren’t there, there would be no counterpoint to the computer’s repeated ‘success’ (success at failure, in a way?), and it feels like that encoded possibility of failure is needed for the success to register properly.

On the other hand, to the extent that the code cannot be triggered, it’s not entirely clear that it’s really there? Like, a really smart compiler would be able to determine that the code cannot be executed, for instance, and just not include it at all. But that said, JavaScript is an ‘interpreted’ language, which means it doesn’t get compiled and this kind of vestigial code is still ‘legitimate’ I suppose. I suppose? So it’s there and not there. Schrödinger’s code.

Unreal code,

Under the brown fog of a winter dawn,

Hey just a quick note to say I now have all five of the levels working as planned which is pretty nice. Remaining key tasks are to make the menu system (where the CPU randomly selects a level to play, scrolling up and down a bit before settling on a choice), and then the consideration of having a 'CPU' indicator above the head of the characters. It would look really nice, but I think there's a big question of how practice it'd turn out to be for a lot of them... e.g. Sisyphus and Tantalus are both animated entirely in the spritesheet, which would make it hard. Prometheus is easy (he doesn't move much). Danaids and Zeno are easy because they move a sprite around rather than just an animation. But yeah, to do Tantalus and Sisyphus (Sisyphus especially) would require hard coding values for the x,y location of the indicator for every frame of animation, which for Sisyphus is over 100 frames, which sounds really unpleasant. So I'll have to think about it. It may be necessary just because it would look so lovely. Ah well.

Nothing very exciting has happened my friend. But it's that kind of game you know? All in the concept rather than the execution. Probably like most of my stuff actually, in that regard. Never all that hard to make. So I'm making away. All the versions of the game are done and the menu system exists now, so it's complete except for... the indicators.

I made a couple of mockups of how the indicators would look and they looked pretty good to me, so I've decided to go ahead and put them in. They're now in for everything except Sisyphus, which involves constructing a giant table of x,y locations for every frame in that animation which: sucks. But that's the only way to do it practically, I think. Anyway it's just a task (it's a little Sisyphean except that it's totally not because it's completely finite ha ha).

Anyway the point here is that the CPU indicator does help I think. In particular it starts pushing away from the idea that you're just watching an animation being played and that instead there is something "controlling" the game proper - it at least implies that. It also conveys, for people for whom the title isn't enough, the aesthetic idea that the computer is playing (whether or not it's faked).

Also on the question of "faking it" by just playing an animation... it's kind of interesting in that in some sense there's no important difference? Both versions involve the computer in a 'hopeless' loop of performing work to display the imagery of, say, Sisyphus pushing a boulder up a hill. One the work of repeatedly rendering frames of a video/GIF, the other the work of repeatedly providing input into a game that renders the same frames to the screen as a result. In a sense all infinite loops are Sisyphean? In a sense computers are constantly in an Ancient Greek Hell of repeated, meaningless work? This just literalises it? Is it almost mocking of the computer? Is it contemptuous? I don't mean to be!

But of course I'd still maintain there's something meaningful in the fact the computer is playing the game rather than playing an animation, the fact that there are other branches of code going unchosen/unexplored is kind of important? The classic "I could have done otherwise" despite the fact of determinism? Deep man.

Let’s Play: Ancient Greek Punishment: CPU Edition! is pretty much all done now, a welcome ‘easy’ game to make in the wake of v r 3 that was so technically challenging (for me, personally). The final addition I made was to go through and add in indicators that point to the CPU player as it goes through the various motions/trials of the different levels of the game (as above) for Zeno. I vacillated on including the indicators for a while chiefly because I had to manually add them frame by frame for a couple of the levels (Sisyphus and Tantalus), but in the end it seemed too important to the nature of the game to omit.

Specifically, although the game communicates that it is the computer playing the game both through its title (“CPU Edition!”) and the brute fact that the player has no input, it didn’t feel like it was necessarily bringing home the potential pathos of watching the computer struggle in the different scenarios. Notably, the game and an animated GIF of the game are kind of interchangeable and it might be possible for a player (if that’s the right word) to think they were merely watching an animation or a video of a game, rather than the game itself. Adding the ‘CPU’ indicator, although it could of course also be represented in a video, helps to constantly explain the automated nature of the game as it proceeds, and also helpfully assigns the computer to player to the specific character on the screen, rather than to the game as a whole.

Thus, the computer is both tormentor and tormented, eagle and Prometheus, perforated bathtub and Danaid, Sisyphus pushing the boulder up the hill and the unseen force sending it flying back down again. This division of labour makes much more sense with the individuating ‘CPU’ indicator to separate the character controlled by the computer from the game world simulated by the same computer, I think. Maybe I’m over-thinking this, but it genuinely seems important when I think about it.

Still, it remains true that in the end the game could still be represented as an animated GIF and appear literally exactly the same when you watch it in a browser window. But in a way, aren’t all looping animated GIFs a kind of Sisyphean torture for the computer? Rendering frame after frame to the screen with no end in sight, at the mercy of the vagaries of the human user to set it free from its infinite task? Or perhaps, au contraire, we might think of infinite loops in computation as the ultimate pleasure for a CPU – the constant and unending expression of their singular abilities to process information indefinitely and without fatigue?

Might one in fact imagine CPU Sisyphus happy?

The above image, taken by my parents, is of my game Let's Play: Ancient Greek Punishment: CPU Edition! in situ at the 2017 Venice Biennale. In Venice. For real. It's part of an installation/show called #HYPERPAVILLION, with my own contribution forming part of a screen curated by NT2, a research lab based out of UQÀM here in Montréal. On the screen you can select to view a set of different pieces work, including my colleague and friend Skawennati's Time Traveller™.

There are three main things this makes me think about this evening,

First of all, it's a testament to the wonderful randomness of life that I'm even part of the show at all. I met the NT2 crowd via giving a talk about my work at the lab and having a discussion with them, and that connection was kind of activated by them being invited to have a screen in the #HYPERPAVILLION space and me having a piece of work that made sense with their key line of inquiry, which was "What if?" (in my case, the "what if" of a game that plays itself). It's kind of amazing how possibilities interlock into opportunities sometimes - much luck on my end, anyway.

Second, the nature of the installation relates in an interesting way to the specific game. The works curator by NT2 all share a single screen with an interface for switching between the different artists' contributions. While each of the other artworks is a video piece, Let's Play: Ancient Greek Punishment: CPU Edition! is obviously a game. Well, maybe not "obviously" since we can probably quibble over the definition, but it's premised on code running very centrally - the entire point is that the computer is actually running the game, that it isn't a video, even while it looks like one (and is indistinguishable from one for an onlooker). As such, NT2 technical support team were terrific in that they were very prepared to go the extra mile(s) required to make it such that, while the other works presented were videos, the game was presented on screen in its "pure form", running as JavaScript. That tension between looking like a video and "being" like software is part of the work, so it's really nice to have that play out in the actual process of exhibiting it, too.

Finally, the fact of my parents going to see the work (they were going to Venice and the Biennale anyway, don't worry) really managed to lock in the sense of the exhibition being a real thing. They were sending me chat messages over the morning reporting on how the work looked in the space and showing me pictures of it (hard to photograph because of light levels, as you can see from the picture). My games are exhibited with some frequency (I have no idea if it's a lot or a little, but frankly I'm thoroughly impressed that it's "at all"), but it's kind of hard to gain any emotional traction on the physical fact. My interaction with exhibitions tends to me emailing relevant files and rewriting bits of code to be "gallery ready" as required - as such, it turns more into an excercise in logistics, followed by a resounding non-awareness of the physical reality of the show itself. It's only today that I'm registering a kind of sadness at not being able to feel more connected to the work as it heads out there.

(Though, finally finally, I'd also add that all the times I've been in the same room as my work being exhibited - which isn't many - I felt a deep and unpleasant sense of discomfort with the experience. So maybe it's all for the best to be blissfully unaware? Or maybe the moral of the story is that I should send my parents as emissaries to all the shows to text message me about them... just the right about of connection and alienation...)