Green Dragon

Projects | September 1, 2014 by Bee Sprawlbug

Green Dragon is a videogame by me that you can read about and play (for free!) on this very website. Presently it comes in Windows, OSX and Linux versions. I made this game for Ludum Dare’s 48 hour Compo, where it placed 55th out of nearly 1500 entries.

home

One night in university I experienced a fever dream that I still think about every day. In the dream I was an adolescent who’d spent his life stargazing through a telescope. I’d been trying the whole time to discover the location of one particular celestial body: A giant, dead green dragon floating somewhere in deep space. Its existence was rumoured, but never confirmed.

On the night of the dream I finally found it. Through the telescope I could see only fragments: a leg, a wing, a neck. Its corpse was disintegrating gracefully out there, scales trailing off into blackness as they blinked in the starlight. I felt I had to go find the thing; to touch it, to commune with it. This was a task of spiritual importance. In my dream the dragon was everything. It was me; the real me. Somehow I assembled a group of vague companions resembling the cast of a late-’90s Final Fantasy game. We departed from our home planet in search of the dragon, a flock of human forms drifting upwards from the Earth.

Dreaming at the Full Indie Summit

Game Criticism | August 20, 2014 by Bee Sprawlbug

One summer in 2008 we dreamt there was money in “indie games”.

It was a consensual hallucination experienced by thousands; a capricious belief, born from the resounding commercial success of games like Braid as juxtaposed against the dismal realities of AAA development work. Back then I counted myself amongst the dreamers.

I was born twenty years beforehand, in December ’88. As a shy middle class white boy growing up in Greater Vancouver, all I wanted to do was play with the computers my parents brought home. Yet where the previous generation, people like Richard Garriott and John Carmack, had spent their formative years hoping to become astronauts I spent them hoping to become Garriott or Carmack: A paragon of nerdness, an auteur of sorts, a so-called “game god”. This was the image I found in magazines and internalized; it was how I saw my future self whenever my daydreams pivoted towards optimism. (Sometimes I still catch it bubbling up from my id.)

A cover of PC Gamer magazine featuring a photo shoot with John Carmack, Sid Meier and Richard Garriott smiling warmly at the camera

Pictured: My subconscious, circa September ’99

By the time I entered high school, however, the magazine cover had changed: The picture grew darker as it became more concrete. Teams of less than ten had become greater than two hundred. Origin was now EA. DOOM was now DOOM 3. The axis of technology and capital had run amok, ‘maturing’ the videogame industry into an abject monstrosity; grown bloated and stiff, its body had begun to stink. I became increasingly aware that the future I sought, which I could not help but seek, was likely to consist of spending 12 hours per day modelling shin pads for EA Sports’ NHL franchise.

Form and its Usurpers

detritus, Game Criticism | July 16, 2014 by Bee Sprawlbug

What is the value of a phantom limb?

In 1964 Marshall McLuhan published a book called Understanding Media: The Extensions of Man. It’s sort of like a religious text for media theorists, though it leans more towards apocrypha than canon. McLuhan was a bit of a heretic. He’s most famous for claiming it’s the form of a medium, rather than the messages we send through it, that has the biggest impact on society; not the violence we watch on television, for example, but the structural properties of television itself. Media change the world by changing its users on a fundamental level; by extending our bodies. The printing press is like a bionic mouth that lets us speak to a million people at once even centuries after our death. The internet is like a second face, a new partial self whose disembodied and digital form can both listen and speak to others of its kind. When I adopt a new medium it alters how I experience the world and what I can do to it, as if I had grown a new appendage. Even my Twitter persona, for example, represents a new facet of my body. At the same time, however, Twitter is a web service; a business run by people I can’t trust, yet with whom I nonetheless share ownership of my shiny new-grown limb. If they wanted to they could cut it off and sell it.

I develop videogames for a living, but I spent last year really hating videogames. I questioned how it was I could consume 60 hours of ‘content’ for Assassin’s Creed 3 yet feel utterly unsatisfied by my act of consumption. I questioned what it was I had consumed, other than my own time. I questioned what it was I sought from the game in the first place. I questioned the nature of the ‘content’ it claimed to offer me; privately I began to suspect it might not even exist. The games I was making and playing seemed more and more to me like empty forms: Puzzle boxes within puzzle boxes, each layer promising ‘content’ underneath it yet in the end yielding an empty centre. I became too tired and bored to care about games anymore. I could no longer see the point in it. I felt as if some enormous detritus had gathered upon my career and favourite hobby; that I could no longer reach through this detritus to claim the enjoyment I had once found underneath.

I awoke from my yearlong stupor the night I encountered a game called Problem Attic by a person named Liz Ryerson. It was like nothing I’d seen before. Rather than a puzzle box, it was more of a sculpture. Its ‘content’ was not buried behind teaching, gating or a thousand tiresome transactions; it was simply present, exposed, beautiful anywhere I cared to look. Ryerson had not designed the game to be consumed so much as authored it to contain ideas. We cannot consume an idea. We cannot lock and unlock it; we cannot buy and sell it; we cannot bundle it with an Xbox 360 at GameStop. We cannot possess ideas. But I learned from Attic that ideas can possess us. Attic made kindling of the detritus through which I’d been stumbling, lighting a bright yet tiny fire in the back of my brain. The more I thought about the game the more it changed the way I thought: About videogames, about Marshall McLuhan, about my job, about everything. As I put my thoughts into writing the fire spread, and the detritus began to burn away.

Upon completing Attic I resolved to write a brief close reading, so I sat down one evening hoping to produce 500 words. I stood up the next morning with 4000. Those words became Fashion, Emptiness and Problem Attic. But even as I published that piece I knew I was not finished. I’d learned Attic is a game about prisons of belief and behaviour: It’s not about looking at the path ahead, it’s about looking at the walls. Thus it was not enough to explain what Attic makes present that other videogames leave absent. I needed to understand the forces around me that created this absence in the first place. Another 4000 words later I’d concluded it was the values I internalized as a student of user-centered design (chief among them clarity and craft) that made me champion products I’d now come to hate. These words became The Cult of the Peacock. I liked that piece a lot, but still my work felt incomplete. I had yet to express the entirety of the thinking I’d been doing; columns of flaming detritus still swirled through my head. I’d learned Attic is not just a game about prisons; it’s also a game about jailers. It was not enough to criticize the shape of the prison in which my work was confined. I had to learn who built its walls.

McLuhan, if he were still alive, could tell us all about walls. He would say walls are a medium. By placing them in the world we form a new space that tells us where we can and can’t go, what we can and can’t do. In this particular sense McLuhan might also say that media, all our various technological appendages, function exactly like walls. When using media we tend to focus only on the messages we choose to send and receive through the paths laid out before us. But if we really want to know who has true power in the world we should seek the people designing the path; those who construct, own and operate the media through which we live our lives.

This is a story about how Steam, Twitter and the App Store came to exist. It’s about how these services present themselves as our friends while behaving as our enemies. It’s about how they stole the internet from us, creating a place where everything is ‘free’ but liberty remains unavailable. It’s about how their forebears stole our very language from us, creating a lexicon in which we have no means of even describing that which cannot be possessed and consumed. It’s about how they filled my head with detritus — with garbage — and sold all my new appendages to the highest bidder. Today I come to reclaim them.

You Died Alone At E3 2014

Projects | June 15, 2014 by Bee Sprawlbug

This week, in honour of this year’s first annual IndiE3 alt-conference, I jammed out my first Twine game! It’s, um, a parody of sorts called You Died Alone At E3 2014 and you can play it right here.

Blowjobs, Loneliness and Glitchhikers

Game Criticism | May 19, 2014 by Bee Sprawlbug

Glitchhikers is a game by ceMelusine, Lucas J.W. Johnson, Andrew Grant Wilson and Claris Cyarron that you can read about and play (for free!) on their website.

In Glitchhikers we follow our protagonist, the Driver, down some lost highway late at night. We may use the keyboard to change lanes, to accelerate or decelerate, and to look out the side windows. These mechanics provide no ‘utility’ in the sense we typically associate with videogames. They do not advance the player towards victory or defeat, nor do they compel her to spend money via microtransactions. They provide no gratifying feedback; there are no excruciatingly-rendered speed lines that spew onto the screen as the Driver accelerates to 120, nor does some down-pitched ‘whoosh’ effect from The Matrix fart out of the speakers every time she slows to 90. She is not competing against some artificial intelligence to snag the most victory tokens from the highway’s three lanes. There are no conspicuous resource crates scattered about for her to collect, no thousand-headed hydra of ‘mission objectives’ snapping at her from the corner of the screen. It is impossible to crash the car.

There is a school of thought in game criticism, which I have labelled The Cult of the Peacock, that doesn’t know what to do with Glitchhikers‘ game mechanics. It looks upon them with a screwed up face and, before making any other comment, utters something to the effect of “the driving controls don’t do anything!” It considers this to be a useful and valid criticism because it regards videogames as designed works whose purpose lies in some distant and mysterious dimension we call ‘fun’. It judges that since these mechanics do not immediately dispense ‘fun’ nor teach the player some skill with which to acquire ‘fun’ they must be superfluous, implicating their designers in the commission of some cardinal design sin. It insists these mechanics will make players confused and disoriented; that any cause not immediately followed by a gratifying and explicative effect is an act of heresy that must be purged from the product in service of clarity and craft. The customers have come to have ‘fun’, it believes, and so it seeks as its righteous purpose to deliver them unit after unit of fungible, systematized, thoroughly user-tested gratification. In other words, this school of thought believes that the purpose of a videogame is to perfect and perform ad infinitum the world’s most prolonged and least eventful blowjob.

Glitchhikers, for its part, is not particularly interested in exchanging gratification for money. It does not regard the player as a ‘John’ the way certain videogames do (either in the sense of “a prostitute’s client” or “a vessel for excrement”). Instead it regards her as one of many tiny inhabitants in its surreal virtual cosmos, imploring her to observe rather than affect; to interact rather than subjugate; to hold a memorable conversation with the world rather than merely ejaculate into it. The game does so, of course, through the very mechanics I’ve been describing, which far from being superfluous are essential to the form of the work.

White Is A Surface

Design, Programming | May 1, 2014 by Bee Sprawlbug

Although I did not participate formally in Ludum Dare this time around, I did make a little Unity sketch based on its theme of ‘beneath the surface’. It’s a sort of 3D spatial poem about whiteness and maleness and the nature of guilt. You can play it here.

Elegant Editor-Only Script Execution in Unity3d

Programming | April 8, 2014 by Bee Sprawlbug

Lately I’ve been doing a lot of Unity programming. I love how easy it is to develop editor tools for my designers and how seamlessly these tools tend to integrate with the runtime environment. My favourite feature is the [ExecuteInEditMode] attribute because it lets me write all kinds of funky real-time level generation tools. (Like extruding 3D meshes from 2D primitives!) But what this attribute sorely lacks is the ability to have code execute ONLY in edit mode, where performance isn’t such a big deal. By default code placed in the Update() method will execute both when the scene changes in edit mode AND during every frame of play mode, making it unwieldy for expensive operations like realtime mesh generation (or even a large number of tiny operations, like setting a renderer’s sorting layer).

Step 1: Execute Only In Edit Mode

Various hacks around the internet purport to solve this problem. Some suggest using conditional compilation directives like #if UNITY_EDITOR. This is helpful for platform-specific builds, but unfortunately code placed within these directives will still execute in the editor’s play mode (which is, of course, where 98% of testing happens). Another approach involves checking a global variable like Application.isPlaying before doing anything editor-specific, but this is less than ideal should you have hundreds of active scripts in your scene (the performance cost of calling Update() on that many components, even if that function contains only one boolean comparison, can add up surprisingly fast). I’ve also found, although I haven’t verified it experimentally, that isPlaying becomes rather unreliable when it mixes with big scenes, custom inspectors and ExecuteInEditMode scripts.

I now use a solution that makes use of both conditional compile tags and a little-known global variable in the EditorApplication class:

[ExecuteInEditMode]
public class CurveGenerator : MonoBehaviour {

#if UNITY_EDITOR
	void Update () {
		if(UnityEditor.EditorApplication.isPlayingOrWillChangePlaymode) {
			this.enabled = false;
		} else {
			// editor code here!
		}
	}
	#endif
#endif

}

Here’s how this works. In edit mode, isPlayingOrWillChangePlaymode will always return false; thus, the editor-only code located within that else statement will execute every time Update() is called (generally every time the scene changes). In play mode isPlayingOrWillChangePlaymode will always return true, causing the MonoBehaviour to disable itself on the very first Update() and cease hogging performance beyond the first frame. (This is especially helpful when you’re trying to use the profiler to isolate script bottlenecks.) In compiled versions of the game the Update() method won’t even exist, saving us the trouble of having to disable it. The result of all this is that you can run horrifyingly-expensive setup code in edit mode that costs virtually no performance during play, which arguably is the entire point of an IDE like Unity.

Now, I know what some of you are thinking: ‘Why not do away with all this ExecuteInEditMode voodoo and simply write a custom inspector? It will never run in play mode and you can use SerializedProperties and GUILayout and all that magic.’ Well, here’s the thing: Custom inspectors act only on currently-selected Unity object(s). Suppose you had a bunch of prefab instances, some of which had overridden properties, and you wanted every single one of them to regenerate their content each time you modified the parent prefab? What if some of your generator scripts modify other generator scripts, and you needed those ones to be responsible for their own regeneration even when not a single one of them is selected (and therefore their custom inspector code is completely unloaded)? What if those scripts used prefabs? ExecuteInEditMode provides an understandable, reliable, and relatively efficient way to let scripts respond to any change in state from anywhere in the IDE. Inspectors will never do that for you.

Lord Bafford’s Manor

Game Criticism | March 11, 2014 by Bee Sprawlbug

Saturday night – 3 AM. I’ve been feeling an irrational urge to play the new Thief. I could not tell you why. I’ve heard that the level design is very good. Sadly, I’ve also heard that the rest of it is a bland, soggy porridge of directionless conspiracy film tropes and cloying AAA panache; caught in the middle, in other words, its various stakeholders unable to decide whether to seek the tone of its predecessors or ape whatever marketing trends were big back when the project hit preproduction. I’ve seen first hand how this happens: The masters of coveted IPs are often better at policing the surface elements of a project (the plot; the art direction; the marketing) than they are at policing the videogame stuff. Thus as a developer you become fixated on pushing a reasonable game design through even if you’ve been ordered to make Garrett into a Vengeance-Driven™ Cool Videogame Anti-Hero™ with a Dead Girlfriend™ standing resolute against a Plague-Ridden Cityscape™. I confess my urge to Twitter in hopes someone will convince me not to buy the thing; @fengxii mistakenly assumes I was talking about my desire to play the original Thief, and implores me to give in. Hmm. That sounds like a better idea.

I’ve played Deadly Shadows before, but never The Dark Project. Its age doesn’t faze me. I pride myself on my ability to jump headlong into ancient videogames, and 1998 is hardly as far back as our medium goes. 800×600 on a high-res 16:10 monitor? Fine. Glaring mouse lag? Okay. Muddy late ’90s textures mapped onto Quake-era BSP trees? Perfect. I could fix all of these things if I wanted to, but that would destroy the original context. I find myself enamoured by Dark Project’s chunky walls, which feel more solid than the elaborate trickery we use today. Here there are no invisible collision volumes warding us away from some bit of twenty-thousand polygon street junk, placed more to afford realistic screenshots than to produce an actual physical environment. There are no normal maps to create the illusion of depth along its brick walls even if, in truth, they are flat. Dark Project’s walls are walls. You can touch them.

The Cult of the Peacock

detritus, Game Criticism | January 5, 2014 by Bee Sprawlbug

It’s easy to forget that at one time all videogames had manuals. I used to like reading manuals. Manuals were cool. Now, instead of manuals, we have interactive tutorials. They take about fifty times longer to produce, three times longer to consume, and players hate them so much that their highest aspiration is to become completely transparent. Currently I spend most of my waking hours developing them. It should come as no surprise that I hate them too.

This is a story about how these things happened. It’s sort of a companion piece to the article I wrote about Liz Ryerson’s Problem Attic in that it examines the reasons why games like that became unfashionable, how this is a bad thing, and what we might do to fix it. It’s a story about the history of interaction design both in academia and the games industry, as well as my experiences travelling through those spaces. It’s a story about how I got the kink in my neck, and the slow death of the videogame manual. It begins with a teapot and ends with a peacock. More than anything, though, it is about apotheosis. There are four parts. Shall we begin?

Fashion, Emptiness and Problem Attic

detritus, Game Criticism | November 2, 2013 by Bee Sprawlbug

Problem Attic is a game by Liz Ryerson that you can read about and play (for free!) on her website.

Any designed work can be decomposed into two different kinds of features: Intrinsic features and extrinsic features. An intrinsic feature is something we judge to be a non-reducible atom of actual value that the audience wants and the work provides—that is, the work’s purpose—while an extrinsic feature is anything that exists solely to realize that purpose, providing no actual value in itself. To design something we must first decide which intrinsic features we hope to provide and then do so as efficiently as possible by devising and iterating on a set of extrinsic ones. Here is a quick example: The intrinsic features of a hammer include ‘delivering impacts to objects’ and ‘inserting/removing nails from rigid structures’, and to best realize these we might iterate on any number of extrinsic ones (such as the hammer’s shape, the materials of which it is composed, or its manufacturing cost).

A product, which is a special kind of designed work, has at least two intrinsic features. One is to perform the task for which it was made; the other is to convince you to buy it. (The next time you hear the phrase ‘ludonarrative dissonance’ ask yourself whether the dissonance you’re discussing might actually stand between ‘what marketing decided would generate money’ and ‘what the designers defiantly attempted to produce’.)

Iterations on a design’s intrinsic features are transformative; they change what the work is on a fundamental level by changing what it does. (A hammer that cannot deliver impacts to objects is no longer, ontologically speaking, a hammer; it has become something else.) Iterations on a design’s extrinsic features are merely ameliorative; they make it better at fulfilling its purpose without changing its nature. Thus we only value extrinsic features insofar as they improve a design’s ability to give us the things we actually want, and we are quite content to discard them as soon as we find more effective ones. Walmart would stop selling hammers if they could figure out how to to market telekinesis. Google would stop making iPhone apps if they could perfect the horrifying spider drones that burrow into your brain through your nasal cavity and telepathically communicate bus directions to you.

The intrinsic features of Art media like literature or film, unlike those of hammers and map APIs, are not easily reducible into language. Whereas to design a hammer involves finding ways of realizing features whose value is readily apparent, to make Art is to search for value lying beyond the edges of our understanding: To capture something we know is important to us even though we cannot quite say why. This is what makes ‘Art’ so famously difficult to define, and why we speak not about ‘novel designers’ or ‘film designers’ but about the authors of these works. Authors are a specialized type of designer who work to realize feelings, concepts or moments; often they attempt to connect in some fashion with our shared humanity. We cannot fully express what their work is for because its value transcends understanding. Thus while conventional design undoubtedly remains useful as a means of iterating towards our authorial objectives (the language by which we communicate mood during a film, for example, is the product of very sophisticated design work) it tells us nothing about what our authorial objectives should actually be nor what our Art becomes when we realize them.

Videogames inherit a little from Art but mostly from product design, which has been kind of a problem for us. As an industry we put faith in the idea that there is intrinsic value in the games we develop, although we don’t think very expansively about what that could be; instead we abstract it, using ugly words like “content” as placeholders for value without ever proving that it truly exists. We then set about designing incredible machines that shuttle players towards these placeholders with extremely high efficiency, which as designers is really what we’re good at. We make the interface as usable as we can because players need it in order to learn the rules. We teach the rules very carefully because players need them in order to grok the dynamics. We shape our dynamics strategically because enacting them is what will stimulate players to feel the aesthetics. Somewhere at the core of all this, we suppose, lives the “content” players are attempting to access: That which we have abstracted away so that we could hurry towards doing safe, understandable product design rather than risky, unfathomable Art. In game design we enjoy paying lip service to aesthetics. What, then, shall we say are the aesthetics that we can package up into 5–60 hours of intrinsic value? Challenge? Agency? Story? Fun? Is ‘Mario’ an aesthetic? How do we stimulate the Mario part of the brain? Oh hey, wait, look over there! Someone is confused about what that UI indicator represents! TO THE DONALD NORMAN MOBILE.

The more time I spend examining my professional work and that of my peers in the games industry, the more I come to believe our near-sightedness has crippled us. We have avoided building sophisticated pleasures that demand and reward the player’s investment, preferring instead to construct concentric layers of impeccably-designed sound and fury over an empty foundation of which we are afraid and at which we can hardly bear to look. We gamify our games, and then we gamify the gamifications, so that many different channels of information can remain open all at once, distracting the player by scattering her attention across a thousand extrinsic reward systems that are, in themselves, of no value whatsoever. We delay the realization that our true goal is not to deliver some fragment of intrinsically valuable “content” rumoured to reside, like a mythical unicorn, in the furthest reaches of our product; our true goal is instead to find something, anything to mete out over the course of 5–60 hours that will somehow account for the absence of real instrinsic value. It is not, therefore, the content that truly matters to us; it is the meting out.

Though the products we design ought to provide value for players and money for us, they currently only pretend towards the former function while actually performing solely the latter one. This deception permits us to continue making intrinsically simple products, avoiding transformative changes to our designs that we fear would render them less digestible; we instead rely upon a pattern of amelioration by technical advancement wherein we deliver as few intrinsic features as possible (and the same ones over and over again), but with intricate fashions heaped upon them. We have abandoned game literacy in the process, and as a result we now find ourselves trapped in the business of making increasingly-elaborate pop-up books.