I first became aware of the 200 Word RPG Challenge 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”:
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?
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 storytelling partners for their players.
A couple of weeks ago, my friend Esteban 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. The whole series of tweets is worth a read, but the concluding tweet 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:
One of the best and most unexpectedly compelling things I read last month was Jason Brennan’s post on the value of stating the obvious. 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.
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 zone of proximal development that separates what you’re already comfortable doing from that which you can’t yet do at all.
You know those things that, once you learn about them for the first time, you start seeing them absolutely everywhere? Recently, that’s been my experience with problem-solution ordering issues. 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.
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.
Why is this blog called “Affording Play”? What, for that matter, does the phrase “affording play” even mean?
The Unix command line is full of surprises. For instance: did you know that the OS X version of the ls tool, most frequently used to get a list of the files in the current working directory, recognizes no fewer than 38 different flags?
Explain programming concepts to them, making liberal use of the words “trivial” and “easy”. This will reassure them that you know your stuff.