Blog Posts

Here are public-facing blog posts I wrote about the game.

Two New Projects, Two Different Processes (2016-12-29)

I’m trying to write more things, so this is a thing.

Currently I’m working on two new games at the same time – one is more of a standard kind of “thing I just want to make” while one is more connected to a research project I’m involved in at work. I’m working on them at the same time because I feel I ought to be doing the work one, but I really want to be making the other one too. We’ll see if that backfires.

One thing I’ve noticed is that the two projects capture two different approaches to game making from my perspective – they’re both processes I’ve followed before, but it’s funny experiencing them simultaneously. Check it out…

SNAKISMS is a kind of spiritual successor to PONGS and BREAKSOUT in that it’s multiple versions of a classic game (Snake), with the change this time being that I’m trying to convey different “isms” or philosophies through the mechanics of the game by making small changes. The process here has very much been cerebral – sitting down with a notebook or my laptop and literally just writing down the names of philosophies and trying to work out how you could make a game of Snake out of them. There was no need for any coding or anything because it’s such a simple game – so the whole thing can be pretty much designed without touching development at all.

It is as if you were doing work is kind of a follow up to It is as if you were playing chess but is also tied more broadly to an interest I’ve had lately in thinking about standard user interface elements in the context of play, and the idea of play as a form of labour. In this case I only have a vague kind of idea with what the game is meant to be like, effectively “WarioWare with standard UI elements”, and as such my process has been much more to grapple with the actual tools for making the game in order to feel my way toward design decisions. As such, I’ve been fighting with jQuery UI and its Theme Roller to try to capture an appropriate theming of the UI elements (so that they look a bit like It is as if you were playing chess) and working out what the game is from the inside out in some ways.

Both those tactics for game design (in the head versus in the technology) are approaches I’ve taken in the past, and of course they blur into each other the further you get into development, but it’s been quite fun experiencing them at the same time like this – has provided me with an odd opportunity to observe myself working in some sense.

Bye.

New (quite old) project: It is as if you were doing work (2017-03-27)

Having finished with both v r 3 and Let’s Play: Ancient Greek Punishment: CPU Edition! I’m naturally onto a new project to occupy myself with. In this case, though, it’s actually a return to something I’d started working on late last year, but lost steam on in favour of SNAKISMS. This is the kind of sequel to It is as if you were playing chess called It is as if you were doing work. The idea is, as you might imagine, to follow a similar pattern of heavily interface-driven play, but this time for the interfaces in question to revolve around the idea of work/productivity, rather than the game of chess.

I was largely stymied by the project last year because I kept tripping over myself in terms of what sort of scale to make it at, and what its identity would be. I was thinking about everything from extreme puzzle games to procedural narrative as possible lynchpins for it. But in fact all those of those extra layers feel now like they more represent a kind of anxiety/inadequacy surrounding the base concept of the game – or perhaps more accurately, simply not knowing what it was. So I spent today just making the absolute simplest example of the game I could image, as pictured above.

The game fades in two radio buttons to choose between, and another button to click, and an instruction tells you which radio button to select and tells you to then click the button. Having implemented this, I feel like I’ve returned to a little bit more clarity in terms of how I envisaged the game in the first place: a hyper-simple ‘simulation’ of doing the kinds of work that user-interfaces generically seem to represent – selecting/inputing/manipulating information on a computer. The fact that you’re told specifically which actions to carry out is part of the idea of the game being a simulation of work rather than work itself and thus, ostensibly, kind of relaxing to ‘play’ – you don’t have to actually make decisions, you just appear to be making decisions. Similarly, the interface is highly abstract (notably with a non-language for all the labelling/content) so that you also don’t have to engage with any particular forms of meaning/interpretation – you can just let the world go by as you do the right thing over and over. I did toy with the idea of having no instructions at all, so you could just do ‘whatever’, but in fact that would probably be less relaxing, because you’d have to make decisions (not to mention more boring because it would be literally meaningless).

So having made this minimal version of the game, I’m feeling a little more confident in terms of proceeding with the next steps. Next is clearly to add different possible interfaces that you could encounter (e.g. checkbox, text box, menu, slider, progress bar). After that I need to decide whether there’s any real sense to having more complex ‘compound’ interfaces with multiple elements, or whether that would actually dilute the purity of the interfaces as they stand. And then I also need to figure out whether the game ought to have some sense of progress/completion involved (e.g. points, an ending), or whether the idea is more just that it goes on indefinitely – for as long as you want to appear to be working (not unlike the ‘boss mode’ in some earlier videogames).

Anyway, it’s a testament to making a (relatively polished) mini-version of the game being a useful way of understanding what you’re doing. Rather than spinning my wheels in design and losing touch with the concrete nature of the game, making a working ‘vertical slice’ has helped recover the meaningfulness of the base interactions and thus to get some traction on the overall project.

Now don’t forget to select ▝▍▀▟▖▀▎ and then press ▚▎▗▀ before you go.

Aesthetics considered harmful (2017-05-31)

Why hello there! I just got back from travels to Japan and New Zealand and so I’m trying to get back in the saddle of writing a few times a week. It’s an uncomfortable and unforgiving saddle on an unpleasant, mean-spirited, and violent horse, so we’ll see how it goes.

Anyway, the other day I was thinking about how the aesthetics of a game (or probably any other creative work or, perhaps, anything at all) can really paint (ha ha) you into a corner in terms of other elements of a project. Specifically, before leaving I’d been working on a project called It is as if you were doing work as a kind of follow up/semi-sequel to It is as if you were playing chess, where the idea is to look like you’re working rather than playing chess.

I used the spirit of the aesthetic of the previous game as a starting point, so had these very minimalist buttons and checkboxes and so on set against a dark grey background. In the interest of simplicity and minimalism I even went to far as to remove language altogether so that you had these kinds of alien shapes instead of something intelligible – pure interface. It looked quite good.

The problem is, it looked quite good in a way that utterly diverted me from the actual point of the game I was initially trying to make. And there’s the rub (apparently that expression derives from bowls, who knew?) – when you set an aesthetic you’re setting a kind of emotional tone for the overall project which, in turn, seeps out into all the other parts, notably the design of the actual interactive bits, the dynamics, etc. So by having established (and fallen a bit in love with) a minimalist/anti-meaning aesthetic, I was driven to think about the game itself as minimalist and anti-meaning. The problem with that being that that wasn’t what I wanted to make.

The idea behind It is as if you were doing work was all about creating (somehow) the sensation of “working” as a kind of game. So it was to focus on that sense of mini-achievement you have when you do some little work unit like closing a dialog box or clicking a button, and by building up lots of these it was going to allow you to sort of look like you were working (ala the “Boss Key” in a game like Leisure Suit Larry) but also feel like you were being “productive” in this essentially empty way.

In order to create those sorts of feelings, though, you really need to evoke familiar tropes of work and the kinds of “content” that work has. It’s hard to represent those tropes in a futuristic-looking minimalist environment, particularly if you’re foregoing the use of intelligible language. And so what happened is I spent quite a while unable to make progress – the aesthetics of the interface I’d create didn’t want to be the game I wanted to make, and I couldn’t see that for quite a while.

Finally, after setting the game aside for quite a while, I had the sudden zennish realisation that I needed to rework how the game looked in order to be able to actually work out how it would behave. By reskinning it to look more like Windows 95 and with text in English, it was suddenly possible to see how the game could move forward, and in fact a bunch of ideas occurred to me and progress was made.

So, be careful with aesthetics, my friends – they sure as hell aren’t some sort of skin on top of the ‘real game’, and in fact they can completely dominate your process without you quite knowing it.

You’ve been warned.

It is as if you were back to work (2017-06-10)

Over the past few days I’ve been successfully getting back to work on It is as if you were doing work. The joke probably writes itself there, but frankly it’s too hot in the apartment to really dwell on it.

I wrote a little while back about how freeing myself from the initial aesthetic of the game had really opened up my ability to think about the game again (Aesthetics Considered Harmful). You can see in the above image that I’ve restyled the game to use a kind of throw-back/retro aesthetic referencing Windows 95. Importantly it’s a formal aesthetic that, to me at least, cries out “this is work!” and that’s a key component of the experience the game it trying to deliver. Work needs to look like work.

At this point I have a prototype able to generate dialog boxes (in that style) which contain a random set of interface elements (sliders, progress bars, radio buttons, etc.) and instructions on what to do with them. As I’ve been working on this more procedural aspect of the game (or its ‘interactive aesthetic’ or whatever) I’ve of course run into other, different issues and roadblocks. Notably, there has been a desire to make the game be… like a game.

But ‘some games are better without gameplay’… or at least they’re better without ‘game-y play’? In constructing this game which is about feeling like you’re working, it seems to me that making it more game-like (in the conventional sense) naturally draws the player away from the sensation of ‘work’ (albeit that playing games frequently feels like labour, etc.). I was coming up with ideas like little popups telling you you made money each time you click an interface element (correctly), or dialog boxes that move around on the screen as you try to use them, or highly complicated/obfuscatory instructions for what to do in a dialog box. Those are all pretty fun things that would make for a more entertaining game and there’s nothing wrong with them, but they’re still wrong for this particular game with this particular experience in mind.

It’s back to that idea of a ‘ground truth’ of design that I think about sometimes. You need to really know what the underlying premise/experience of the thing you’re making is, because literally every single decision you make at every level of design and implementation tends to either serve or betray it. Moving dialog boxes are almost objectively hilarious, but they don’t serve a ground truth of feeling like you’re doing work, because that’s not what it looks like when you’re doing work. And of course I could spin some narrative reason why work-of-the-future involves moving dialog boxes, but it’s not especially plausible. (Though now I think about it, in a simulation of work, why not have added challenge element? I think because the idea here is also to feel comfortable and competent, rather than challenged.)

So in reconnecting with the ground truth(s) of It is as if you were doing work it’s been easier and easier to make the decisions I need to make moving forward. Whether or not it will end up as a ‘good game’ is entirely debatable, but it will at the very least serve the idea I started making it for in the first place.

Narrative framing in It is as if you were doing work (2017-06-14)

In the past couple of days I’ve really managed to get the basic structure of It is as if you were doing work up and running in terms of the idea of dialogs popping up, telling you what to do, and knowing whether or not you did that correctly. Part of me wanted to just scream “done!” and immediately upload the game to my website, but as we all know, just getting the basic mechanical nature of a game/thing running really isn’t the full picture. As I sat there starting at the dull grey background of the game, it was sadly apparent I need some kind of larger framing for the core activity of clicking around in dialogs - quelle surprise.

It’s especially important to create this frame for this game because, although the ‘point’ is the act of filling out dialog boxes, the point can only register if the game establishes the hypothetical context in which that act is taking place. Namely, the near-future in which most or all computer work is automated and humans have nothing to do with themselves and some of us pine for that feeling of ‘getting work done on the computer’ and require a game/computer program to allow us to simulate that and chase that feeling. As such, the game now needs enough extra stuff to bring across the idea that It is as if you were doing work is that program/game.

I’ve discussed possible extra UI elements with Rilla and with my colleague Jonathan Lessard and collected some nice ideas concerning having some more active background (including the idea of a desktop picture) and the idea of interactions that take place outside the basic ‘workflow’ (ha ha) of the game. Importantly and appropriately, the game needs to set up this near-future idea via interface elements specifically - like my earlier game MANIFEST it needs to be the program that would exist in this near future, rather than trying to portray that near future in a more traditional narrative way.

Current thoughts for how to establish the narrative frame via interface-stuff are:

So that’s where things stand with the game for the moment. A fair bit of work left to do, but generally it’s known work rather than the horrors of unknown work where you know something’s wrong but not what to do about it.

Something to do while you’re doing something (2017-06-19)

Work continues on It is as if you were doing work. Over the last passage I made a slightly dispiriting discovery, again concerning something of a conflict with the ‘ground truth’ of the project, but then also think I have a solution for the problem.

The issue I discovered is that on implementing an actual stream of dialog box-based tasks for the user to complete, it’s actually pretty stressful. It quickly harks back to the dynamics of Let There Be Smite!, where you’re getting completely overwhelmed by dialog boxes and are much more focused on getting rid of them that on any sensation of effectiveness and competence.

The obvious solution to that problem is simply to slow the flow of dialog boxes down until it’s fairly trivial to deal with them one by one and thus feel that sense of “there!” each time you get one done. The problem with that, though, is that then the dialog boxes are coming slowly enough that there’s only one or two on the screen at a time, which looks quite bare aesthetically.

In fact this gets back to the nature of dialog boxes themselves as interface elements: they’re almost always used as momentary interactions rather than sustained interactions. This is contradictory to the fundamental objective of the game being to simulate continuous, effective, work. That’s simply not what dialog boxes are for, so they’re a somewhat ill-suited tool, even though they look great.

So my planned solution is, sensibly (and probably belatedly), to return to this idea of work and to think about how dialog boxes are contextualised in work - that is, you’re usually doing something else when they pop up. They interrupt another interaction, you deal with them, and then you return to the initial interaction. And that initial interaction is often/generally the actual work you’re doing.

The plan is, therefore, to include more ‘longitudinal’ tasks in the interface, like writing a document or doing data entry, that then serve as the basic texture against which the dialog boxes can appear and diversify your experience a bit. As such there will be three levels of interface operating at once:

Those three levels seem like they ought to work together well. That said I also need to actually implement the longer-term work interaction to make sure that it fits in and solves the problem of dialog-anxiety/dialog-scarcity. So it goes.

You’re doing so well forever (2017-06-21)

One of the elements of It is as if you were doing work I’ve been thinking about lately is the question of feedback to the player on how well they’re doing. It’s gone through a few phases in conversation with thinking about what the imaginary narrative context of the game is.

Initially, the idea was very much to have a clear idea of getting things right or wrong when you play the game. So if you click the wrong button, say, a ‘bad sound’ plays, the dialog boxes shakes and closes, and you would lose some salary. If you kept getting things wrong then you’d get warnings, demotions, and would eventually be fired. Vice versa for getting things right: you get happy sounds, salary bonuses, and promotions.

However, in trying to design the interface itself and find a place to list ‘salary’ I was reminded of Jonathan pointing out that the person is literally not earning anything through this work. With that in mind it started to seem like listing an explicit ‘imaginary salary’ would be more of a distraction, so I got rid of that idea in favour of the more abstract/interpretation-friendly thing of just having your rank.

And then as I was working on the game more, I started wondering why I would have negative feedback in the first place, since it doesn’t really fit in with the empowering fantasy of being good at your job. So I moved to a model where there is a correct way to complete a dialog, but if you get it wrong, it just won’t close (and may even indicate where the problem is so you can fix it easily).

With this new model of absolutely no failure being allowed, it no longer made sense to have the idea of demotions in rank, and therefore the idea of there even being a hierarchy of rank stopped making sense. Instead, I now have a “job position superlative generator” that comes up with job titles as you get “promoted” (laterally) over and over again. “Super Dialog Processor”, “Premium Interactivity User”, “Chief Screen Expert”, etc.

All of this lends itself to an atmosphere of extreme effusiveness about your skills and success, while also signaling a kind of total stasis at the same time, which feels about right for the narrative framing. So it’s quite a journey from the very evaluative/severe version to this super-positive/going-nowhere version.

[Okay.]

Radically open game development? (2017-07-07)

Since I made SNAKISMS earlier this year I’ve moved toward an open-source version of my games as much as I’ve been able. v r 3 was a challenge because it included proprietary assets I’d paid for and because I’m dumb at Unity, but in general I’ve been trying to release my code when I release a project, including all the commits etc. (It is also making me hyper-aware of how absolutely terrible I am about commenting my code lately - really must fix that.)

To go with the basic availability of my code (under a Creative Commons Attribution-NonCommercial 3.0 Unported License), I’ve also used GitHub to host other elements of the development process (examples here are from It is as if you were doing work):

Obviously that’s quite a lot of information to package with my games themselves, and it’s in no small part so voluminous because as someone working as an academic, I’m working with my colleagues (notably Rilla Khaled and Jonathan Lessard) toward a method of game design and development process analysis. (We’re calling this Games as Research. That website will have actual information at some point.)

However, with both SNAKISMS and It is as if you were doing work one thing that came up I wasn’t expecting (for reasons I don’t pretend to understand) was that people were interested in engaging with the work ‘as software’ by writing fixes for bugs in a game or improving a game by adding functionality like making the game installable on Android!

This makes me wonder about a couple of more “extreme” avenues that are entirely plausible with something like GitHub as the central repository of my games (usually)…

Real-time visible development. At present I make my game repositories private until I release the game, at which point I make them public for people to look at whatever they want. It occurs to me that I could develop games “in public” the whole time such that people who gave a shit (this could easily, easily be nobody) would actually be able to keep track of the game as it developed, play incremental builds and generally watch me being terrible at game development. Live! The obvious reasons I haven’t done this as yet are that a) I’m self-conscious about how shitty my development actually is, b) I’m self-conscious that nobody would care, and c) there’s some (probably dumb) fear that if the development were open, people would lose interest in the final product when I actually released it. None of those reasons, at this moment, strike me as great reasons not to just do it anyway. The primary reason probably being: “who even cares?”

Real-time visible radically open development. It’s only a short step from having my code repositories open while developing to accepting the idea that random strange might want to randomly contribute to the game itself. It’s easy to imagine, for example, somebody randomly populating an array of job titles, say, with their own ideas, or editing the list of inspirational slogans, or adding a whole other kind of dialog box. (Or not, of course, I’m not saying people would actually want to do this, just that they could.) This one troubles me much more significantly because, well, I’m already not the best collaborator in the first place, and the idea of “random collaborators from the internet” gives me chills. On the other hand, if it’s just people suggesting additions/subtractions to the code base, there wouldn’t be any harm in this and it could be pretty interesting.

In the end I suspect it might be good to have the development in public to see what happens (while being aware it might change how honest and open I feel able to be in, for example, my diary). The question of whether people might want to interact with the code itself during development is just something that could be explored as it happened (or didn’t happen). It’s certainly a weird and interesting idea. So, let’s see. Maybe.

##

This site is open source. Improve this page.