Indicators of Effort

Screen Shot 2017-03-23 at 11.47.31 copy

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?


Unreal Code

Screen Shot 2017-03-22 at 17.35.58

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,


struggle();

Screen Shot 2017-03-16 at 17.04.21 3

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.


New Project: Let’s Play: Ancient Greek Punishment: CPU Edition

Screen Shot 2017-03-17 at 13.43.16

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.