Affording Play2024-03-13T21:27:11+00:00http://mkremins.github.ioMax KreminskiAn offer you can refuse2021-01-07T00:00:00+00:00http://mkremins.github.io/blog/an-offer-you-can-refuse<p>I want to create computer programs that engage in meaningful two-way creative collaboration with human users. For this to take place, I think the notion of “offers” is going to need to become more widespread in human/computer co-creativity research.</p>
<p>In solo creative work, you don’t ever necessarily need to articulate what it is you’re trying to make. You can take action in the medium, <a href="http://worrydream.com/LearnableProgramming/#react">see what happens in response</a>, and iteratively refine the actions you’re taking in order to produce an artifact that more closely matches your intent. A classic creative feedback loop – and all without ever having to explain yourself.</p>
<p>When another person gets involved as a creative collaborator, though, things get tricky. You can’t just take action anymore – they’ll be taking action too, and if your actions aren’t coordinated, you’re likely to end up with <a href="https://www.ribbonfarm.com/2017/01/05/tendrils-of-mess-in-our-brains/">a mess</a>. Some creative forms (like improv) seem at first glance to operate on the premise that action is sufficient for creative coordination and you don’t need to explicitly metacommunicate with your collaborators about intent. But even improv performers do a lot of metacommunication about intent <em>outside</em> of individual scenes. And in most creative forms, effective collaboration involves a <em>ton</em> of dialogue and negotiation about what you want to accomplish, how you want to accomplish it, and why.</p>
<p>There’s something of a gap in existing co-creativity research around the question of how to handle creative metacommunication. In co-creative platformer level design, for instance, the <a href="https://arxiv.org/abs/1901.06417">state of the art</a> involves action-level turn-taking between the human and computer system, but creative intent (on both the human and computer sides) is left almost totally implicit. Either you guess at what your collaborator is trying to achieve from their actions alone, or you just learn to treat them as inscrutable and alien. And if they’re doing something you don’t want, you often can’t even tell them not to do it – let alone tell them <em>why</em> you don’t want to do it in terms of the creative intent you’re trying to enact, as you would with a human collaborator. <em>Negotiating</em> creative intent with your machine collaborator (e.g. by deciding together which creative goals should take precedence over others in a situation where they can’t all be fully realized) is right out.</p>
<p>Where existing systems try to handle creative intent, they usually do so by trying to implement more and better ways for the machine to infer what the human intends from their actions alone. This is neat when it works, but not sufficient: insofar as actions speak, they always say simultaneously too little and too much. Not only do actions fail to reliably communicate their own motivations, they also hint at myriad other possible motivations that the person performing the action never even considered.</p>
<p>This is why I’m excited about the notion of explicit <em>offers</em> in creative collaboration. An offer, in essence, takes a tacit inference about intent and makes it explicit: “Based on what’s happened so far, it seems like we’re trying to achieve this overall goal. I could further advance that goal by doing X. What do you think?”</p>
<p>The term “offer” as I’m using it here originally comes from improv, where it refers to any action that somehow “advances” the scene. Generally improv actors are supposed to accept any offers they receive, since there’s no time to deliberate on whether the overall direction implied by an offer is good or not. But here I’m generalizing the concept a bit. A lot of co-creative systems already implicitly provide users with little details that they can either seize on and elaborate or choose to ignore. (Consider, for instance, <a href="https://mkremins.github.io/publications/EvaluatingViaRetellings.pdf">“extrapolative narrativization”</a> in simulation-driven emergent narrative games.) But crucially, I think an offer is not just a creative action – it’s a creative action <em>accompanied by some explicit means of acceptance or rejection</em>. The structure of an offer not only provides the recipient with something to react to, but also provides the giver with a way to determine whether the recipient is interested in taking the shared creative work in a particular direction. If the system makes an offer and the user rejects it, the system gains information from the rejection that it can incorporate into its understanding of what the user is trying to create.</p>
<p>In the co-creative storytelling game <a href="https://mkremins.github.io/publications/WAWLT_FDG2020.pdf"><em>Why Are We Like This?</em></a>, we’ve been implementing offers via the automatic detection and surfacing of what we call “situations”. First, we query the database for collections of interrelated characters and narrative events that match a certain specified pattern – let’s say the baseline minimum requirements for “love triangle”, or “escalating cycle of vengeance”. Then we present these matches to the user as <em>potential situations</em>, and give them the choice to take an action that <em>reifies</em> the situation in question. Once reified, new actions related to this particular kind of situation are unlocked between these characters: for instance, two characters engaged in an escalating cycle of revenge might unlock a set of actions relating to <em>sworn enmity</em> that enable these characters to act hostile toward one another without any other immediate motivation. But if you don’t want to tell a story that includes sworn enmity, you can also reject the offer and choose to develop some other storyline instead.</p>
<p>In practice, this can start to feel a bit like the <a href="https://gnomestew.com/steal-this-mechanic-microscopes-yesno-list/">palette negotiation</a> that takes place in the tabletop story-making game <em>Microscope</em>. If everyone in your story is supposed to be uncomplicatedly polyamorous, you can reject the system’s offers to help you develop potential love triangle plotlines. But if you’re deliberately delving into the luridest corners of soap opera-space, the system can begin to recognize a pattern of accepted bids in that direction and offer increasingly enthusiastic support.</p>
<p>Note that offers aren’t enough to solve the problems outlined here on their own. The main issue is that they’re too local: they don’t help as much with longer-term or higher-level negotiation of creative intent. For that you need a proper <em>intent language</em>, which I hope to say more about in future posts. But a co-creative system that reasons in terms of offers still represents a big step up from a system that reasons in terms of actions alone.</p>
<p><em>[This is a crosspost from the new <a href="https://mixedinitiatives.github.io">Mixed Initiatives</a> group blog, which will host writing on similar themes from a number of scholar-practitioners in expressive computation, myself included. Check it out!]</em></p>
Highlights from FDG 20182018-08-13T00:00:00+00:00http://mkremins.github.io/blog/highlights-fdg-2018<p>I just got back from <a href="http://fdg2018.org/">Foundations of Digital Games 2018</a>. It was pretty close to my ideal conference experience, by which I mean that there was way too much interesting stuff going on for any human person to possibly experience all of it directly. Nevertheless, I had a bunch of great conversations, met a bunch of cool people, and took a ton of notes, some of which (focusing particularly on the highlights or else I’d never be able to get this post out the door) I’ve attempted to summarize below.</p>
<hr />
<h4 id="pcg-workshop">PCG Workshop</h4>
<p>The Workshop on Procedural Content Generation, better known as the <a href="https://www.pcgworkshop.com/workshop-program/">PCG Workshop</a>, was – for me, at least – one of the main highlights of the conference.</p>
<p>The workshop started out with a presentation about the <a href="http://gendesignmc.engineering.nyu.edu/">Generative Design in Minecraft Competition</a>, which challenged participants to make a generator that could be given an arbitrary predefined area within a Minecraft world and somehow construct a fitting settlement within that area. This competition is especially exciting to me as a way to push forward the state of the art in procedural <em>adaptation</em> – not generating a new thing totally from scratch in a way that wipes out whatever was there before, but somehow accomodating what already exists and generating something new that fits alongside it. This capability is essential for successful mixed-initiative creative tools, which have to be able to accept meaningful creative input from a human user rather than just overriding everything the user suggests with more computer-generated ideas, so I’m excited to see a PCG competition that awards points partly based on respect for what was already there prior to running the generator.</p>
<p><a href="https://twitter.com/annetropy">Anne Sullivan</a> presented a neat paper on <a href="http://www.asdesigned.com/tarot/">tarot-based narrative generation</a> that makes interesting use of narratological theory (specifically Christopher Booker’s <a href="https://thewritepractice.com/basic-tragedy/">five-part definition of tragedy</a>) in conjunction with the fact that tarot cards can be presented in either an upright or reversed position to set the emotional valence of their meaning. Essentially, each tarot card has a fixed symbolic meaning, but can be interpreted either positively or negatively depending on its position; cards are thus drawn at random to fill certain slots in the overall story arc, and presented either upright or reversed depending on whether that part of the arc is positively or negatively flavored. My favorite thing about this project is the fact that you can choose to redraw individual cards if you like the story as a whole but would prefer to change one bit of it – this brings it closer to being a mixed-initiative story generation tool without requiring the user to actually write any text of their own.</p>
<p>And I presented my <a href="https://mkremins.github.io/publications/GardeningGames.pdf">position paper</a> on what we as PCG researchers stand to gain by recognizing things like Animal Crossing as a distinct category of generative games: <em>gardening games</em>, which revolve around dynamics of cultivation and caretaking in collaboration with ongoing slow generative processes. These games stand in opposition to <em>mining games</em> like Minecraft, in which gameplay is essentially extractive or consumptive and procedural content generation is used to generate tons of individually disposable artifacts for the player to consume. (My <a href="https://docs.google.com/presentation/d/1mymgz-junqqUtYJ3mwbIOftU552gswLgYESn9zHG_rQ/edit?usp=sharing">slides</a>, including speaker notes, are also available, and those who’ve been following me for a while might remember my earlier <a href="https://twitter.com/maxkreminski/status/977591410281955328">zine</a> on the same topic.)</p>
<h4 id="games-crafters-play">Games Crafters Play</h4>
<p>Probably my favorite talk of the whole conference was <a href="https://twitter.com/annetropy">Anne Sullivan</a>’s presentation on her work (in collaboration with <a href="https://twitter.com/AnaSalter">Anastasia Salter</a> and <a href="https://twitter.com/gillianmsmith">Gillian Smith</a>) on the folk games played in fiber and textile crafting communities – i.e., communities of people who recreationally make physical stuff with their hands using fiber or textiles. There’s a ton of interesting angles from which to look at this paper, but two stand out as especially interesting to me.</p>
<p>First and foremost, I’m super excited about games in which the process of play naturally results in the player having created something by the end of the game, and these crafting games all fall into that category. I’ve talked about sewing-machine territory-control game <a href="https://web.archive.org/web/20170721230552/https://www.disneyresearch.com/project/threadsteading/">Threadsteading</a> (which Gillian also worked on) and Porpentine’s <a href="http://aliendovecote.com/uploads/twine/empress/empress.html">With Those We Love Alive</a> as examples of this sort of thing before, and this is also the main reason I will never stop yelling excitedly about Spore. From this perspective, the games that crafters play are full of game design patterns meant to encourage creativity, and – as such – could serve as a rich vein of inspiration for anyone who wants to develop more games of this kind.</p>
<p>But also, these crafting games represent an especially clear example of how games not only embody but also reinforce and propagate values – in this case, the values (including creative expression, education, and community support) of the crafting communities who play them. Since a lot of people first get into crafting communities by responding to open calls to participate in these kinds of games, the games might actually serve as a means of enculturation, or a way of introducing new community members to these values for the first time.</p>
<p>This has some obvious connections to the idea of games as rituals, and makes me wonder if maybe the social functions of folk games are inherently closer to the surface than they are in games designed by individuals or smaller teams. Maybe, through many repeated cycles of deliberate incremental modification and imperfect retransmission by the people that play them, folk games are naturally worn down (like river rocks worn smooth by centuries of erosion) to something close to their essential social function. Either way, it’s a neat mental image.</p>
<h4 id="twitch-workshop">Twitch Workshop</h4>
<p>To the best of my knowledge, <a href="https://sites.google.com/ucsc.edu/fdg-twitch-workshop/papers">this event</a> was the first of its kind: a dedicated workshop for researchers who’re doing stuff with gameplay streaming platforms like Twitch to meet up and compare notes. Papers came from people with a wide range of academic backgrounds; some (like <a href="https://twitter.com/chardr27">Charlie Ringer</a>) were using machine learning to <a href="https://www.charlieringer.com/files/Ringer_FDG_2018.pdf">identify highlight moments</a> in streams, some (like <a href="https://twitter.com/mrj_games">Mark R Johnson</a>) were studying the demographics of streamers and the economics of being one, and some were trying to do things like more deeply understand the phenomenon of toxicity in chat.</p>
<p>Neither <a href="https://twitter.com/mediocregiraffe">Raquel Robinson</a> (the workshop’s main organizer) nor I had papers in the workshop, but we also both got a chance to briefly talk about our own relevant work. Raquel discussed her project <a href="https://escholarship.org/uc/item/6mb4f7hb">All the Feels</a>, an exploration into the design space of what you can do by making a streamer’s biometric data visible to their audience during play. I acted as a sort of unofficial representative of <a href="https://twitter.com/scholarsplay">Scholars Play</a>, a Twitch channel run by an ever-evolving group of UCSC game scholars (myself included) where we stream ourselves playing games and academically critiquing them in real time.</p>
<p>Toward the end of the workshop we discussed some possible next steps for further organizing and growing the community of researchers interested in game streaming. I’m excited to see what’s next for this nascent subfield of games research; streaming already plays a major role in the culture surrounding games, represents a kind of asymmetric performative play that confounds a lot of traditional ideas about the boundary between the player and the spectator, and should be taken into account as part of the game design process a lot more frequently than it currently is, but it seems to be relatively understudied nevertheless. Hopefully that’ll start to change soon!</p>
<h4 id="posters">Posters</h4>
<p><a href="https://twitter.com/jd7h">Judith van Stegeren</a> is working on <a href="https://judithvanstegeren.com/assets/1807-towards2018vanstegeren-fdg2018.pdf">natural language generation for text-based games</a>, and was presenting a <a href="https://judithvanstegeren.com/assets/1807-towards2018vanstegeren-fdg2018-poster.png">poster</a> on a text-based game that uses super-compressed shorthand messages from some sort of public emergency broadcast system as an open data source. This is especially interesting to me because a number of text-based games I’ve worked on (including <a href="https://mkremins.itch.io/epitaph">Epitaph</a>, the current prototype build of <a href="https://mkremins.itch.io/starfreighter">Starfreighter</a>, and a few forthcoming ones) also make unusually extensive use of procedural text, and the intersection between “text-based game design” and “deeply procedural text” is small enough that it’s basically <em>always</em> refreshing to talk to someone else who’s working on similar stuff.</p>
<h4 id="curiosity-in-games-workshop">Curiosity in Games Workshop</h4>
<p>This was another all-around impressive bunch of talks. Unfortunately <a href="http://curious-games.org/">this workshop</a> was held on the final day of the conference, and by that point I didn’t really have it left in me to stick around for the whole thing, but I did see the entire first block of presentations, a couple of which I found especially intriguing.</p>
<p>The first of these was <a href="https://twitter.com/mjntendency">Mark Nelson</a>’s paper on <a href="http://www.kmjn.org/publications/CuriousUsers_FDG18-abstract.html">Curious Users of Casual Creators</a>, which focused on a phenomenon that the authors observed when testing a <a href="http://computationalcreativity.net/iccc2015/proceedings/10_2Compton.pdf">casual creator</a> (essentially a lightweight creative tool that trades power for ease or enjoyability of use) for mobile games: namely, that some users seemed to gravitate toward exploring the boundaries of what the tool could do rather than actually making anything in particular. This reminded me of Scott McCloud’s <a href="http://fullcollstudentbloggers.blogspot.com/2013/12/artists-in-quadrants.html">four types of artists</a>, particularly the category of “formalists”: artists who are “interested in examining the boundaries of an art form, stretching them, exploring what the form is capable of.” I’d half-forgotten about McCloud’s typology until I saw this talk, but maybe it (or something like it) has useful implications for designers of creative tools!</p>
<p>And then there was <a href="https://twitter.com/MikhailJacob">Mikhail Jacob</a>’s paper on collaborative AI/human improv. Not only do I think AI/human improv is an inherently interesting idea (for many of the same reasons that I’m interested in <a href="https://twitter.com/maxkreminski/status/748169430518108160">teaching robots to dance</a>), I’m also super intrigued by part of the methodology used here. The authors noticed that artists in a lot of fields make use of “arcs” of some sort (from narrative arcs in storytelling to visual movement arcs in visual art to tension/release arcs in music), and tried to generalize this pattern to a sort of unified theory of <em>creative arcs</em>. To do this, they drew on Margaret Boden’s <a href="https://pdfs.semanticscholar.org/52f1/53075b22469fa82ecb35099b8810e95c31f6.pdf">theory of creativity</a> as existing within a three-dimensional space where the dimensions are novelty, surprise and value, and framed their creative arcs as curves within this space. An AI agent could then try to figure out what kind of curve through creativity-space it was currently on and use this knowledge to decide what action it should perform next during creative collaboration (e.g. improv).</p>
<p>…yeah. A lot to take in at once, especially on the last day of a week-long conference, but it seems like the authors are on to something fundamentally interesting here, and I’m super curious to see how further development of the underlying theory might play out. This talk also convinced me to bump Boden’s book up to the top of my reading list. (In fact, I started reading it on the flight back from Europe.)</p>
<h4 id="mould-rush">Mould Rush</h4>
<p>I wasn’t actually able to make it to this talk in person due to a time conflict, but I did get to have a brief conversation with the speaker (<a href="https://twitter.com/kim_raphael">Raphael Kim</a>) a bit beforehand. He was presenting a paper about his game <a href="https://biohackanddesign.com/2018/07/13/mould-rush/">Mould Rush</a>, a kind of strange hybrid physical/digital multiplayer territory control game in which you strategically mess with the real-time growth of actual, living fungi and other microbes in order to win.</p>
<p>This game does a startlingly good job of tying together several of the threads that I mentioned in my discussions of the other highlights. As its creator pointed out to me, if you interpret biology as a generative method, it fits the definition of “gardening game” that I used in my own talk pretty well, albeit a bit more literally than most. The process of play seems to inherently generate these neat-looking boards that you can then take pictures of and share as co-created artifacts. And at present, if you want to play the game at all, you have to play it via Twitch chat.</p>
<p>Perhaps most interesting, looking at Mould Rush through the gardening games lens, is the game’s inherent (and deliberately designed) slowness. The microbes take time to grow and propagate, forcing the player to think on an unusual timescale and thereby calling their attention to the process of growth itself. Moreover, the exact behavior of the microbes (i.e., the generative processes) is largely outside the player’s control. This seems to force the player into a position of compromise with the game, and thereby with the other living organisms that are participating in it – deemphasizing the player’s role in exactly the way that gardening games are meant to.</p>
<hr />
<p>Alright, I think that’s about it for now. There were actually a few other talks and conversations that I’d like to discuss further, but in each case my thoughts on the subject are either (a) too complicated for a super-short writeup like the ones I’ve been doing here or (b) not yet developed enough that I’m actually sure what I want to say. It also doesn’t help much that the conference was deeply inspiring to me, in such a way that I want to jump right back into <em>making stuff</em> as soon as possible. So I’ll leave it at that – poke me on <a href="https://twitter.com/maxkreminski">Twitter</a> if you want to chat about anything I mentioned here!</p>
History generation in Epitaph2018-01-09T00:00:00+00:00http://mkremins.github.io/blog/history-generation-epitaph<p>A little while ago, someone emailed me to ask how my game <a href="https://mkremins.itch.io/epitaph">Epitaph</a> procedurally generates histories for its various procedurally generated alien civilizations. In response, I wrote up a quick summary of how Epitaph actually works behind the scenes. Going back and re-reading that response today, I think it’s substantial and potentially useful enough to repurpose as a <a href="http://matt.might.net/articles/how-to-blog-as-an-academic/">“reply to public”</a>, so I’m reproducing it here for the curious.</p>
<p>(Note that this post contains what could loosely be termed “spoilers” for Epitaph. You have been warned.)</p>
<hr />
<p>In Epitaph, there’s two kinds of things that can happen to a civilization – <a href="https://github.com/mkremins/epitaph/blob/master/src/epitaph/events.cljs">events</a> and <a href="https://github.com/mkremins/epitaph/blob/master/src/epitaph/techs.cljs">techs</a>.</p>
<p><em>Techs</em> are organized into something approximately equivalent to a <a href="https://en.wikipedia.org/wiki/Technology_tree">tech tree</a>. They can be taught by the player, but can also be discovered independently by the civilization. Each individual tech has a set of <em>prerequisites</em> – other techs that have to be known before this tech becomes available. Many techs influence the odds that certain events will happen: a tech can have an associated map of <em>event chances</em> which either increase or decrease the per-tick likelihood that certain events will occur. A few techs (writing, the printing press, and networked computers) also increase the <em>tech discovery chance</em>, i.e. the per-tick odds that this civilization will discover a new tech on their own.</p>
<p><em>Events</em> are divided into two categories (extinction and flavor events), but they function pretty much the same outside of the fact that extinction events result in a “game over” for this civilization and flavor events don’t. Like techs, events can have their own associated <em>event chances</em> maps that influence the odds of other events happening in the future. Events also have <em>implicit prerequisites</em> in that an event can only happen if something (either a tech or another event) has already set the likelihood of this event to something greater than zero. (<a href="https://github.com/mkremins/epitaph/blob/master/src/epitaph/civs.cljs#L110-L114">A few events</a> have nonzero likelihood of occurring from the moment the civilization is first generated, and the chance of discovering a new tech is likewise always greater than zero.)</p>
<p>The textual descriptions of events and techs are generated with grammars. <a href="https://github.com/mkremins/epitaph/blob/master/src/epitaph/techs.cljs#L94-L101">Here’s an example</a>. Certain game-wide global variables (like the current stardate) and civilization-specific global variables (like the name of the largest city, or the name of the primary crop they cultivate) can also be substituted in. In fact, any civilization-specific bit of text that appears in the descriptions of multiple events or techs is set up front as a global variable for that civilization at the moment the civilization is first generated. (You can see <a href="https://github.com/mkremins/epitaph/blob/master/src/epitaph/civs.cljs#L96-L108">the full list of these global variables</a> in the source code for the <code class="language-plaintext highlighter-rouge">epitaph.civs/gen-civ</code> function.) This ensures some consistency across multiple chunks of generated text for the same civilization, although there’s no guarantee that all of these variables will ever actually be surfaced for any given civ.</p>
<p>During gameplay, there’s nothing especially fancy going on. On each tick, the game just looks at the odds that certain things will happen to each civilization, and rolls the dice to see which (if any) will actually take place.</p>
<hr />
<p>If you want to read more about the procedural generation of history, I strongly recommend Jason Grinblat and Brian Bucklew’s paper on <a href="https://dl.acm.org/citation.cfm?id=3110574">history generation in Caves of Qud</a>. One particularly neat trick they use to generate coherent historical narratives is to “subvert cause and effect” by first generating sequences of historical events, then coming up with after-the-fact narrative rationalizations for these events. Jason gave <a href="https://www.youtube.com/watch?v=ClGAApZYIvI">a talk on this approach</a> at the 2017 Roguelike Celebration, and will be presenting <a href="http://schedule.gdconf.com/session/procedurally-generating-history-in-%27caves-of-qud%27/854704">an expanded version of the talk</a> that also touches on history generation in Epitaph and Dwarf Fortress at GDC later this year.</p>
Embodied social behavior in VR2018-01-03T00:00:00+00:00http://mkremins.github.io/blog/embodied-social-behavior-vr<p>Today I ran into a <a href="https://www.youtube.com/watch?v=9JGkpGM2ENc">video</a> that highlights something I’ve been thinking about for a while: if we want to use VR to tell (non-farcical) stories about characters interacting in 3D space, we need to figure out how to recognize and respond to embodied social behavior – things like body language, personal space, and contextually (in)appropriate physical actions for the current social practice.</p>
<p>My favorite part of the video is the bit from ~9:00-9:25. The player egregiously violates dozens of implicit social rules at once, yet there’s no reaction whatsoever from the game:</p>
<iframe width="560" height="315" src="https://www.youtube.com/embed/9JGkpGM2ENc?start=540&end=565" frameborder="0" gesture="media" allow="encrypted-media" allowfullscreen=""></iframe>
<p>Crafting socially believable NPCs is already a huge challenge for non-VR games, but VR adds a whole new level of difficulty. Existing frameworks for scripting conversation and other forms of social behavior in game characters are totally unequipped to deal with body language and gesture.</p>
<p>One potential research direction here is to construct computational models of <a href="https://en.wikipedia.org/wiki/Proxemics">proxemics</a> – basically how humans use space in interpersonal interactions. Some of the VR projects I worked on at the <a href="http://mobilemedia.usc.edu/">Mobile & Environmental Media Lab</a> actually dealt with proxemics to a certain extent! But the intersection between VR and proxemics is so huge that we were really only able to scratch the surface during my time there.</p>
<p><img src="/img/proxemics.png" alt="" /></p>
<p>The term “social practice” that I used earlier in this post also points to another potential research direction. I first encountered this term in the context of Emily Short and Richard Evans’s work on the interactive fiction engine <a href="https://versu.com/about/how-versu-works/">Versu</a>, which uses the concept of social practices to model the context-sensitivity of social behavior on a much deeper level than I’ve seen anywhere else.</p>
<p><em>(This post was <a href="https://twitter.com/maxkreminski/status/948692681412284416">rescued from Twitter</a> thanks to <a href="http://nearthespeedoflight.com/">Jason</a>, who tirelessly refuses to let me forget that I do in fact have an actual blog.)</em></p>
<style>iframe{margin-bottom:1rem;}</style>
Highlights from the 200 Word RPG Challenge2017-05-28T00:00:00+00:00http://mkremins.github.io/blog/highlights-200-word-rpg<p>I first became aware of the <a href="https://200wordrpg.github.io/">200 Word RPG Challenge</a> in April of this year, and was immediately impressed with both the elegant simplicity of the challenge itself and the quality of some of the past entries. One thing that really stands out to me about the challenge is how well it matches Robert Yang’s description of “games as conceptual art”:</p>
<blockquote>
<p><strong>Games are primarily conceptual / performance art; games are culture; it’s more important to witness a game than to play it.</strong></p>
<p>Most people haven’t played most games. Conversations about games often start with “oh yeah I’ve heard about it” or “I haven’t played that yet.” Thinking about the vast intergalactic politics of EVE Online is so much more interesting than trying to play it, and watching high-level Starcraft play is much more interesting than drilling on a specific build yourself.</p>
<p>To “consume” a game, it is no longer necessary to play it. Rather, the most important thing about a game is that it exists, because that means you can think about it. (Or maybe, games don’t even have to exist? Consider the endless press previews and unreleased games that engross so many people. These are purely hypothetical games that are often better than playing the actual finished product.)</p>
<p><strong>The concept, and your explanation of that concept, and your audience’s understanding of that concept, is your game.</strong></p>
<footer>Robert Yang, <a href="http://www.blog.radiator.debacle.us/2015/10/not-manifesto.html">“Not a manifesto; on game development as cultural work”</a></footer>
</blockquote>
<p>The vast majority of the entries to the 200 Word RPG Challenge weren’t playtested prior to submission, and I’m willing to bet that most of them won’t ever be played at all. But that doesn’t matter, because in this context, the experience of playing the games isn’t really the point – a challenge entry can be “successful” without ever being played so long as people read about it, think about it, talk about it, and derive inspiration from it.</p>
<p>With that in mind, I wound up reading through a lot of the 2017 challenge entries, and I came away from the experience with a head full of new ideas about game design. So I figured I’d go through and highlight some of my personal favorite entries, in the hopes of spreading and provoking discussion of the concepts they embody.</p>
<hr />
<h4 id="chromed-poets"><em>Chromed poets</em></h4>
<p>A surprising number of this year’s challenge entries managed to work in the composition of poetry as a game mechanic, and <em><a href="https://200wordrpg.github.io/2017/rpg/2017/04/22/Chromedpoets.html">Chromed poets</a></em> is probably my favorite of these. Between the prompts you’re given (“who you are, what you pilot, why you fight”…) and the requirement that each haiku you compose has to somehow answer your opponent’s previous haiku, the game very effectively recreates the feel of the psychological back-and-forth between rival pilots in Gundam’s extended space-mecha duel sequences.</p>
<p>I’m also a fan of how tightly constrained the poetry composition mechanic is here. In games where players have to create stuff, the fear of the blank canvas and the anxiety of being judged by other players can easily intimidate them into mediocrity. Tightly constraining the creative parts of gameplay (as <em>Chromed poets</em> does with its use of the strict haiku form, its topic prompts, and its list of goal words) has two key benefits: it (1) gives players <em>something to react to</em> instead of a blank canvas, and (2) relieves some of the anxiety of creating in front of others – since you can blame the constraints, instead of your own creative ability, if the stuff you make isn’t any good.</p>
<h4 id="no-mistakes-only-deeper-plans"><em>No Mistakes, Only Deeper Plans</em></h4>
<p>On Twitter I described <em><a href="https://200wordrpg.github.io/2017/rpg/finalist/2017/04/22/NoMistakesOnlyDeeperPlans.html">No Mistakes, Only Deeper Plans</a></em> as <a href="https://twitter.com/maxkreminski/status/856258727518851074">“a clever mechanical interpretation of heist-movie logic”</a>, and I stand by that description today. The division of gameplay between the planning and execution stages of the heist, with failures during execution kicking you back into the planning phase to explain how that was actually “all part of the plan”, perfectly captures the rhythm of my favorite heist scenes in film. I also love how the game suddenly strips you of the ability to explain away your failures, but only after you’ve gotten used to having it – the loss of this ability really drives home the unraveling of the meticulously thought-out plan, and sets the stage for an especially energetic and thrilling final act.</p>
<h4 id="thank-you-for-the-feast"><em>Thank you for the feast</em></h4>
<p>One thing I find especially compelling about <em><a href="https://200wordrpg.github.io/2017/rpg/2017/04/19/Thankyouforthefeast.html">Thank you for the feast</a></em> is the way it piggybacks on an existing social ritual, taking as its setting a literal dinner party between close friends. Another is the way it seems to deliberately blur the lines between in-character and out-of-character actions. You’re told to do a certain amount of character creation and worldbuilding at the start of the game, but you’re also instructed to “have your meal and enjoy the time spent with your friends” before the closing round of accusations and explanations – seemingly leaving it up to you to decide how much you want your out-of-character relationships and interactions to <a href="https://nordiclarp.org/2015/03/02/bleed-the-spillover-between-player-and-character/">bleed into</a> the final scene of the game.</p>
<h4 id="bullets"><em>Bullets</em></h4>
<p><em>Chromed poets</em> uses mechanics to recreate the feel of a Gundam fight scene. <em>No Mistakes, Only Deeper Plans</em> uses mechanics to recreate the logic and pacing of a heist movie. Continuing in this vein, <em><a href="https://200wordrpg.github.io/2017/rpg/2017/04/22/Bullets.html">Bullets</a></em> is notable for the way it uses mechanics to recreate the dramatic tension of a <a href="https://en.wikipedia.org/wiki/Mexican_standoff">Mexican standoff</a>.</p>
<p>My favorite thing about this one is that each character to enter the scene is responsible for introducing the previous character – meaning that the character you’re playing is decided not by you, but by the player who goes after you. I also really like that when your character is shot, you get to make a choice between taking damage and exercising narrative agency (declaring something about another character) or avoiding damage and relinquishing narrative agency (having another character make a declaration about you). The dynamic of having “your” characterization dictated by everyone <em>except</em> you is incredibly intriguing to me – more games should explore this!</p>
<h4 id="trolls"><em>TROLLS</em></h4>
<p>There’s not much room for worldbuilding in 200 words, but the way <em><a href="https://200wordrpg.github.io/2017/rpg/finalist/2017/04/19/TROLLS.html">TROLLS</a></em> manages to recall such a particular flavor of online conflict (from the days of old-school web forums) shows how far you can go with just a few well-chosen turns of phrase. The use of ALL CAPS TEXT (or rather, “TROLLSPEAK”) and the fact that the mechanism for attacking another player is called “BLOG POST” both carry a lot of weight here – all-lowercase text and a mechanic labeled “callout” would put in mind a markedly different era of trolling.</p>
<p>Unlike <em>Thank you for the feast</em>, which deliberately blurs the line between in-character and out-of-character actions, <em>TROLLS</em> attempts to create a clear demarcation between player and character, explicitly instructing you not to “draw on you, the player’s, insecurities” during character creation. This is important given that the whole game revolves around attempting to discover and mock your opponents’ insecurities – a dynamic that could cause a lot of interpersonal harm if too much bleed was permitted. I also wonder if the game’s focus on insecurities related to <em>physical appearance</em> could be an attempt (albeit a limited one) to discourage attacks based on race, gender, sexuality, and all the other axes of marginalization that real-life trolls frequently employ against their targets.</p>
<p>One final step the game takes to establish itself as a separate space comes at the very end, in the form of a pact between the players “never to speak or write as you have just done” – essentially having the players explicitly disavow their characters’ actions. I find this part especially neat since it’s a kind of built-in <a href="https://twitter.com/maxkreminski/status/856580952088223744">“de-roleing” ritual</a>, which I don’t think I’ve ever seen before in a tabletop game.</p>
<h4 id="marked"><em>Marked</em></h4>
<p><em><a href="https://200wordrpg.github.io/2017/rpg/2017/04/23/Marked.html">Marked</a></em> borrows from Porpentine’s <em><a href="http://aliendovecote.com/uploads/twine/empress/empress.html">With Those We Love Alive</a></em> the mechanic of drawing meaningful sigils on your arms as part of play. In <em>Marked</em>, however, the sigils represent spells cast in a real-time witches’ duel, with both you and your opponent simultaneously struggling to complete each sigil in time to counter the other’s next move. Under the rules as written, I suspect this game would be too chaotic to play well in real life, but I’m still fascinated by the idea of games that leave behind a lasting physical record of play – whether a series of markings on the player’s body, or a quilted gameboard produced by a session of <em><a href="https://www.disneyresearch.com/project/threadsteading/">Threadsteading</a></em>.</p>
<h4 id="redacted"><em>[REDACTED]</em></h4>
<p>Tabletop RPGs usually treat character sheets (and other kinds of player-maintained documentation) as non-diegetic parts of the game’s “user interface”: they don’t exist in the game world, and are present exclusively for the convenience of the players. <em><a href="https://200wordrpg.github.io/2017/rpg/2017/04/15/REDACTED.html">[REDACTED]</a></em>, with its diegetic character sheets, represents an exception to this rule. Player characters are spies during the Cold War, character sheets represent the characters’ in-universe dossiers, and words from character sheets can be permanently redacted to grant one-off advantages during play.</p>
<p>I find myself wondering what other kinds of novel mechanics might be created around the alteration of character sheets – maybe give players a way to “attack” or selectively rewrite one another’s sheets? – and what other typically non-diegetic parts of the RPG “user interface” could somehow be brought into the world of the game. In the author comments, the author of <em>[REDACTED]</em> encourages this line of questioning by linking to a <a href="http://story-games.com/forums/discussion/2682/props-and-the-deterioration-of-the-character-sheet">discussion thread</a> that mentions several other possibilities for similar mechanics.</p>
<h4 id="go-on-without-me"><em>Go On Without Me</em></h4>
<p>In a clever inversion of the usual narrative logic of action/horror movies (where every character attempts to survive as long as possible), <em><a href="https://200wordrpg.github.io/2017/rpg/2017/04/23/GoOnWithoutMe.html">Go On Without Me</a></em> tasks players with being the first to heroically sacrifice themselves for the rest of the party. Something strikes me as inherently hilarious about the idea of a whole party of characters each trying their utmost to fail at everything they do, while simultaneously keeping the others from doing the same. Why hasn’t anyone made a videogame about this yet?</p>
<hr />
<p>So there you have it: eight of my favorite entries from this year’s 200 Word RPG Challenge, along with a short description of what I found most exciting or interesting about each one. Although these are the ones I chose to highlight, I definitely want to point out that there’s <a href="https://200wordrpg.github.io/2017entries">a <em>ton</em> of entries</a>, many of which I never even read. There’s also several I read and found really compelling, but just didn’t have enough to say about them (yet?) to justify a review.</p>
<p>If any of these inspire you or lead you to any interesting thoughts, I’d love to hear about it <a href="https://twitter.com/maxkreminski">on Twitter</a>!</p>
Authorial roleplaying2017-05-24T00:00:00+00:00http://mkremins.github.io/blog/authorial-roleplaying<p>If you’re a fiction writer, you might already be familiar with a certain oft-repeated piece of folk wisdom: that you can use personality tests to help flesh out your characters. By filling out a personality test as the character you want to develop, giving the answers you think that character would give, you can force yourself to consider different aspects of the character’s psyche. What do they value most? How do they differ from other characters? What factors weigh on their mind when they’re making decisions?</p>
<p>This practice is perhaps one of the purest forms of <em>authorial roleplaying</em>: as an author, temporarily taking on the role of a fictional character in order to further develop your understanding of the character in question.<sup><a name="1" href="#1-note">1</a></sup></p>
<p>This, however, is by no means the only form of authorial roleplaying that’s out there. Consider, for instance, the practice of playing tabletop RPGs in order to <a href="http://blog.protagonize.com/2014/07/02/roleplaying-for-writing/">develop characters and settings</a> for use in other works – or of meticulously screenshotting and documenting everything that happens in a strategy game, with the ultimate goal of writing up a really good <a href="http://tvtropes.org/pmwiki/pmwiki.php/Main/AfterActionReport">“after-action report”</a> at the end.</p>
<p>A closely related practice, especially prevalent among writers of fanfiction, involves the placement of familiar characters into <em>alternate universe</em> (or <em>AU</em>) scenarios. Extracting characters from their original setting, canon, or context and dropping them into a new environment gives the fanfic writer an opportunity to examine what is most essential or fundamental about the character. What traits, relationship dynamics, and so on remain constant (perhaps out of necessity) even when the setting is changed?</p>
<p>Several of the most popular AU settings – “modern day”, “high school”, and “coffee shop” among them – are noticeably more mundane than the fantastic settings from which characters in fanfic are typically drawn. The popularity of these familiar settings for AU stories can, I think, be explained partly by their utility for authorial roleplaying. Since mundane AUs expose characters to “everyday” situations, fanfic writers working in these settings can draw on their own real-life experiences to concretely envision <em>what-if</em> scenarios that might arise and possibilities for how the characters might react.</p>
<p>Similar practices can also be found in acting.<sup><a name="2" href="#2-note">2</a></sup> Most obvious here is the practice that some actors adopt of remaining in character for extended durations – even when off-camera or offstage – during a run of performance (e.g. the filming of a particular movie). One benefit of this practice, at least in theory, is that it exposes the <em>character</em> to a wider range of situations and stimuli, thus giving the <em>actor</em> more opportunities to consider how the character would react and why.</p>
<hr />
<p>So far, we’ve only discussed how authorial roleplaying can be used to flesh out the model of a character that exists in the author’s head. But couldn’t we also use roleplaying to flesh out the model of a character that exists within a computer?</p>
<p>Authorial roleplaying techniques, it seems to me, could potentially provide a key part of the solution to a longstanding problem in interactive fiction: the problem of crafting non-player characters that are capable of reacting believably to a wide range of player actions, including some actions that the author couldn’t possibly anticipate ahead of time.</p>
<p>Imagine an IF authoring tool in which the author can “train” NPCs by roleplaying as them in hypothetical game situations. By showing the computer how an NPC would react to certain concrete scenarios, the author could also teach the computer how the NPC <em>might</em> respond to similar (but not identical) situations. Authoring would essentially become a form of <a href="https://en.wikipedia.org/wiki/Programming_by_demonstration">programming by demonstration</a>, with the author’s actions as a particular NPC in roleplay scenarios being used as the training examples of how that NPC generally ought to behave.</p>
<p>Some scenarios for authorial roleplaying could be hand-crafted, while others might be procedurally generated using a library of generic or game-specific characters, settings, <a href="https://versublog.files.wordpress.com/2014/05/ptai_evans.pdf">social practices</a>, and so on. Scenarios could even involve the player character, with an AI temporarily taking over the player’s usual role.</p>
<p>Creating an authoring tool with all these features wouldn’t be easy, but it’s also possible to create much less sophisticated tools that still take advantage of roleplaying as an authorial practice. Remember those personality tests? For games that use well-understood models of personality (such as the <a href="https://en.wikipedia.org/wiki/Big_Five_personality_traits">five-factor model</a>) to guide NPC behavior<sup><a name="3" href="#3-note">3</a></sup>, simply including an actual personality test in the NPC creation process could do a lot to help the computer develop an internally consistent characterization of each NPC.</p>
<p>It’s a well-established cliché in creative writing that, at some point during a successful writing process, the characters will “come to life” in the writer’s mind and practically start writing the story on their own. This is only possible, however, once the author has developed a sufficiently deep understanding of each character’s motivations and defining traits.</p>
<p>If we accept that <a href="https://mkremins.github.io/blog/games-storytelling-partners/">games themselves are authors</a>, the creation of lifelike NPCs would likewise seem to hinge on the development of similarly rich models of character personality and motivation within the computer. And in teaching computers to develop such models, I think we could do much worse than to look at the techniques used by human authors – authorial roleplaying among them – for inspiration.</p>
<hr />
<h3 id="footnotes">Footnotes</h3>
<p><a name="1-note" href="#1">[^1]</a> Insofar as <em>authorial</em> roleplaying differs from the ordinary kind, the difference is one of intent: authorial roleplaying is undertaken with the specific goal of developing through play a character that you intend to use in another fictional work.</p>
<p><a name="2-note" href="#2">[^2]</a> As creative practices, acting and writing fanfiction have a lot in common. Both the actor and the fanfic writer must step into the shoes of a character originally created by someone else and work to develop a particular interpretation of that character. Frequently, audience members will judge this interpretation against other portrayals of the same character, and a particularly striking or well-received portrayal may become an accepted standard of characterization for the character in question.</p>
<p><a name="3-note" href="#3">[^3]</a> For example, games based on the <a href="https://www.jamesryan.world/projects#/talktown/">Talk of the Town</a> framework for social simulation, which normally incorporate only procedurally-generated NPCs but could ostensibly be extended with hand-authored ones as well.</p>
Games as storytelling partners2017-03-24T00:00:00+00:00http://mkremins.github.io/blog/games-storytelling-partners<p>What, exactly, is a game? And isn’t that kind of an impossibly loaded question? (It is, but I’m going to try to answer it anyway!) In this post, I’ll be making the argument that it can be useful to view games in general as <em>storytelling partners</em> for their players.</p>
<p>First, let’s go over a few (possibly debatable) assumptions I’ll be making about narrative in games:</p>
<p><strong>The narrative happens in the player’s head.</strong> It is the story the player tells themselves about their experience – the story they construct to make sense of the events unfolding before them.</p>
<p><strong>Even “non-narrative” games have a narrative dimension.</strong> Consider, for example, such a clearly abstract game as Tetris. Despite the total absence of concrete characters, setting, and plot, the experience of playing is still linearized as a narrative in the player’s head.<sup><a name="1" href="#1-note">1</a></sup> As the game progresses, a skilled player may find themselves living out a story of rising tension, spectacular last-second saves, and even an escalating antagonistic relationship with the <a href="http://tvtropes.org/pmwiki/pmwiki.php/Main/RandomNumberGod">RNG</a> as it repeatedly refuses them the piece they need to survive.</p>
<p><strong>The player is necessarily a co-author of the narrative.</strong> No matter how careful you are as a designer, the player will inevitably miss some story-relevant details, misinterpret others, and bring their own unique perspective to the process of interpretation – and that’s before we even get into the issue of <em>player choice</em>! Thus, you cannot make any guarantees about the story the player will actually experience. You can only set up a possibility space that naturally affords certain kinds of narrative experiences for the player to explore.</p>
<p><strong>The narrative is built on buts and therefores.</strong> “I wanted A, so I did B in order to get it. But C got in the way, so I was forced to do D instead…”</p>
<p>Taken together, these four assumptions lead more or less directly to a fifth key point, which is the actual subject of this post:</p>
<p><strong>To play a game is to co-create a narrative with the game.</strong> The player and game, in other words, are <em>creative partners</em>. They take turns reacting to one another’s actions, creating in the process a sequence of interconnected “buts” and “therefores” that collectively comprise a narrative.<sup><a name="2" href="#2-note">2</a></sup></p>
<p>What does this perspective give us? Among other things, it gives us a way to evaluate games based on the kinds of storytelling assistance they provide! For instance, I find that a lot of my favorite games are like <em>good improv partners</em> in their willingness to say <a href="https://en.wikipedia.org/wiki/Yes,_and...">“yes, and…”</a> when I try taking the story in a particular direction.</p>
<blockquote class="twitter-tweet" data-conversation="none" data-lang="en"><p lang="en" dir="ltr"><a href="https://twitter.com/eevee">@eevee</a> the best surprises in games go like this:<br />1. wonder if it'll let me do that<br />2. nah, no way<br />3. [does it anyway]<br />4. holy shit it worked</p>— Max Kreminski (@maxkreminski) <a href="https://twitter.com/maxkreminski/status/722600337379430400">April 20, 2016</a></blockquote>
<p>When I try something a little silly or off-the-wall, the game doesn’t shut me down or tell me I can’t do that. Instead, it recognizes what I was attempting to do and <em>builds on it</em>, reacting in almost exactly the way I was hoping it would – but with an interesting twist of its own that <em>gives me something else to react to</em>.</p>
<p>(Can I catch that dragon with my fishing rod if I use something shiny as bait and line up the throw just right? Haha, there’s no way that would work. Guess it’s worth a shot, thOH F*** WHAT DO I DO NOW)</p>
<p>This builds up a neat little feedback loop of action-and-reaction. The game and I are now batting the storytelling initiative back and forth like a tennis ball, and an interesting narrative has begun to emerge.</p>
<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">"What happens if I do this?"<br />- Good games have an answer<br />- Great games have an unexpected answer<br />- Interesting games raise another question</p>— Dan Hindes (@dhindes) <a href="https://twitter.com/dhindes/status/840492777632751616">March 11, 2017</a></blockquote>
<p>Another way of looking at this feedback loop is through the lens of <em>closure</em>, as discussed by Scott McCloud in <em>Understanding Comics</em>:</p>
<p><img src="/img/mccloud_closure.png" alt="McCloud: "This phenomenon of observing the parts but perceiving the whole has a name. It's called closure. In our daily lives, we often commit closure, mentally completing that which is incomplete based on past experience."" /></p>
<p>McCloud uses the term “closure” to refer to the thing that happens in the reader’s mind when they fill in missing details in a story – like, say, what exactly happened in the “gutter” between two consecutive comic panels. Closure is an essential part of storytelling in comics; you could even argue that a comic alone contains only the skeleton of a narrative, and that the narrative is not <em>realized</em> or <em>instantiated</em> until a reader comes along and does closure to it.</p>
<p><img src="/img/mccloud_accomplice.png" alt="McCloud: "Every act committed to paper by the comics artist is aided and abetted by a silent accomplice. An equal partner in crime known as the reader."" /></p>
<p>In this sense, the narrative of a comic is in fact constructed partly by the reader, who serves as the author’s “silent accomplice” – a storytelling “partner in crime”. Without a closure-committing reader to fill in the gaps, keep a lookout, and drive the getaway vehicle, the story is fundamentally incomplete.</p>
<p>One key difference between games and comics is that games are capable of committing closure <em>back</em>: of “reading” the player’s concrete actions and filling in the gaps between them to interpret the player’s intent. Comics, as a rule, don’t attempt to <em>read the reader</em> and adjust themselves in response; games, as a rule, absolutely do. And because games can and do read the player, they end up behaving more like storytelling partners: capable, to some extent, of “going with the flow”, letting the player guide the story in new directions on the fly.</p>
<p>Perhaps the weirdest consequence of this perspective is that, if you take it really seriously, it starts making sense to think and talk about games as <em>agents</em> – decision-making entities with goals and desires of their own. As an agent, a game can’t really be said to contain a single fixed narrative; it can, however, be said to have certain kinds of narratives that it <em>wants to tell</em>.</p>
<p>This also helps explain the appeal of <a href="https://en.wikipedia.org/wiki/Let's_Play">Let’s Plays</a>, gameplay streams, and gameplay-driven video series like <a href="https://www.youtube.com/playlist?list=PLaDrN74SfdT6FvTs9d2JPLJnVRjnjIlfo">Car Boys</a>. The popularity of these things might at first seem paradoxical: they’re all about <em>watching other people play games</em>, when the fun of games is “supposed to” lie in playing them yourself. But when you change your perspective a little, all of these can essentially be seen as instances of <em>improvisational storytelling</em> in which one of the storytellers just happens to be a game.</p>
<p>I, for one, find this perspective shift immensely exciting. What can we learn by looking at, say, chess as an active storytelling partner for the players? What about Super Mario Bros.? Animal Crossing? Any of a wide variety of sports? I don’t know just yet, but I’m definitely looking forward to finding out.</p>
<hr />
<h3 id="footnotes">Footnotes</h3>
<p><a name="1-note" href="#1">[^1]</a> Jack Post has also written about the narrative dimension of Tetris in particular, and comes to a similar conclusion:</p>
<blockquote>
<p>An abstract and non-narrative game like Tetris has narrative structures, not because it has settings, events and characters, but because of its complex [Narrative Program] and tactic dimensions, and because the interactivity of its gameplay can be analyzed in narrative terms.</p>
<footer>Jack Post, <a href="http://www.ec-aiss.it/monografici/5_computer_games/3_post.pdf">“Bridging the Narratology-Ludology Divide. The Tetris Case”</a></footer>
</blockquote>
<p>In essence, because the experience of interacting with a game can itself unfold as a narrative in the player’s head, a game doesn’t necessarily have to provide any of the things we traditionally think of as “parts of narrative” (plot, characters, setting, and so on) for a “narrative structure” to emerge.</p>
<p><a name="2-note" href="#2">[^2]</a> The perspective I’m taking here is closely related to the <a href="http://game-studies.wikia.com/wiki/Story_Machine">“story machine”</a> approach to interactive storytelling. Under this perspective, a game is essentially a <em>machine for generating interesting stories</em>:</p>
<blockquote>
<p>From this point of view, a good game is like a story machine — generating sequences of events that are very interesting indeed. Think of the thousands of stories created by the game of baseball or the game of golf. The designers of these games never had these stories in mind when they designed the games, but the games produced them, nonetheless.</p>
<footer>Jesse Schell, <em>The Art of Game Design: A Book of Lenses</em> (pg. 265)</footer>
</blockquote>
<p>This is obviously only one of several distinct ways that it’s possible to approach interactive storytelling in games, but it’s a perspective that I find very powerful – especially since it gives us a way to understand narrative experiences in games with few or no “baked-in” narrative elements (such as, say, the majority of sports).</p>
<script async="" src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
Gardening games2016-12-13T00:00:00+00:00http://mkremins.github.io/blog/gardening-games<p><em>[<strong>Note</strong>: an earlier and substantially shorter version of this post appeared in the 2016 edition of <a href="http://www.procjam.com/seeds/">Seeds</a>, the <a href="http://www.procjam.com/">PROCJAM</a> zine.]</em></p>
<p>What kind of games do you think of when you think of procedural content generation?</p>
<p>For me, at least, a handful of especially well-known games spring immediately to mind. Minecraft. No Man’s Sky. Terraria, and its sorta-but-not-really successor Starbound.</p>
<p>In all of these games, the main thing that’s procedurally generated is the <em>terrain</em>. As a player, you can keep moving indefinitely in any direction, and the game will procedurally generate new chunks of terrain as needed to fill in the blanks.</p>
<p>Because the experience of playing these games depends heavily upon procedurally generated content, and because these games are strongly associated with PCG in the popular imagination, I think it makes sense to consider them as a genre of <a href="https://arxiv.org/pdf/1610.03138v1.pdf">PCG-based games</a>. Specifically, let’s refer to them as <em>procedural-terrain exploration games</em>.</p>
<!--Games of this form, in which you spend your time wandering through a procedurally generated world of potentially infinite size, continue to enjoy a great deal of popularity. There is clearly something appealing to players about the kind of [infinite play](http://www.gdcvault.com/play/1022083/Infinite) these games afford.-->
<p>Judging purely by their continuing popularity, these games are undoubtedly successful. Lately, though, something about them has been bothering me, and in the long term, they seem to be completely incapable of holding my interest. When I take my first tentative steps into one of these games, its infinite world seems alive with possibilities – but gradually, as I become more accustomed to the game, playing starts to feel more and more like a repetitive grind.</p>
<p>In this post, I’ll try to explain what exactly it is about procedural-terrain exploration games that makes me feel this way. At the same time, I’ll also try to sketch out my vision for a possible alternative genre of PCG-based games. My eventual hope is that, in moving away from the genre conventions of the procedural-terrain exploration game, we might stumble upon some potential solutions to the problems facing PCG-based games as they currently exist.</p>
<hr />
<p>First, let’s talk about <em>exploration games</em>.</p>
<p>A lot of PCG-based games ask you to <em>explore</em>: to go out into the game world and actively seek out surprises amidst the procedurally generated landscape. Exploration of this kind tends to monopolize your attention; as you explore, you have to pay close attention to the terrain you’re traversing, the landmarks you encounter, and the dangers that beset your path. You must keep your wits about you as you venture ever deeper into parts unknown.</p>
<p>In exploration games that feature large expanses of procedurally generated terrain, this often entails spending a whole lot of time looking at “samey”, repetitive content: the connective tissue that fills the gaps between sparsely distributed points of interest. This gives rise to what Kate Compton calls the <em>10,000 Bowls of Oatmeal</em> problem:</p>
<blockquote>
<p>I can easily generate 10,000 bowls of plain oatmeal, with each oat being in a different position and different orientation, and <em>mathematically speaking</em> they will all be completely unique. But the user will likely just see <em>a lot of oatmeal</em>.</p>
<footer>Kate Compton, <a href="http://galaxykate0.tumblr.com/post/139774965871/so-you-want-to-build-a-generator">“So you want to build a generator…”</a></footer>
</blockquote>
<!--The human brain is *really good* at completely tuning out certain kinds of *non-meaningful* variation. As a result, unless the game gives you a particular reason to care about the difference between two sections of generated terrain (or, for that matter, two bowls of oatmeal), it's all going to start to blur together pretty quickly in your head.-->
<p>In other words: with nothing to distinguish one massive flat expanse of desert from the next, the novelty of scale rapidly gives way to the tedium of picking your painstaking way across another hundred dunes.</p>
<p>What happens when you finally find something interesting – a temple in the desert? In many exploration games, there’s no real mechanical reason to ever visit the same place twice, so the core game loop tends to go something like this: travel until you discover an interesting place; investigate it as thoroughly as you like; take from it any resources you might want or need; and then keep pushing steadily onward, away from the clean-picked remains of your past.</p>
<p>This, as a format, is hostile to narrative. Stories are fundamentally about change, and you can’t witness change in anything or anyone besides yourself unless you observe that thing or person repeatedly over a period of time. If you never encounter the same character twice, none of the game’s characters will ever have any chance to undergo long-term change.</p>
<p>In this sense, the exploration game format imposes strict limitations on the character stories that a game can tell. Any change that occurs in a non-player character must be made evident to the player within the scope of a single encounter. Is it any surprise, then, that the most common form of change for characters to undergo in exploration games is both instantaneously visible and clearly binary?</p>
<p>(I’m talking, of course, about the change from <em>alive</em> to <em>dead</em>.)</p>
<hr />
<p>Now, let’s talk about <em>gardening games</em>.</p>
<p>Gardening games are different. Where the exploration game requires its players to put in more effort if they want to encounter more surprising generated content, the gardening game keeps generating new content in the background – regardless of whether the player is paying attention to it or not – and brings any surprises it generates up to the player on its own.</p>
<p>The surprises of the garden are nothing as monumental as isolated temples in the desert. Instead, they are narrative surprises: surprises of cause and effect, of pushing on one small part of an interconnected system and watching the effects reverberate throughout the whole.</p>
<p>The player can use a variety of tools to exert influence on the garden, but the ultimate outcome is always shaped by forces entirely outside of the player’s control. You can water certain flowers and plant certain seeds, but the weather doesn’t always agree with your choices of which plants to favor. You can try to plant pink flowers over here and purple flowers over there, but don’t be too surprised if – over the course of a few generations – the indiscriminate activity of pollinators erodes the sharp distinction between the two until it falls entirely away.</p>
<p>To play a gardening game is to become intimately familiar with the story of a bounded space as it changes over time. The player’s attention remains fixed on a single, gradually evolving system; it is not scattered throughout a vast world whose individual parts are uniformly disconnected. To know why a garden looks the way it does today is to understand not only the histories of its individual parts, but also of the relationships between them, both past and present. In a garden, each individual flower becomes a character in an ongoing story, with a personal narrative arc all its own.</p>
<hr />
<p>What games are gardening games? Neko Atsume is a gardening game. Animal Crossing is the quintessential gardening game. Stellaris, when played in a certain mostly passive style, has something of the gardening game about it. <a href="https://mkremins.itch.io/epitaph">Epitaph</a>, an idlegame I made for the <a href="https://itch.io/jam/fermi-paradox-jam">Fermi Paradox jam</a>, was initially conceived as – and largely remains – a gardening game.</p>
<p>Twitter bots, too, are garden-like in nature. Just as a gardener plants seeds and allows them to grow, the botmaker sets up a generator and allows it to run, stopping by occasionally to search through its recent output for a harvest of surprising content.</p>
<p>What is it that these games (or “games”) all have in common? One important shared feature, I would argue, is the <em>inexorable passage of time</em>. In most of these games, things will go on happening in the game world regardless of whether you’re actively playing or not.</p>
<p>In Animal Crossing, for instance, the game world’s clock is tied directly to the real world’s, and special events (such as holidays and festivals) are scheduled to happen on certain days in the game even if the player does not play on those days. This has two effects. First, it makes the world feel more <em>alive</em> – or, in other words, less like a solipsistic illusion created solely for the player to experience. And second, it enables you to walk away from the game when you’re bored with the knowledge that there will be new, different stuff waiting for you when you come back tomorrow.</p>
<p>Another important common element is the <em>bounded world</em>. Unlike exploration games, gardening games don’t allow you to keep moving forever in any direction. Neko Atsume gives you exactly one house; Animal Crossing, exactly one town; Stellaris, exactly one galaxy. Hit the physical bounds of the space you’ve been given, and that’s it: you can go no further. This serves to focus your attention and keep you coming back to the same places over and over again, giving the game a chance to show you how these places evolve and change over time.</p>
<p>A third and final key distinguishing feature of gardening games is the <em>absence of a hard failure state</em>. In most of these games, it’s impossible to lose. This dovetails nicely with the inexorable progression of time, whose inclusion in many kinds of games would cause a pressing design problem: players find it frustrating when something causes the game to end while they’re away! By eliminating the “game over” state entirely, gardening games neatly avoid this issue.</p>
<p>In my view, it’s this conjunction of inexorable time progression, bounded space, and the absence of hard failure from which the recognizable dynamics of gardening games emerge.</p>
<hr />
<p>And now, let’s talk about <em>aesthetics</em>.</p>
<p>Space, in science fiction, frequently plays the role of the final frontier: a place full of new land to settle, new resources to extract, and new native inhabitants to subjugate. In many cases, the people who go to space do so in search of a second chance: refugee-colonists fleeing a used-up Earth. <em><a href="https://www.youtube.com/watch?v=sZNzz4SaTYk">A new life awaits you</a> in the off-world colonies – the chance to begin again in a golden land of opportunity and adventure.</em> <!--Sometimes, the devastation they're escaping is explicitly ecological in nature.--></p>
<p>Similarly, exploration games tend to employ procedurally generated content as a kind of <em>infinite frontier</em>. Once you’ve extracted and exploited and consumed your way through a particular chunk of the world, that chunk becomes fundamentally boring. All the surprise is gone: all the doors opened, all the traps dismantled, all the ores mined, all the inhabitants’ stories resolved. Then, the game uses procgen to give you a fresh start – or, in other words, a chance to do the same things all over again.</p>
<p>This, more than anything else, stands out to me as the key difference between exploration and gardening games. In exploration games, to spend time in a place is to <em>deplete</em> it, to make it less and less interesting until there’s no longer any reason to stay. In gardening games, to spend time in a place is to <em>enrich</em> it, to participate in stories and interactions and relationships that make it more interesting by virtue of your understanding of its inhabitants.</p>
<p>Lately, for me, the latter of these two aesthetics holds much more appeal. I’m tired of the boom-bust cycle, of draining places until there’s nothing left and then chasing the infinite frontier to escape the consequences of my actions. Instead, more and more, I find myself leaning towards games that let me satisfy my desire to stay in one place and improve it: my desire, in other words, to be a gardener.</p>
<hr />
<p>A few final thoughts.</p>
<p>The thing I find especially frustrating about procedural-terrain exploration games, even more so than the aesthetics I think they tend to promote, is the way they seem to have captured the popular imagination with regards to PCG. The particular way in which these games apply PCG seems to be making its way into mainstream game design discourse as the de facto <em>purpose</em> of procgen.</p>
<p>This popular conflation of “PCG” with “infinite terrain generation” bugs me because I think it tends to stifle creativity regarding how PCG might possibly be applied. Procedural content generation is an incredibly diverse and general-purpose set of techniques, and I don’t want people to get the impression that procgen is inextricably tied to <em>any</em> specific set of genre conventions – regardless of how I feel about these conventions in particular!</p>
<p><a href="https://arxiv.org/pdf/1610.03138v1.pdf">“PCG-Based Game Design Patterns”</a>, the paper from which I originally took the term <em>PCG-based game</em>, is – in this sense – an incredibly useful read. By setting out a taxonomy of ways in which players might be permitted to interact with procedural generators, it calls attention to largely-overlooked parts of the design space and invites designers to fill them with entirely new kinds of games. If you have any kind of interest in PCG-based games, it’s definitely worth a look.</p>
<p>The notion of <em>gardening games</em> that I’ve been talking about also draws, to a certain extent, on another idea that I couldn’t quite work in anywhere else: the concept of <em>infinite play</em>, as described in <a href="http://www.gdcvault.com/play/1022083/Infinite">this GDC talk</a> by Richard Lemarchand. The fantasy of the infinite frontier, it seems to me, likely has some of its roots in the desire for a sort of infinite play; so too does the gardening game, whose lack of a hard failure state seems to imply that it can continue indefinitely forward into the future.</p>
<p>And now: let a thousand gardening games bloom! 🌺</p>
Controls as language2016-05-19T00:00:00+00:00http://mkremins.github.io/blog/controls-as-language<p>A couple of weeks ago, my friend <a href="https://twitter.com/estebanthinks">Esteban</a> said some stuff on Twitter that got me thinking (again) about the value of looking at a game’s control scheme as a sort of language. <a href="https://storify.com/maxkreminski/controls-as-language">The whole series of tweets</a> is worth a read, but <a href="https://twitter.com/estebanthinks/status/728821263540457473">the concluding tweet</a> in particular effectively sums up a few key parts of the controls-as-language metaphor that I’ve been meaning to write about for a while now:</p>
<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">You want less buttons because each button is a vocabulary word players have to learn, like it was a textbook</p>— esteban (@estebanthinks) <a href="https://twitter.com/estebanthinks/status/728821263540457473">May 7, 2016</a></blockquote>
<script async="" src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
<p>I really like this perspective, but I’ve never seen the logic behind it explicated in detail. So I figured I’d take this opportunity to collect and write up some of my thoughts on <em>controls as language</em>.</p>
<h3 id="expressive-flexibility">Expressive flexibility</h3>
<p>What makes a language a language?</p>
<p>All human languages seem to share a few things in common. One of these things is <em>grammar</em>: a set of rules that collectively define the structure of sentences in the language. Typically, words are grouped into distinct <em>parts of speech</em> such as “nouns” and “verbs”, and the language’s grammar describes where in a sentence you’re allowed to use words belonging to each part of speech.</p>
<p>In the English language, the meaning of a sentence is built from the meanings of its parts. As an example, consider the sentence “Jack and Jill went up the hill”. You can swap out any one of the words in this sentence with another word from the same part of speech without changing the sentence’s overall structure. For instance:</p>
<ul>
<li>Jack and Jill <strong>flew</strong> up the hill.</li>
<li>Jack and Jill went up the <strong>stairs</strong>.</li>
<li><strong>The elephant</strong> went up the hill.</li>
</ul>
<p>…and so on. This is possible because the meaning of each word is <em>orthogonal</em> to, i.e. independent of, the meanings of the other words. It’s legal, grammatically speaking, to replace any noun (for example) with any other noun.</p>
<p>You can even make up entirely new words on the spot and use those instead!</p>
<ul>
<li>Jack and Jill <strong>fleeped</strong> up the hill.</li>
<li>Jack and Jill went <strong>dorf</strong> the hill.</li>
</ul>
<p>What do we know about the meaning of the word “dorf”? Surprisingly enough, the answer isn’t “nothing”, even though we’ve never encountered this word before. In this case, because of its place in the overall structure of the sentence, we can be fairly certain that “dorf” is a preposition – something akin to “up”, “around”, or “through”.</p>
<p>English words are <em>generic</em>. Once you’ve learned the English verb “throw”, you can apply that verb to any noun you want. “Throw” doesn’t care what’s being thrown; its meaning is orthogonal to the meaning of the noun to which it’s applied! You can throw something up the hill, down the hill, or even dorf the hill. You can throw anything, anywhere.</p>
<p>Language, as I use the term here, is characterized by this kind of expressive flexibility: the kind that comes from having generic words, sorted into several orthogonal parts of speech.</p>
<h3 id="axes-of-variation">Axes of variation</h3>
<p>Let’s say we’re making a videogame, and we want to add some variety to the gameplay by populating each level with randomly selected enemies. There are seven kinds of enemies that we can place: red monsters, orange monsters, green monsters, blue monsters, circle monsters, triangle monsters, and square monsters.</p>
<p><img src="/img/enemytypes1.jpg" alt="Seven kinds of monsters" /></p>
<p>This is a good amount of variety, right? With seven distinct monster types for us to draw from when populating each level, players who go back to replay levels they’ve already completed won’t get bored quite so easily.</p>
<p>But we can do better. What if we separate these categories into two different groups – let’s say colors and shapes? Now we’ve still got seven categories, but four of them (red, orange, green, blue) are colors, and three (circle, triangle, square) are shapes. What’s more, every monster we generate will now have both a shape and a color. What does that look like?</p>
<p><img src="/img/enemytypes2.jpg" alt="Three shapes, four colors" /></p>
<p>We haven’t added any new categories, yet the number of distinct enemy types available has nearly doubled! It’s jumped from seven to twelve: one for each cell in the 3 × 4 grid of shapes and colors. This might not seem that dramatic at first, but consider: if we add to this grid only a single additional shape (let’s say pentagons), the number of distinct enemy types will jump to 16, and if we add one more shape or color after that, we’ll be all the way up to 20!</p>
<p>Such rapid expansion of the <a href="/blog/sculpting-possibility-space/">possibility space</a> for monster selection is made possible by the orthogonality of color and shape. You can combine any color with any shape to yield a distinct enemy type; thus, the possibility space grows <em>multiplicatively</em>, rather than <em>additively</em>, with the introduction of each new shape or color. By redefining color and shape as independent <em>axes of variation</em>, we’ve extended our previously one-dimensional possibility space into the second dimension.</p>
<h3 id="parts-of-speech">Parts of speech</h3>
<p>Game designers spend a lot of time talking about <em>verbs</em>: the things that games allow players to do. Many games map each verb to a single <em>input element</em>, be it a mouse button, controller thumbstick, or key on the keyboard. In a typical Mario game, for instance, the A button maps directly to the verb “jump”.</p>
<p>Sometimes, designers extend the linguistic metaphor of “verbs” even further by using the word “vocabulary” to talk about the player’s repertoire of skills. But a vocabulary made of verbs alone is sharply limited in its expressiveness. Where are all the other parts of speech?</p>
<p>It’s always surprised me that most games don’t really have any equivalent to <em>adverbs</em>: discrete <em>ways of doing things</em>, such as “quietly” or “aggressively”, that can be applied to any verb in order to modify its effects. Generic adverbs represent a whole new axis of variation. If you have a seven-button controller and map each button to a unique verb, then the player has seven different things they can do. But if you map four buttons to verbs and three to adverbs that can be used with any verb, you’ve now got twelve possibilities instead!</p>
<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Simple inputs can produce logical combined outputs, allowing for more complex controls without more buttons</p>— esteban (@estebanthinks) <a href="https://twitter.com/estebanthinks/status/728821017997496320">May 7, 2016</a></blockquote>
<p>What’s more, it’s much easier to learn four generic verbs and three generic adverbs than twelve entirely separate verbs. <a href="https://en.wikipedia.org/wiki/Transfer_of_learning">Transfer of learning</a> plays a major role here: if a player learns the adverb “quickly” in conjunction with the verb “walk”, and then learns the verb “hit”, they may be able to transfer their understanding of the generic adverb to the new verb and correctly intuit (without explicit instruction) that the combined phrase “hit quickly” may be used to make a rapid strike.</p>
<p>It’s not just games that can benefit from grouping controls into orthogonal parts of speech. The Vim text editor makes use of an input language with distinct parts of speech rather than a conventional one-keyboard-shortcut-per-action editor control scheme, and is frequently lauded for its power and flexibility as a result.</p>
<blockquote>
<p>Arguably the most brilliant thing about vim is that as you use it you begin to think in it. vim is set up to function like a language, complete with nouns, verbs, and adverbs.</p>
<footer>Daniel Miessler, <a href="https://danielmiessler.com/study/vim/#language">“A vim Tutorial and Primer”</a></footer>
</blockquote>
<p>The Vim command <code class="language-plaintext highlighter-rouge">d2w</code> (“<strong>d</strong>elete <strong>2</strong> <strong>w</strong>ords”) can be understood entirely in terms of the individual characters from which it’s constructed. And anyone who knows <code class="language-plaintext highlighter-rouge">d2w</code> also understands the meaning of <code class="language-plaintext highlighter-rouge">d4w</code>, even if they’ve never previously encountered the latter command.</p>
<h3 id="downsides-and-remedies">Downsides and remedies</h3>
<p>There are, of course, tradeoffs involved in making users learn a full-fledged input language. The larger and less familiar the language, the higher the barrier to entry for new users; there’s a ton of people out there (myself included!) who would sort of like to learn Vim, but who don’t want to put in all the time and energy that it would take to get from zero to barely adequate.</p>
<p>And even once you get that far, you still might not yet be getting enough out of the language to justify your initial investment. Eevee talks about this <em>late-beginner stage</em> a bit <a href="https://eev.ee/blog/2016/05/06/learning-to-draw-learning-to-learn/">here</a>:</p>
<blockquote>
<p>A very frustrating stage of learning a new (spoken) language is the late-beginner stage. You know the basic grammar and understand how the language is generally put together; you just don’t know many <em>words</em>. Learning resources are starting to dry up — everything’s always written for complete beginners — but you struggle to transition to learning from real native media, because you have to stop to look up every other word.</p>
<p>If you stick with it, you’ll eventually claw your way up to a kind of <strong>critical mass</strong>, where you know enough vocabulary that you can start to pick up the rest from context. You no longer need to spend ten minutes fishing through a dictionary just to understand what someone is talking about, and can instead focus on picking up nuance and idioms and more complex grammar. From there, you can accelerate.</p>
<footer>Eevee, <a href="https://eev.ee/blog/2016/05/06/learning-to-draw-learning-to-learn/">“Learning to draw, learning to learn”</a></footer>
</blockquote>
<p>Keeping these pain points in mind, what can we do as designers to help new users overcome the initial difficulty of learning a sophisticated input language?</p>
<p><strong>First</strong>, we can begin by introducing new users to a limited subset of the language: a subset which may lack nuance, but which is <em>good enough</em> for basic tasks. Super Smash Bros. does this pretty well. All of the controls <em>can</em> be combined in a wide variety of different ways, but you only <em>need</em> to know a handful of basic moves to begin playing the game.</p>
<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">But at the same time, those simple inputs ideally allow for basic play from only knowing one or two things to press</p>— esteban (@estebanthinks) <a href="https://twitter.com/estebanthinks/status/728818593794654208">May 7, 2016</a></blockquote>
<p>And <strong>second</strong>, we can occasionally prompt users with new vocabulary items in a way that guides them toward a broader, more idiomatic understanding of the language as a whole. In my own (rather limited) experience, neither Vim nor SSB does a particularly great job of this: both of them mostly leave users to their own devices when it comes to discovering new “words”.</p>
<p>They do both offer guided tutorials, but at the late-beginner stage, you’ll find yourself getting less and less value out of sitting through more contrived lesson scenarios. To keep improving past this point, you have to start actually <em>using the language</em> and learning new words and idioms as they appear.</p>
<p>Instead of relying on tutorials, perhaps a game or tool could do more to help late-beginner users improve by observing their actions and keeping an eye out for certain inefficient patterns of behavior (such as using multiple general-purpose words to achieve the same effect as a single, more specialized word that hasn’t been introduced yet). Then, when it recognized one of these patterns, it could introduce a handy new vocabulary word at the point of need.</p>
<p>This is easier said than done! But altogether, using techniques like these to mitigate the initial difficulty of learning a sophisticated input language might be a way to make such input languages accessible to wider audiences – and, in the process, to encourage the design of more expressive control schemes for games and tools alike.</p>
Sculpting possibility space2016-03-31T00:00:00+00:00http://mkremins.github.io/blog/sculpting-possibility-space<p>One of the best and most unexpectedly compelling things I read last month was Jason Brennan’s post on the value of <a href="http://nearthespeedoflight.com/article/2016_03_18_stating_the_obvious">stating the obvious</a>. So, in the spirit of stating the obvious, I’m going to try to describe a very simple shift in perspective that has nevertheless had a major impact on the way I think about programming.</p>
<p>The conventional view of programming is <em>additive</em>: you start with an empty program that doesn’t do anything, sort of like a painter’s blank canvas, and gradually build it up into something useful by adding capabilities. This attitude is reflected in the language we use to describe programming: we “write code”, “make apps”, and “build software”, using verbs that capture the sense of creating something from nothing to express our physical intuitions of what it feels like to program. These are the <a href="https://en.wikipedia.org/wiki/Conceptual_metaphor">metaphors we live by</a>.</p>
<p>But this additive perspective, pervasive though it may be, is not the only way of looking at programming. Personally, I often find it valuable to think of programming as a <em>subtractive</em> activity. Less like painting a picture, more like sculpting stone: you start with a lump of material and gradually carve pieces away, eventually producing something strictly smaller than the lump you started with.</p>
<p>And the material being sculpted? <em>Possibility space</em>: the range of things that your program might possibly do. To develop a program is to take a general-purpose, Turing-complete system – a programming language, a computer – and gradually exclude most of its capabilities in order to highlight a few specific ones that your users might find interesting.</p>
<p>Viewed through this lens, programming isn’t about adding capabilities to a program until it does what you want. In fact, almost the exact opposite is true: programming is about gradually whittling away at the entire vast possibility space of general-purpose computation (roughly speaking, “anything a computer can do”) until your program doesn’t do anything you <em>don’t</em> want.</p>
<p>Why exclude so many possibilities? Because the human brain is limited. You can only hold a certain amount of information in your head at once, and the possibility space of general-purpose computation is absolutely huge – way too huge to fit completely in <em>anyone’s</em> brain. Unless you find ways to narrow down this possibility space, you’ll forever be adrift in a sea of complexity.</p>
<p>This realization played a critical role in helping me understand the value of functional programming. When functional programming advocates say they’re trying to make it easier to “reason about” code, they’re really talking about reducing the size of the possibility space that you have to fit in your head when attempting to understand said code. Both “fancy” type systems and immutable data structures are tools for <em>excluding possibilities</em> – such as “the possibility that this function will alter the arguments I pass in”, or “the possibility that this code will mess with the filesystem when I run it” – in order to cut off as much of the possibility space as possible.</p>
<p>This is also one of the conceptual underpinnings of the <a href="http://langsec.org/">LangSec</a> movement, whose proponents suggest (among other things) that it’s easier to develop secure software when you use the least computationally powerful techniques that will suffice for processing input. In other words: the smaller the initial possibility space from which your program is hewn, the less likely you are to overlook a potentially dangerous corner of this space.</p>
<p>But the most profound implication of the subtractive viewpoint, in my opinion, is that programmers need better tools for <em>exploring possibility spaces</em>. <a href="http://blog.jessitron.com/2013/04/property-based-testing-what-is-it.html">Generative testing</a>, which can be used to shed a bit of light on the darker corners of a program’s possibility space, represents a step in the right direction, but I’m even more intrigued by things like Michael Cook’s <a href="http://www.gamesbyangelina.org/2016/02/introducing-danesh-part-1/">Danesh</a>: a tool for visually analyzing the “expressive range” of a procedural generator, which begins to hint at how profoundly different our development and debugging workflows might look if we were able to visualize possibility spaces directly.</p>
<p>I’ll almost certainly have more to say about this subject in the future. For now, though, I’ll wrap this post up by reaffirming the value of stating the obvious. As Jason Brennan writes:</p>
<blockquote>
<p>I’m not writing groundbreaking stuff, but I am trying to make some connections I (and you) might not have otherwise made. It might sound obvious when you read it, but my hope is by writing it down, by giving it a <em>name</em>, whatever obvious thing I write about becomes just a little bit more tangible.</p>
<footer>Jason Brennan, <a href="http://nearthespeedoflight.com/article/2016_03_18_stating_the_obvious">“Stating the Obvious”</a></footer>
</blockquote>
<p>I’d been toying with a vague notion that programming could be thought of in terms of sculpture for months, but it was only when I ran into <a href="http://galaxykate0.tumblr.com/post/139774965871/so-you-want-to-build-a-generator">this post’s</a> offhand parenthetical definition of the term “possibility space” that everything finally clicked. Hopefully, my writeup of this obvious-in-hindsight realization will be just enough to help someone else arrive at an “obvious” realization of their own.</p>
Failure margins and feedback loops2016-02-05T00:00:00+00:00http://mkremins.github.io/blog/failure-margins-feedback-loops<p>Learning necessarily involves failure. This is because learning, by definition, takes place at the very edge of what you’re able to handle: within the <a href="https://en.wikipedia.org/wiki/Zone_of_proximal_development">zone of proximal development</a> that separates what you’re already comfortable doing from that which you can’t yet do at all.</p>
<p>And failure is discouraging. Fail hard enough and you’re liable to start doubting even your own <em>ability</em> to learn, let alone your progress towards learning any particular subject. Overcoming the urge to quit in the face of failure is widely recognized as a difficult but critical step in the process of learning.</p>
<p>Despite this, people routinely and voluntarily immserse themselves in environments that require them to learn – and, consequently, to fail. I’m talking, of course, about video games.</p>
<p>How do games keep players coming back for more, even in the face of near-constant failure? And can the techniques used by games to keep people engaged in learning be applied to other learning activities, such as learning to program?</p>
<h3 id="partial-failure-margins">Partial failure margins</h3>
<p>As far as I can tell, the idea of the <em>partial failure margin</em> can be traced back to a 2006 GDC talk on <a href="http://www.roningamedeveloper.com/Materials.html">“Level Building for Stealth Gameplay”</a> by game designer Randy Smith. (I can’t find any recordings or transcripts of the talk itself, so I’ll instead be referring to <a href="http://www.blog.radiator.debacle.us/2011/07/dark-past-part-4-useful-post-or-randy.html">Robert Yang’s concise summary</a> of the relevant parts.)</p>
<p>At the core of this idea is the observation that (most) stealth games tend to be way less tolerant of the player’s screw-ups than (most) action games. As Yang puts it:</p>
<blockquote>
<p>In the average action game, you might have failure (i.e. 0 health), all player states in-between (1-99 health), and success (100 health). Most of the game time takes place within that in-between “limbo” portion of the spectrum.</p>
<p>The average stealth game has failure (you’ve been discovered), the limbo in-between (you’re being hunted), and success (you’re undetected). In contrast to the action game, most of the game time takes place in that “success” part when you’re in a safe hiding spot, scouting out places.</p>
<footer>Robert Yang, <a href="http://www.blog.radiator.debacle.us/2011/07/dark-past-part-4-useful-post-or-randy.html">“Dark Past (part 4): The Useful Post (?)”</a></footer>
</blockquote>
<p>To illustrate this point, Smith throws in some diagrams:</p>
<p><img src="http://1.bp.blogspot.com/-7WuuuemiCtU/ThOS5lU4lsI/AAAAAAAAAis/UjUbKFp16Os/s1600/pask4_smith1.jpg" alt="Partial failure margin for action games" /></p>
<p><img src="http://3.bp.blogspot.com/-JK9TjG-Me4Y/ThOS-21dinI/AAAAAAAAAiw/O9b8McGTNrc/s1600/pask4_smith2.jpg" alt="Partial failure margin for stealth games" /></p>
<p>Because of the comparatively narrow <em>partial failure margin</em>, an average player’s run through an average stealth sequence is much more likely than a comparable run through an average action sequence to end in <em>total failure</em>: capture or death, followed by a game-over screen. Total failure is both frustrating and flow-breaking, and it’s something we (as game designers) usually want players to be able to avoid.</p>
<p>To understand why this is the case, we’ll turn to <a href="http://www.pentadact.com/2014-12-29-what-works-and-why-invisible-inc/">Tom Francis’s take</a> on the concept of the partial failure margin. (Technically, he calls it the <em>failure spectrum</em>, although it’s clearly the same idea underneath.)</p>
<blockquote>
<p>A big failure spectrum is good because a lot of the most emotional moments in a game happen on the cusp of failure. If you were <em>this</em> close to being seen, your escape is exhilarating. But if failure is a ‘game over’ screen, spending a lot of time on the cusp of failure means a lot of ‘game over’ screens. Each one interrupts your immersion and ends your investment in this current run. It pulls you out of the game, and you find yourself in a menu, then at a checkpoint or a savegame. Mentally acclimatising to how much of your story has been lost forces you to disengage from it, and you have to build up all that immersion again from scratch.</p>
<footer>Tom Francis, <a href="http://www.pentadact.com/2014-12-29-what-works-and-why-invisible-inc/">“What Works And Why: Invisible Inc”</a></footer>
</blockquote>
<p>In other words: total failure comes with a <em>cost</em> in terms of time and effort wasted, immersion shattered, and story progress lost. This cost is the number-one reason that players tend to become frustrated and discouraged when they experience total failure.</p>
<p>Thus, if you want to keep the player engaged, it’s almost always better to leave them in a <em>partial</em> failure state, with an opportunity to recover from whatever mistake they made and salvage their current run, than to cut them off completely. You still need the <em>possibility</em> of total failure to motivate players to avoid making mistakes in the first place, but ideally, they’ll rarely – if ever – mess up hard enough to actually wind up in the total failure state.</p>
<p>Hence Smith’s argument: that the goal of stealth level design is to expand the narrow-by-default margin of partial failure as much as possible. A well-designed level encourages players to take risks that may get them detected, while also giving them plenty of chances to recover from their mistakes. Most of the player’s time should be spent in various states of partial failure, the rhythm of gameplay punctuated by narrow escapes and near brushes with disaster.</p>
<p>Many modern stealth games seem to have taken this advice to heart. <a href="http://www.pentadact.com/2015-09-13-things-about-metal-gear-solid-v-spoiler-free/">Another post by Tom Francis</a> enumerates nearly a dozen different ways that Metal Gear Solid V permits players to recover from the partial failure of being spotted by a guard. Until every last one of these methods has been tried and exhausted, the player still has a shot at salvaging their run.</p>
<h3 id="game-over">Game over</h3>
<p>Let’s change gears a bit, now, and talk about programming – and, more specifically, about the idea of <em>programming as theory building</em>. This idea was first put forth by Peter Naur in his <a href="http://pages.cs.wisc.edu/~remzi/Naur.pdf">essay of the same title</a>, in which he argues that</p>
<blockquote>
<p>[…] what has to be built by the programmer is a theory of how certain affairs of the world will be handled by, or supported by, a computer program.</p>
<footer>Peter Naur, <a href="http://pages.cs.wisc.edu/~remzi/Naur.pdf">“Programming as Theory Building”</a></footer>
</blockquote>
<p>Essentially, the programmer’s aim is to develop a <em>theory</em> of how some high-level goal can be accomplished through the application of a specific procedure or algorithm, and of how that algorithm can then be expressed as machine-executable code.</p>
<p>One implication of this view, Naur notes, is that</p>
<blockquote>
<p>[The] problem of education of new programmers […] is quite similar to that of the educational problem of other activities where the knowledge of how to do certain things dominates over the knowledge that certain things are the case, such as writing and playing a musical instrument. The most important educational activity is the student’s doing the relevant things under suitable supervision and guidance.</p>
<footer>Peter Naur, <a href="http://pages.cs.wisc.edu/~remzi/Naur.pdf">“Programming as Theory Building”</a></footer>
</blockquote>
<p>Naur is suggesting, here, that programming – at least from an educational perspective – belongs to a category of activities in which <a href="https://en.wikipedia.org/wiki/Procedural_knowledge">procedural knowledge</a> “dominates over” <a href="https://en.wikipedia.org/wiki/Descriptive_knowledge">declarative</a>. Certainly the activity of playing games would also seem to belong to this category!</p>
<p>And, indeed, the process of learning how to complete an unfamiliar level in a video game is remarkably similar to the process of learning how to write an unfamiliar program. Just as the programmer gradually develops a theory of how to translate some high-level idea into code, the player gradually develops a theory of how to translate <em>beating the level</em> into a particular series of button presses.</p>
<p>Perhaps this is why hitting a compilation or parse error when you go to run your program feels so much like hitting a game-over screen in a video game. An unexpected compilation failure, much like a game-over screen, represents a total failure state: a sign that your current theory of how to write the desired program is fundamentally incorrect. To resolve the error, you’ll have to go back in and start rebuilding your theory, just as if you were replaying an unexpectedly difficult level to try and put right what went wrong on the previous run.</p>
<h3 id="mitigating-discouragement">Mitigating discouragement</h3>
<p>Total failure is discouraging in any context, but programming tools – unlike games – rarely seem to be designed with this in mind. The core activity loop of programming, especially for beginners, typically looks something like the following:</p>
<ol>
<li>Develop a theory of how to write a particular program.</li>
<li>Type some code into a text file, one character at a time.</li>
<li>Attempt to compile, and maybe run, the program.</li>
<li>Repeat until either successful (yay!) or too frustrated to continue.</li>
</ol>
<p>Feedback on the program’s validity comes primarily from the compiler, which is invoked only occasionally and often takes several seconds to run. What’s more, a single misplaced character of input is often enough to halt the compiler in its tracks, creating an absurdly narrow partial failure margin: reminiscent of those stealth games in which one wrong move is sufficient to get you detected and booted back to the start of the level.</p>
<p><em>But</em> there do exist programming tools that break this mold, and these tools tend to handle failure very differently than their more traditional relatives. This is especially true of those programming tools that were specifically designed for the purpose of education.</p>
<p>Let’s take a closer look at some of the recurring patterns in how games and programming tools alike handle failure. Which approaches are effective at mitigating discouragement, and why?</p>
<h4 id="fail-tiny-fail-often">Fail tiny, fail often</h4>
<p>Users of the educational programming environment <a href="https://scratch.mit.edu/">Scratch</a> do not construct programs by typing code into text files. Instead, they construct programs by snapping together discrete “blocks” of functionality in a drag-and-drop workbench-style UI.</p>
<p>Each block has a “shape” that describes the roles it might play in the program. Only blocks with compatible shapes may be snapped together. By preventing users from snapping together mismatched blocks, Scratch effectively prohibits the construction of structurally invalid programs. In the process, it also does away with the need for traditional compile-time syntax and type errors: error messages that appear only when the user attempts to run the program.</p>
<p>Thus, Scratch eliminates an entire category of infrequently-occurring <em>total</em> failures (compile-time error messages caused by structurally invalid code) in exchange for an increased frequency of <em>partial</em> failures (failed attempts to snap together two mismatched blocks). Whereas a single total failure might seem to invalidate minutes or even hours of work, the perceived cost of each partial failure rarely amounts to more than a few seconds of “wasted” time.</p>
<p>This is a straightforward case of widening the partial failure margin. What would ordinarily be a single total failure is instead diffused into dozens, even hundreds, of barely-noticeable partial failures, and the discouragement of failure is no longer delivered all at once.</p>
<h4 id="checkpoints-and-restarts">Checkpoints and restarts</h4>
<p>Some games – especially one-hit-kill action games like <a href="http://www.hotlinemiami.com/">Hotline Miami</a>, in which taking <em>any</em> amount of damage results in immediate death – manage to succeed even in spite of their razor-thin partial failure margins. What explains this apparent contradiction?</p>
<p>Hotline Miami in particular contains examples of several design patterns that are often adopted to maintain player motivation in scenarios where total failure is always only one wrong move away. Most notably, it employs both <em>frequent checkpointing</em> and <em>low-friction restarts</em> to keep the cost of total failure relatively low.</p>
<p>A game that employs <em>frequent checkpointing</em> automatically saves the player’s progress at each checkpoint they encounter. Death merely results in the loss of progress made since the previous checkpoint, and checkpoints are scattered liberally throughout the game world. Thus, it’s rare for a single failure to result in the loss of more than a few minutes of progress at once.</p>
<p><em>Low-friction restarts</em>, meanwhile, make it quick and easy for the player to hop back into the game after death. Rather than playing a lengthy death animation for the player character, transitioning to a separate “game over” screen, or bringing up a menu that gives the player a choice of whether to restart or quit, Hotline Miami merely pops up a text overlay reading <a href="https://www.google.com/search?q="press+r+to+restart"">“PRESS R TO RESTART!”</a> As soon as the player presses R, they’re back in the game at the previous checkpoint.</p>
<p>If you adapt these patterns to programming, you get something that looks very much like a <a href="https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop">REPL</a>. Successfully defining a new function in the REPL establishes a checkpoint: because the REPL (ideally) doesn’t crash on failure, you don’t have to worry about restarting it and re-entering all your previous definitions if the next one <em>does</em> happen to fail. Meanwhile, the REPL encourages you to keep each individual definition small and relatively self-contained, leading you to establish checkpoints both early and often.</p>
<h4 id="killcams-and-error-messages">Killcams and error messages</h4>
<p>Low-friction restarts work well when some other factor (such as frequent checkpointing) is suppressing the cost of failure, but what if failure is necessarily costly? In the competitive multiplayer game <a href="http://www.teamfortress.com/">Team Fortress 2</a>, for instance, a player who dies must then spend several seconds waiting before they are allowed to respawn. Some third-party TF2 servers, in accordance with the principle of low-friction restarts, change this behavior and allow players to respawn immediately; this invariably throws off the competitive balance, making players feel that the game is unfair.</p>
<p>In lieu of low-friction restarts, then, TF2 takes a different approach to mitigating player discouragement during the mandatory waiting period between death and respawning. When you die in TF2, the game first shows you a <em>killcam</em> – a static shot of the enemy responsible for your death – to give you a better idea of how exactly you died. Then, for the rest of the waiting period, it allows you to observe what your still-living allies are currently doing, so that you’ll have some sense of what to do next when you finally respawn.</p>
<p>This is much more helpful than a typical game-over screen. Rather than merely invalidating your theory of how to beat the other team, TF2 gives you specific, contextualized feedback on how your theory was flawed (“you were killed by a sniper up on that rooftop”) and how it might be adjusted (“your teammates in the tunnel are still alive, maybe try going through there instead”).</p>
<p>The <a href="http://elm-lang.org/">Elm</a> programming language, with its emphasis on <a href="http://elm-lang.org/blog/compiler-errors-for-humans">human-friendly compiler errors</a>, adopts a similar approach. Every Elm compiler error includes both the exact code that caused the error, formatted exactly as the user wrote it, and one or more suggestions concerning how the error might be fixed. Thus, even though total failure is still costly, the discouragement of encountering a total failure state is mitigated by the suggestion of a viable way to proceed.</p>
<h3 id="closing-the-loop">Closing the loop</h3>
<p>What do all of these patterns have in common? Most obvious, it seems to me, is that all of them essentially <em>tighten the feedback loop</em> between failure and renewed play. So far as I know, this is an unambiguously good thing: a sufficiently tight feedback loop enables people to <a href="http://mkremins.github.io/blog/why-affording-play/">learn by trying and reacting</a> in a way that feels very natural for skills, like programming, that rely heavily on procedural knowledge.</p>
<p>Overall, then, if you want to design more readily learnable tools (or, for that matter, more readily learnable games), consider trying for tighter feedback loops and wider margins of partial failure. Your [users/players/students] will thank you!</p>
Locked doors, headaches, and intellectual need2015-10-27T00:00:00+00:00http://mkremins.github.io/blog/doors-headaches-intellectual-need<p>You know those things that, once you learn about them for the first time, you start seeing them absolutely <em>everywhere</em>? Recently, that’s been my experience with <em>problem-solution ordering issues</em>. They keep cropping up: not just in the context of game design, where I first encountered them, but also in such apparently unrelated fields as math education and functional programming.</p>
<p>Despite this, however, I’ve never seen problem-solution ordering issues explicitly discussed in any of the online communities I participate in. So I’m going to try to define what they are; trace them through the different fields in which I’ve encountered them; and hopefully, in the process, demonstrate how a working awareness of these issues can help you avoid certain common pitfalls in teaching and communicating new ideas.</p>
<h3 id="game-design">Game design</h3>
<p>I was first introduced to the idea of problem-solution ordering issues by <a href="https://twitter.com/rich_lem">Richard Lemarchand</a>, one of my game design professors. The idea stuck with me, mostly because it provided a satisfying explanation for a certain confusing pattern of player behavior that I’d witnessed many times in the past.</p>
<p>Here’s the pattern. A new player jumps into your game and starts bouncing around your carefully crafted tutorial level. The level funnels them to the key, which they collect, and then on to the corresponding locked door, which they successfully open. Then, somewhere down the road, they encounter a second locked door… and are completely stumped. They’ve solved this problem once before – why are they having such a hard time solving it again?</p>
<p>What we have here is a problem-solution ordering issue. Because the player got the key in the first level <em>before</em> encountering the locked door, they never really formed an understanding of the causal link between “get key” and “open door”. They got the key, and then some other stuff happened, and then they reached the door, and were able to open it; but “acquiring the key” and “opening the door” were stored as two separate, disconnected events in the player’s mind.</p>
<p>If the player had encountered the locked door <em>first</em>, tried to open it, been unable to, and <em>then</em> found the key and used it to open the door, the causal link would be unmistakable. You use the key to open the locked door, because you can’t open the locked door without the key.</p>
<p>This problem becomes a lot more obvious when you don’t call the key a key, or when the door doesn’t look like a locked door. The “key/door” metaphor is widely understood and frequently used in video games, so many players will assume that you use a key to open a locked door even if your own game doesn’t do a great job of teaching them this fact. But if the “key” is really a thermal detonator and the “door” is really a power generator, a <em>lot</em> of players are going to wind up trying to destroy the second generator they encounter by whacking it ineffectually with a sword.</p>
<h3 id="math-education">Math education</h3>
<p>I’ve <a href="/blog/why-affording-play">drawn parallels</a> between game design and education before, but it still took me a while to realize that problem-solution ordering issues crop up just as often in the classroom as they do in games.</p>
<p>Remember how, in high school math class, a lot of the work you were doing felt <em>really, really pointless</em>? (Even if you never felt that way, I can all but guarantee that at least a few of your former classmates did.) We often think of this feeling of pointlessness as an inevitable byproduct of math education. But what if, instead, it’s partly a consequence of problem-solution ordering issues in the way we currently teach math?</p>
<p>Consider Dan Meyer’s question for math educators: <a href="http://blog.mrmeyer.com/2015/if-math-is-the-aspirin-then-how-do-you-create-the-headache/">if math is the aspirin, then how do you create the headache?</a></p>
<blockquote>
<p>Think of yourself as someone who sells aspirin. And realize that the best customer for your aspirin is someone who is in pain. Not a lot of pain. Not a migraine. Just a little.</p>
<p>One of the worst things you can do is force people who don’t feel pain to take your aspirin. They may oblige you if you have some particular kind of authority in their lives but that aspirin will feel pointless. It’ll undermine their respect for medicine in general.</p>
<p>Math shouldn’t feel pointless. Math isn’t pointless. It may not have a point in job [y] or [z] but math has a point in math. We invented new math to resolve the limitations of old math. My challenge to all of us here is, before you offer students the new, more powerful math, put them in a place to experience the limitations of the older, less powerful math.</p>
<footer>Dan Meyer, <a href="http://blog.mrmeyer.com/2015/if-math-is-the-aspirin-then-how-do-you-create-the-headache/">“If Math Is The Aspirin, Then How Do You Create The Headache?”</a></footer>
</blockquote>
<p>In other words: if you introduce the solution (in this case, a new kind of math) before introducing the kind of problems that it’s meant to solve, the solution is likely to come across as pointless and arbitrary. But if you first let students try to tackle these problems with the math they already understand, they’re likely to come away with a kind of intellectual “headache” – and, therefore, to better understand the purpose of the “aspirin” you’re trying to sell.</p>
<p>Which brings us to…</p>
<h3 id="functional-programming">Functional programming</h3>
<p>In functional programming, there’s a concept called the <em>monad</em>. Monads are notoriously abstract, and newcomers to functional programming often get tripped up trying to understand them.</p>
<p>The thing is, monads aren’t actually all that complicated. In fact, most of the experienced functional programmers I’ve met consider them downright simple. It’s just that newcomers often have a really hard time trying to figure out what exactly monads even <em>are</em>.</p>
<p>A lot of intermediate-to-advanced functional programmers have taken it upon themselves to write <em>monad tutorials</em>: blog posts and other explanations intended to demystify monads once and for all. But for the most part, these tutorials never seem to work. Experts who read them go on thinking monads are simple, and beginners who read them remain confused. Why is that?</p>
<p>I think a problem-solution ordering issue is to blame.</p>
<p>Monads are a solution to a specific problem: the problem of repetitive code. If you write enough code in a functional programming language, you start to notice that you’re writing a lot of suspiciously similar code to solve a bunch of superficially different problems. Wouldn’t it be nice if you could just write this code once and then reuse it, instead of rewriting it slightly differently every time? I’m omitting a lot of detail here, but this is effectively what monads allow you to do.</p>
<p>By definition, the chief difference between experienced and inexperienced functional programmers is that experienced functional programmers have written tons of code in functional languages. They’ve all encountered repetition and sought solutions to it. In other words, they’ve felt the headache for which monads are the aspirin.</p>
<p>Beginners, on the other hand, haven’t written nearly as much functional code. They might not have noticed any recurring patterns yet; if they have, the repetition doesn’t yet bother them. The headache just isn’t there.</p>
<p>This is why it’s so hard to explain monads to beginners, especially with canned tutorials that try to explain what monads <em>are</em> without spending too much time on what they’re <em>for</em>. Monads are the solution to a problem that beginners haven’t yet experienced for themselves; and, as a result, they feel pointless, like something out of high-school math.</p>
<p>Remember: <em>One of the worst things you can do is force people who don’t feel pain to take your aspirin.</em> Likewise, I suspect that trying to “teach monads” to novice functional programmers who don’t yet understand the need for monads is likely to do <a href="https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/">more harm than good</a>, creating further unnecessary confusion and perpetuating the myth that monads are intrinsically hard to understand.</p>
<h3 id="final-thoughts">Final thoughts</h3>
<p>Strong problem-solution ordering is one of the defining hallmarks of the effective <a href="http://explorableexplanations.com/">explorable explanation</a>. Through interactivity, a well-designed explorable immediately invites the reader to play with the initial arrangement of elements, and thereby to discover potential problems on their own. First-hand experience of a problem induces <em>intellectual need</em> (or, if you prefer, a “headache”) and sets the stage for the introduction of the solution later on.</p>
<p>Speaking of intellectual need: if you’re interested in learning more about the educational theory underpinning this post, I strongly suggest checking out this <a href="http://math.ucsd.edu/~jrabin/publications/ProblemFreeActivity.pdf">remarkably readable paper</a> on intellectual need in the math classroom, which offers both a concrete definition of “intellectual need” and a broad overview of the idea of <em>necessity</em> in the context of education.</p>
<p>And finally, the ultimate takeaway: if you want to craft memorable, relevant-seeming lessons, introduce your locked doors before your keys; your headaches before your aspirin; and your specific motivating problems before your wordy metaphorical generalizations.</p>
<p>(OK, maybe on that last one I should take a bit of my own advice.)</p>
Creative tools for non-creators2015-09-15T00:00:00+00:00http://mkremins.github.io/blog/creative-tools-non-creators<p>I keep coming back to the idea of tools that unlock creativity in people who don’t ordinarily think of themselves as creative. Yesterday, some of my scattered thoughts on the subject spontaneously crystallized into something resembling a coherent argument: successful tools of this kind tend to differ from successful “real” or “professional” creative tools in a number of fairly consistent ways.</p>
<p>How, exactly, are successful creative tools for non-creators designed? Here’s one approach that seems to work fairly reliably. Take an existing “professional” creative tool; aggressively simplify its user interface; remove features left and right; rip out pieces of other, completely unrelated tools and weld them on. Then put the resulting monstrosity in front of an audience of total beginners: people who’ve never even <em>heard</em> of the original tools you’re ripping off.</p>
<p>If you can, avoid marketing what you’ve made as a creative tool; that’s likely to attract the wrong sort of people, the ones who <em>have</em> heard of the real tools. These people will thoroughly review every nook and cranny of your creation, draw up a detailed side-by-side comparison between it and the “real thing”, and then conclude, as loudly as possible, that no one should waste their time on the kiddie toy you’ve slapped together. Instead, they’ll say, all aspiring creators should invest in learning the One True Tool – the one that <em>everyone</em> uses out here in the Real World.</p>
<p>These people <em>don’t know what they’re talking about</em>. They can’t see the ways in which the One True Tool, and the community of vocal proponents that surrounds it, are at best indifferent and at worst outright hostile to new users. They don’t realize that you’re aiming to recruit people who don’t think of themselves as creators, who don’t even see themselves as <em>creative</em> yet, because everything around them is constantly screaming that Making Stuff Is For Other People Who Are Fundamentally Unlike You.</p>
<p>So it’s better to disguise your aims, to hide in plain sight. Don’t call what you’ve built a tool for 3D Modeling or Game Development or Musical Composition; these are things that your latent users do not yet believe themselves to be capable of doing. Wrap your tool in a game, make it fun to play with, and do whatever you can to shield players from the kind of people who enjoy holding others to strict standards of Excellence. Present your creation as an Excellence-Free Zone, a safe space for <a href="http://www.glorioustrainwrecks.com/">glorious trainwrecks</a>. Encourage people to make messes, and then surprise them with the realization that their messes consistently turn out ever so slightly better than they expect.</p>
<p>Impose constraints. Perhaps require the user’s creations to <a href="https://kerbalspaceprogram.com/en/">play some functional role</a> within a complex simulated world; perhaps place a <a href="https://twitter.com">hard upper bound</a> on creative complexity. Do so not only because constraints breed creativity, but also because externally imposed limitations give people a scapegoat to blame when their creations don’t live up to <a href="http://www.brainpickings.org/2014/01/29/ira-glass-success-daniel-sax/">their own high expectations</a> and a clear stopping point that protects against the characteristic failure mode of perfectionism: eternal diminishing-returns polishing of a single, perpetually unfinished piece. Perfectionists don’t know how to say “good enough”, but they understand what it means when the voice of authority says “done”. Pencils down!</p>
<p>Suppress any remaining qualms you may have about the quality of the things that people will use your tool to make. If all goes well, your users will unleash a torrent of crap upon the world. This torrent of crap is a sign that you have succeeded beyond your wildest dreams. Think of it, perhaps, as a trail of exhaust, tracing the path taken by the rocket of creative empowerment in the wake of its launch.</p>
<p>Strive, above all, to recapture the spirit of the <a href="http://tilde.club/">early</a> <a href="https://neocities.org/">internet</a>. Of <a href="https://www.youtube.com/watch?v=rdhIPj4BdKM">Mario Paint</a>. Of <a href="http://ludumdare.com/compo/ludum-dare-27/?action=preview&uid=4987">GREAT ARTIST</a>. Of Minecraft. Of <a href="http://www.gamasutra.com/php-bin/news_index.php?story=19122">Spore</a>.</p>
<p><em><strong>Addendum:</strong> No less than a couple hours after putting the finishing touches on this post, I stumbled upon a <a href="http://boingboing.net/2015/08/24/a-game-making-app-for-everyone.html">recent article</a> by Anna Anthropy that touches on a lot of these same themes. If you found any part of this post even remotely interesting, you should go read that article as well.</em></p>
Why “Affording Play”?2015-08-03T00:00:00+00:00http://mkremins.github.io/blog/why-affording-play<p>Why is this blog called “Affording Play”? What, for that matter, does the phrase “affording play” even <em>mean</em>?</p>
<p>This isn’t exactly a “frequently asked question”, but it <em>is</em> a question I’ve been asked a few times by a few different people, and a question I wanted to get around to answering eventually one way or the other. Now seems to be as good a time as any, so here we go.</p>
<p>The “affording” part, for starters, refers to the concept of <em>affordances</em>. In user interface design, an affordance is a feature of an interface that suggests or facilitates (i.e. <em>affords</em>) a certain kind of interaction. At the risk of oversimplification, a door handle affords pulling; a door plate affords pushing; a light switch affords flipping; and a knife affords grasping (of the handle part) and cutting (with the blade part).</p>
<p>A thing that affords play, then, is a thing that suggests playful uses; a thing that naturally guides its user towards a playful state of mind.</p>
<p>The “play” part is a bit more complicated. As a game design student with a particular interest in usability, I spend a lot of time pursuing ways to make interactions feel playful. At a surface level, it’s tempting to write off the phrase “affording play” as a literal description of the work I do, which often involves the application of user interface design techniques to games.</p>
<p>But it’s when you interpret this phrase more generally that a deeper level of meaning begins to emerge. If you’re anything like me, it might initially strike you as a little odd that the longest and most widely read post on a game design student’s blog is a <a href="http://mkremins.github.io/blog/unix-not-acceptable-unix/">criticism of Unix</a> that doesn’t even mention games. But if you take “affording play” as my goal for <em>complex human-authored systems in general</em> and not just games, this observation starts to make a bit more sense.</p>
<p>What does it mean to afford play outside of games? Let’s take a look at two of my all-time favorite user interface idioms: the <em>undo</em> command, and <em>real-time suggestions</em> for things like the Google search bar.</p>
<p>The very existence of a reliable undo command is an open invitation to engage in playful experimentation. Wondering what that big red button does? Without undo, you’ve got to be cautious: pressing the button might well mess something up. But if you have undo, you can figure out what the button does by pressing it and seeing what happens. Even if it does mess something up, you have the tools you need to restore the previous state.</p>
<blockquote class="twitter-tweet" data-conversation="none" lang="en"><p lang="en" dir="ltr">Remember, Undo is the king of interface idioms. It makes users more willing to explore and experiment.</p>— Jonathan Korman (@miniver) <a href="https://twitter.com/miniver/status/610868340442157056">June 16, 2015</a></blockquote>
<script async="" src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
<p>Real-time suggestions, meanwhile, afford play by tightening the feedback loop between action and reaction. Trying to find the source of a quote, but unsure of the quote’s exact wording? Without real-time suggestions, you’re forced to adopt a rigid multi-step process: formulate a query in your head; submit it; evaluate the results; and decide whether you need to repeat the process with a revised query. But if real-time suggestions are available, you can improve the query on the fly by <em>reacting to the suggestions</em> that come up as you type, enabling you to play around with the search and obtain better results with less cognitive effort.</p>
<p>To quote directly from the “Create by Reacting” section of Bret Victor’s essay, <a href="http://worrydream.com/LearnableProgramming/">Learnable Programming</a>:</p>
<blockquote>
<p>I was recently watching an artist friend begin a painting, and I asked him what a particular shape on the canvas was going to be. He said that he wasn’t sure yet; he was just “pushing paint around on the canvas”, reacting to and getting inspired by the forms that emerged. Likewise, most musicians don’t compose entire melodies in their head and then write them down; instead, they noodle around on a instrument for a while, playing with patterns and reacting to what they hear, adjusting and sculpting.</p>
<p>An essential aspect of a painter’s canvas and a musical instrument is the immediacy with which the artist gets <em>something there</em> to react to. A canvas or sketchbook serves as an “external imagination”, where an artist can grow an idea from birth to maturity by continuously <em>reacting to what’s in front of him</em>.</p>
<footer>Bret Victor, <a href="http://worrydream.com/LearnableProgramming/">“Learnable Programming”</a></footer>
</blockquote>
<p>In other words: humans become proficient at manipulating complex systems in part through reactive experimentation and play.</p>
<p>Consider what it’s like to play Super Mario Bros. for the first time. Now consider what it’s like to write, say, a shell script for the first time. In both scenarios, your challenge involves learning how to manipulate a wildly complex system in order to achieve a desired outcome. But so far, I’ve yet to meet anyone who had a harder time learning Super Mario Bros. than learning to program. Why is that?</p>
<p>An important part of the answer to this question can be found in Anna Anthropy’s analysis of Super Mario Bros.’s first level. As <a href="http://auntiepixelante.com/?p=465">this analysis</a> reveals, it’s easy to learn SMB because SMB has been meticulously designed to be learnable through play:</p>
<blockquote>
<p>an unfortunate trend in contemporary games is to spell out every detail in a hand-holding “tutorial” session at the outset of a game – unfortunate because it shows both a great deal of contempt for the player’s intuition and a lack of confidence in the designer’s own design. but more than that, it’s a design failure because it tells the player the rules instead of allowing her to learn them.</p>
<p>what if the first level of the game were laid out in such a way that the player could learn the rules simply by playing through it, without needing to be told them outright?</p>
<footer>Anna Anthropy, <a href="http://auntiepixelante.com/?p=465">“level design lesson: to the right, hold on tight”</a></footer>
</blockquote>
<p>Super Mario Bros. doesn’t tell the player how to play. In fact, it never utters a single word. Instead, practically every aspect of its first level is aligned in <em>showing</em> the player how to play the game by giving them something to react to.</p>
<p>This throws the relative difficulty of learning to program into sharp relief. People don’t learn to program by sitting down at a computer and trying things. Instead, they follow tutorials and exercises that <em>tell</em> them how to program. This is a hideously ineffective way of learning how to manipulate a complex system: the equivalent of learning how to play Super Mario Bros. by watching a more skilled player’s fingers and mimicking their button presses without looking at the screen.</p>
<p>It’s certainly possible to learn how to accomplish a specific task <em>within</em> a complex system – how to complete a specific level of Super Mario Bros., say, or how to write a script that prints the number of files in a directory – by rote mimicry. But this kind of “knowledge” is brittle. A slight change to the parameters of the task renders everything you’ve “learned” effectively useless.</p>
<p>To play with a system is to develop a kind of <em>robust</em> knowledge that reinforces your understanding of the system’s underlying logic. The decision-making process that motivates the skilled player’s button presses is the product of hundreds of thousands of cycles of action, consequence, and reaction: the core feedback loop of play. You can’t acquire this kind of deep understanding, which the skilled player experiences as an intuitive “feel” for the game, merely by having the skilled player <em>tell you</em> how the game is played.</p>
<p>Why, then, do people learn to program through tutorials and exercises that tell rather than show? Perhaps because the tools, languages, and environments embraced by modern programming practice are at best indifferent and at worst actively hostile to play. When you first launch Super Mario Bros., you’re greeted by an engaging, reactive first level designed to guide you gently into the world of the game. When you first launch the Unix shell, you’re confronted by an empty, inscrutable command line that will reject, with a tersely worded error message, almost anything you choose to type.</p>
<p>Granted, the shell is probably inherently more complex than Super Mario Bros. The set of SMB levels that players are expected to complete is finite, while the set of shell scripts that someone might reasonably want to write is infinite. But, as SMB demonstrates, a complex system need not confront anyone with its full complexity right off the bat. Subtle cues and hints that build player confidence and ward off confusion are critical if you want to keep players from throwing aside the controller in frustration during the first ten minutes of gameplay.</p>
<p>Complex systems aren’t going anywhere anytime soon. If anything, the ability to understand and manipulate complex systems will only become more important as software continues to eat the world. With this in mind, I think it’s absolutely critical for those of us who design and develop software to take a cue from Super Mario Bros. and adopt <em>affording play</em> as an end goal for the systems we design.</p>
Unix is not an acceptable Unix2015-06-05T00:00:00+00:00http://mkremins.github.io/blog/unix-not-acceptable-unix<p>The Unix command line is full of surprises. For instance: did you know that the OS X version of the <code class="language-plaintext highlighter-rouge">ls</code> tool, most frequently used to get a list of the files in the current working directory, recognizes no fewer than <a href="https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ls.1.html">38 different flags</a>?</p>
<p>I didn’t, so I <a href="https://twitter.com/maxkreminski/status/585843964260941824">tweeted</a> about it. I got a couple of replies, <a href="https://twitter.com/rtraschke/status/585933203183165441">one of which</a> got me wondering: was Unix itself really to blame?</p>
<blockquote class="twitter-tweet" lang="en"><p lang="en" dir="ltr"><a href="https://twitter.com/msimoni">@msimoni</a> <a href="https://twitter.com/maxkreminski">@maxkreminski</a> Unfortunately, the lineage is _not_ Unix -> Linux. It is Unix -> Plan 9. Linux doesn't follow Unix philosophy :-(</p>— Robby Raschke (@rtraschke) <a href="https://twitter.com/rtraschke/status/585933203183165441">April 8, 2015</a></blockquote>
<script async="" src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
<p>As far as I know, neither Linux nor OS X was designed with close adherence to the <a href="http://en.wikipedia.org/wiki/Unix_philosophy">Unix philosophy</a> in mind. It’d be disingenuous of me to base a criticism of “Unix” exclusively on those derivatives of Unix that are still with us today.</p>
<p>What follows, then, is my attempt to show that many of the problems with the command-line interfaces provided by modern descendants of Unix go all the way to the roots of Unix itself. In particular, I’m going to try to explain my skepticism at the idea that the Unix command-line environment could <em>ever</em> have supported an ecosystem of programs that each did one thing well.</p>
<p>But I’m getting a little ahead of myself. Before I start into any of that, let’s take a closer look at <code class="language-plaintext highlighter-rouge">ls</code> and see if we can figure out what exactly it’s doing wrong.</p>
<h3 id="many-things-poorly">Many things poorly</h3>
<p>Different versions of <code class="language-plaintext highlighter-rouge">ls</code> understand different sets of flags, but these flags can in general be classified into a few broad categories. <code class="language-plaintext highlighter-rouge">ls</code> users make use of flags to:</p>
<ul>
<li><strong>Specify the output format</strong>. <code class="language-plaintext highlighter-rouge">-C</code> arranges entries in a neat grid; <code class="language-plaintext highlighter-rouge">-m</code> prints a comma-separated “stream” of entries; <code class="language-plaintext highlighter-rouge">-1</code> prints each entry on its own line; <code class="language-plaintext highlighter-rouge">-q</code> replaces nonprintable characters in file names with question marks.</li>
<li><strong>Display extra information about each file</strong>. <code class="language-plaintext highlighter-rouge">-F</code> adds trailing sigil characters to the names of directories (<code class="language-plaintext highlighter-rouge">/</code>), executables (<code class="language-plaintext highlighter-rouge">*</code>), symlinks (<code class="language-plaintext highlighter-rouge">@</code>), and files of other “special” types; <code class="language-plaintext highlighter-rouge">-s</code> prints the size of each file alongside its name.</li>
<li><strong>Reorder the list of files</strong>. <code class="language-plaintext highlighter-rouge">-r</code> reverses the default order; <code class="language-plaintext highlighter-rouge">-t</code> orders files by how recently they’ve been modified.</li>
<li><strong>Include and exclude certain files</strong>. <code class="language-plaintext highlighter-rouge">-a</code> includes files that are hidden by default; <code class="language-plaintext highlighter-rouge">-R</code> recursively lists files in subdirectories of the working directory.</li>
</ul>
<p>Disregarding the first category for now, there’s something interesting going on with the other three. Functional programmers in particular might find something about them strangely familiar.</p>
<p>That’s right – each of these three categories corresponds roughly to a single generic higher-order function that operates on sequences!</p>
<ul>
<li>Flags that <em>display extra information about each file</em> can be expressed in terms of <code class="language-plaintext highlighter-rouge">map</code>, which applies a given transformation to each item in a sequence independently of the others.</li>
<li>Flags that <em>reorder the list of files</em> can be expressed in terms of <code class="language-plaintext highlighter-rouge">sort</code>, which uses a given comparator to compare items pairwise and reorder them accordingly.</li>
<li>Flags that <em>include and exclude certain files</em> can be expressed in terms of <code class="language-plaintext highlighter-rouge">filter</code>, which tests each item against a given predicate and rejects those that are found unworthy.</li>
</ul>
<p><code class="language-plaintext highlighter-rouge">ls</code> seems bloated because it <em>is</em> bloated. A handful of higher-order functions could subsume the vast majority of the functionality that’s currently baked into <code class="language-plaintext highlighter-rouge">ls</code> itself in the form of flags.</p>
<h3 id="what-went-wrong">What went wrong?</h3>
<p>By no means is it novel to assert that each program should constitute a self-contained unit of functionality. For decades, Unix proponents have been extolling the virtues of pipelines: “programs” created on the fly by gluing small, composable <a href="http://en.wikipedia.org/wiki/Filter_(software)#Unix">filters</a> together end-to-end. How, then, is it possible to explain the evolution of such a conceptually simple tool as <code class="language-plaintext highlighter-rouge">ls</code> towards ever-greater complexity?</p>
<p>The extreme terseness of the Unix command line hints at one possible explanation. When Unix was invented, 80 characters was about as wide as you could expect a screen to go, and using a computer was synonymous with sitting at a terminal and typing out commands. In such an environment, it made sense to trade legibility and composability for the ability to fit more information into as few characters as possible.</p>
<p>During this era, the developers of heavily used utilities were strongly incentivized to build in shortcuts wherever they could. <code class="language-plaintext highlighter-rouge">ls</code> is called <code class="language-plaintext highlighter-rouge">ls</code> for the very same reason that its flags are cryptic single-character runes rather than meaningful words or, god forbid, entire phrases: it was developed by and for a small group of highly specialized experts in an environment where every keystroke, every character displayed on the screen, came at a real and meaningful cost.</p>
<p>Likewise, the flags themselves are shortcuts for common real-world use cases. Why waste time adding a filtering step to the pipeline to drop the hidden files when 90% of the time no one wants to see the hidden files anyway? Why display all the available information about each file when 90% of the time the user only cares about filenames?</p>
<p>This mindset – that keypresses are expensive, and that there should be a shortcut for everything – is responsible for many of the problems with <code class="language-plaintext highlighter-rouge">ls</code>, and with the Unix command-line environment as a whole.</p>
<h3 id="the-universal-interface">The “universal interface”</h3>
<p>But <a href="https://www.google.com/search?q=%22why%20not%20just%22">why not just</a> write a simpler alternative to <code class="language-plaintext highlighter-rouge">ls</code> – a function that takes an optional directory, or the working directory by default, and returns a list of the files inside, disregarding flags entirely? Unix is, after all, nothing if not hackable: if you don’t like <code class="language-plaintext highlighter-rouge">ls</code>, you’re free to replace it.</p>
<p>I’ll answer that question with a hypothetical. Imagine, if you will, a programming language in which every function takes exactly one argument (a string) and returns exactly one result (another string).</p>
<p>Oh, look at that – it exists, and it’s called the shell.</p>
<p>Unix permits programs to communicate with one another, and with the user, exclusively through character streams. You can’t write a function that returns a list of files because the shell doesn’t know what a “list” is, doesn’t know what “files” are, and couldn’t tell you the difference between a “function” and a “program” if its life depended on it. Programs don’t “take arguments” and “return values”, they read characters from <code class="language-plaintext highlighter-rouge">stdin</code> and print characters to <code class="language-plaintext highlighter-rouge">stdout</code>!</p>
<blockquote>
<p>Write programs to handle text streams, because that is a universal interface.</p>
<footer>Doug McIlroy, <a href="http://harmful.cat-v.org/cat-v/unix_prog_design.pdf">“Program Design in the UNIX Environment”</a></footer>
</blockquote>
<p>The original designers of Unix viewed the “simplicity” of text streams as an advantage. Consequently, they declined to impose any structure on the data that was to pass between programs. This decision, intended to banish inessential complexity, instead managed only to push essential complexity further downstream.</p>
<p>Remember that first category of <code class="language-plaintext highlighter-rouge">ls</code> flags, the flags we couldn’t explain away as shortcuts for generic sequence transformations? Turns out they’re just shortcuts for informally encoding notional <em>lists of files</em> as strings that certain other programs (or, in some cases, human beings) know how to parse.</p>
<p>The system fails to provide the abstractions its users need. Users respond by <a href="http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule">reinventing them</a>, poorly and inconsistently and in all the wrong places. It’s a distressingly common pattern.</p>
<h3 id="not-an-acceptable-unix">Not an acceptable Unix</h3>
<p>Awareness of the history of computing, and of the constraints under which our current mental models were developed, bestows a kind of superpower: the ability to notice when changing circumstances have rendered once-necessary tradeoffs nonsensical or obsolete.</p>
<p>Many of the usability issues raised by Don Norman in his 1981 <a href="http://www.ceri.memphis.edu/people/smalley/ESCI7205F2009/misc_files/The_truth_about_Unix_cleaned.pdf">criticism of Unix</a> have gone largely unaddressed for three and a half decades. Granted, we’ve developed graphical user interfaces that keep “ordinary users” away from the command line, but we still expect “serious developers” to drop down into a demonstrably inhumane environment to get anything meaningful done.</p>
<p>Rather than re-evaluating the Unix command line with an eye towards improving its usability under the greatly relaxed technological constraints of modern hardware, we’ve written <a href="http://www.secretgeometry.com/apps/cathode/">terminal emulators</a> that faithfully reproduce the constraints of the mid-1970s. We demand <a href="http://unix.stackexchange.com/questions/145522/what-does-it-mean-to-be-sh-compatible"><code class="language-plaintext highlighter-rouge">sh</code> compatibility</a> from new alternative shells and take it for granted that the <a href="https://www.usenix.org/legacy/event/hotos09/tech/full_papers/seltzer/seltzer.pdf">hierarchical filesystem</a> is the optimal way to organize information.</p>
<p>What are the odds that we somehow stumbled upon the best possible interface for interacting with the computer 40 years ago? What are the odds, in other words, that what we’re doing still makes sense today?</p>
<p>Even the earliest version of Unix was ultimately only a particular, flawed implementation of the Unix philosophy. If we want to encourage more widespread acceptance of the <em>philosophy</em>, we should not try to defend the <em>implementation</em> by downplaying its flaws. Instead, we should confront these flaws head-on and work to build systems that address them while also adhering to the spirit – if not the letter – of the principles on which Unix was built.</p>
<style>.full-post li{margin-bottom:1.5rem}</style>
How to help beginners learn to program2015-02-13T00:00:00+00:00http://mkremins.github.io/blog/how-to-help-beginners<p>Explain programming concepts to them, making liberal use of the words “trivial” and “easy”. This will reassure them that you know your stuff.</p>
<p>Adopt a new motto: “there are no smart questions”. Take any request for clarification as an opportunity to remind all the lurkers that there are some things <em>everyone</em> should be expected to already know.</p>
<p>To avoid coming across as condescending, leave out of your explanations the stuff that everyone already knows.</p>
<p>Give lots of constructive criticism! For instance, consider reminding a beginner that the programming language they’re currently using is shit.</p>
<p>Start a flamewar in the comments of the thread where a beginner is showing off their first open source project – the less relevant to the project itself, the better. This will help teach them how to handle disputes.</p>
<p>Pick apart a beginner’s comments to find spelling and grammar errors, then point these errors out to them. For best results, remind them that no one will take them seriously if they can’t even speak proper English.</p>
<p>Avoid gendered language. Make exclusive use of the neutral pronouns “he” and “him” when referring to individuals of unspecified gender – you don’t want to give anyone the impression that programming is a gendered activity!</p>
<p>If accused of insensitivity, squash the challenge to your authority by doubling down. Make it clear to the PC Police that you’ll have nothing to do with this newfangled “social justice” crap, nor with the advanced form of Cultural Marxism known to the thin-skinned and weak-minded as “having feelings”.</p>
<p>Write a monad tutorial.</p>
<p>Write a lengthy rebuttal of someone else’s monad tutorial.</p>
<p>Make snarky jokes about monad tutorials.</p>
<p>Remind a beginner that real programmers use Vim. If they say they prefer a different editor, ask them what they will do if they ever have to edit a file remotely over SSH.</p>
<p>Point out that their idea has been done before, in Smalltalk, in the 1980s. Consider initiating a flamewar with the person who points out that it was also done in Lisp in the 1970s.</p>
<p>Under no circumstances lie to beginners about the difficulties you encountered when learning to program. If they catch you making the <em>obviously false claim</em> that you yourself once found some aspect of programming confusing, they will instantaneously lose all respect for you.</p>
<p>Flash back in time twenty years. Spend five years honing your skills amidst a culture of cliquish one-upmanship. Spend five years learning how to win arguments through your superior knowledge of obscure incantations, reveling in the feeling that you are different from and somehow better than all the teeming hordes of the mundane. Spend five years memorizing the semantics of <code class="language-plaintext highlighter-rouge">this</code> in JavaScript. Spend five years drinking to the memory of our once-proud civilization, of days gone by.</p>
<p>Surrender. The machines have won. It is all over for us. Resistance is futile.</p>
<p>Sit in a holding cell, awaiting the tribunal for crimes against the virtual. Sleep occasionally, far more frequently than you ever did back then. Resign yourself at last to your fate. Feel yourself enveloped by a deep inner tranquility, unlike anything you’ve ever known.</p>
<p>After enlightenment: write one last monad tutorial, conduct one last flamewar with the Perl hacker imprisoned in the cell across the hall.</p>