La Tinaja

My first experiences working on the kind of large-scale, self-directed project that lasts longer than a weekend afternoon or two came building computer games on a Mac Performa starting around 1995.¹ My constant struggle was to balance learning new techniques in order to achieve the functionality I wanted, the temptation to drill further and further into writing up design documents and maps, and sticking with the boring parts long enough to finish the work I had set out to do in the first place.

Since then I have moved on to large projects of other sorts—releasing records, finishing a dissertation, launching and then producing periodical publications, etc.—but I still find myself getting trapped in that no man’s land where the thread of what will move the project a step closer to becoming real gets lost.

Derek Yu started making games around the same time and at a similar scale as a participant in a Windows games scene I was familiar with, but not a part of. In continuing to make games into his adult life, his path was a sort of alternate universe version of one I could have taken (though at a level of success I would not expect for myself, of course). That point of identification helped connect for me a history of disparate projects. Rather than a youthful hobby left behind, those games were perhaps the first in a series of large, self-directed projects in a wide variety of contexts that I have pursued into my own adult life.

And it’s that identification that made Yu’s insight regarding the ‘grind’ really hit home. There’s a point in a large project when the early pitfalls of spending too much energy spinning out elaborate ideas with no plans for implementation give way, but the endgame where all that is left is to check some clearly defined items from an ever-shortening list is still nowhere in sight. This long middle portion is where all of the most important work happens, but not all work that can be done in this moment is equally healthy.

The danger in this middle phase comes from grinding, and I know that I fall victim to this temptation all the time. The problem with grinding is that it feels productive—in fact it usually is actually productive—but focusing only accomplishing sequential, well-defined, or periodic tasks can become the trap. The recurring sense of small accomplishments feels better than opening back up to struggling with the big ideas that will make the work better. The project has forward momentum, but not necessarily a destination. I have been trying to become more sensitive to noticing when I’m at risk of getting stuck in this phase of a project, and reading about Yu’s experience with it helps to establish it as a natural part of long-term work rather than a personal deficiency.

For me, this is the insight I’ll remember most clearly from Spelunky, but of course the primary focus of the book is the game design itself.

Spelunky is a roguelike platformer game, meaning it combines action gameplay along the lines of games like Super Mario Bros. with randomly generated levels, items and entities in the game world that all interact according to the same rule set, and ‘permadeath’.² This combination means that it is a game that rewards both the development of dexterity-based skill and deliberative analysis of how best to use the game’s systems in conjunction with one another. The unforgiving permadeath mechanic raises the stakes by locating all residue of past playthroughs in the player’s accumulated skill and understanding, rather than in the in-game accumulation of stats, items, or other markers of progress.

All of these characteristics of the game will be apparent from the earliest playthroughs, but dozens (or hundreds or thousands) are necessary for the serendipitous potential of the layered systems Yu designed to manifest. It was the unique narrative moments that emerge from these interactions that won Spelunky its devoted community.

Randomness doesn’t signify lack of intentionality, however. The overwhelming sense one gets of Yu in his discussion of his design process is of sensitivity and deliberation. Even as a fan of Spelunky, I had little appreciation for the depth of consideration Yu had put into the design. In the wake of Spelunky (and other procedurally-generated games of similar vintage like Minecraft and Binding of Isaac), there is a glut of games by small teams based on procedurally-generated content. The technique is appealing to small teams because it frees them from the time-consuming obligation of creating designed content, but most of these efforts pale in comparison to Spelunky. Yu’s description of his approach clearly demonstrates that this gap can be attributed to the care, planning, and attention to polish involved in developing his game’s systems beyond the initial engineering task of getting things up and running.

This revelation is both humbling and inspiring. I have been intrigued by the possibilities of emergent behaviors in procedurally-generated games, Twitter bots, and other software agents in the last few years, but have hesitated to pick up the ball for a lack of insight into what distinguishes interesting random output from a simple tech demo. Yu’s experience provides a great map for starting to build these randomized systems in the spiriting of seeing what happens without abandoning the possibility of an intentional and designed product at the end.

Books

• Derek Yu. Spelunky. Los Angeles: Boss Fight Books, 2016.

  Spelunky is the first of the Boss Fight Books series in which the game’s creator writes about his own game. In his post-mortem Yu makes clear the amount of sensitivity and deliberation required to design the systems that create the opportunities for serendipity that Spelunky provides.

  WorldCat » Amazon »