Games, systems and the visibility of code

I’m thinking of submitting an abstract for the CODE conference that’s on later this year, and so I’ve been looking at the different themes to find some sort of direction (yeah, this might be a little late, what with it being due in 3 weeks…). I’ve had a thought that needs to be fleshed out some more, and would love to get some feedback on this topic to help me cement it into some sort of throughline.

Also, it’s been ages since I wrote about the theory of game design and I kinda miss it.

The theme I’m looking at is ‘Code and the in/visible’. The conference site explains that it has been argued that “software, operating at the level of screen and interface, obscures the constant workings of code, which become opaque to ‘end-users’”, and asks for papers that discuss “the technical, ideological and academic aspects that work to obscure codes? And what might be the strategies for making codes visible again?”

My response to this? For me, games are in a unique position when it comes to the visibility and invisibility of code and, that at some level, they undermine the very idea of obscuration.

What? Why? How? Read on and I’ll (hopefully) explain (clearly).

Games, unlike most software, is often not aimed at productivity or a ‘bottom line’, but at fun. As Koster says in ‘A Theory of Fun for Game Design’, “Fun from games arises out of mastery. It arises out of comprehension. It is the act of solving puzzles that makes games fun.”

Now I, being a guy who’s really interested in narrative, will be the first to point out that fun in games is not altogether that simple, but the fact is that this definition is completely accurate for some games. That is, you can make a game whose fun is entirely based on mastery, and people will find it fun. They might not buy it (as we’re all kinda spoilt by pretty graphics/stories/music etc.), but they will find it fun.

And if the goal of using a game is to master something (rather than to perform a task in an optimal fashion), then the entire purpose of the game is to make it’s underlying system visible and understandable, or, to make it’s code visible (at least at an ideological level). Games actively reward those who uncover the secrets of their mechanics. In  fact, we often design games to help players to understand their mechanics (we introduce elements of the system one at a time, show players how they interact and then test them to ensure they fully understand before moving on).

We can, in fact, split a game into two parts. There’s the underlying system (the basic simulation of the game, or the ‘model’ for you MVC-ers), whose code we want to explain to the player and the rest of the game (which I’ll call the explanatory system), which is designed to explain the underlying system to the player.

Why do we need the explanatory system? Because of the simple fact that code is already invisible to most people, simply because of it’s code-like nature. Code obscures itself, making itself opaque through parentheses, keywords and syntax, and so we need to create these complex systems (ironically, with code) to help demystify it.

Games, therefore, are an opaque system whose purpose is to make a specific part of themselves transparent. They specifically ask you to decode them, and give you tests that can only be passed if you do. They are therefore a supremely powerful strategy in making codes visible, whether they be software or otherwise. In fact, this property of games might be why ‘gamification’ (which is still a horribly defined word) has taken off.

There’s a couple of counterpoints that I want to mention here before I open this up to you guys:

  1. Code and mechanics aren’t always equivalent. A physics engine, for example, is often employed to make a stepwise system look and feel continuous. There is still code that is directly analogous to the mechanics (there’s a bit of code somewhere that says that letting go of the strangely enraged bird sends it flying towards the justifiably terrified pigs), but for every bit of that, there’s other bits that are obscured.
  2. There’s usually code/mechanics that aren’t meant to be visible: Halfbrick fudges the hitboxes on fruit ninja to make it easier, and we’ve done a number of tweaks on shape splitting to make it subtly more intuitive (we also cheat for the player at times). There’s a possible argument here that the goal of the game is still to understand the game, and so these changes, while not consciously understood, are often unconsciously acknowledged. We’d then get into the question of what invisibility really means: do we call it visible if we know it at an unconscious level?

That pretty much sums up my thoughts on the topic. Clearly I need to do more thinking and research before I can submit anything, so if any of you have any thoughts on the subject or ideas of what I should read, I’d love to hear them.

Did you enjoy this?
Share the love
Get free updates