Connecting Workspace Culture to Qualities of Player-Creator Communities
August 9, 2012
PROJECTS: Leveling Up
PRINCIPLES: Academically oriented, Interest-powered
TAGS: Connected Learning, Little Big Planet 2, Portal 2, StarCraft II
As a learning scientist one of the first things I was trained to consider is my underlying epistemology—the theory of knowledge, or what it means to know—and how that relates to the learning environment being studied. Seymor Papert (1980) discussed epistemology as what “reflects and reinforces a particular way of thinking and knowing that is aligned with the norms and principles of a particular community” (Hatfield, 2011). This blog post is about how different modding platforms and communities are different not just in surface characteristics, but at a deep “way of knowing” level that may invite or discourage participation for different learners. I believe this has implications for how educators, parents, and designers think about engaging learners in making and modding activities, and how we can make these practices more inclusive.
The second observation this post is sharing is that the epistemologies of these modding communities are extensions of the design studios themselves. By the end of this academic year, our team had conducted all of our on-site interviews with the design teams of LittleBigPlanet2, StarCraft II, and Portal2’s PuzzleMaker[1]. One of the things that struck me was how different each game’s design team was. As I struggled to tell colleagues about what I’d seen and learned about game design from each group, I came to a realization about how their internal work structures framed and shaped the design tools they’d released to their modding communities. For example Valve’s culture is strongly based on the scientific method, and this comes through in the Portal2 modding tools. I think this provides useful insight into why modding tools and communities are different, and how these differences can inform the design of learning environments. Individually each game platform offers a different epistemolgy for modding; collectively they present multiple ways of “knowing” modding.
An epistemology frames what matters for knowing, and that in turn determines what matters for learning. This is a big idea that has deep implications for the design of learning environments and tools, and specifically the game modding environments we studied.
Epistemology Applied: Epistemic Frames and Epistemic Plurality
An epistemic frame (Shaffer, 2007) is composed from the “linked and interconnected values, knowledge, skills, epistemology, and identity of a practice.” To make this a little more concrete, it helps me to think in terms of Shaffer and Clinton’s (2006) work on toolforthoughts: the idea that each generation encodes thinking into the tools they produce, enabling the next to leverage that thinking through the tools themselves. For example, think about a modern hammer. It has “baked into” its design all the thinking about needing to pound nails into other materials. It removes the necessary thinking of finding an object appropriate for pounding nails, and benefits from 2.6 million years of design refinements to the weighting, leverage, and ergonomics. But most importantly, once introduced to a hammer, even young children can benefit from the while playing with their platonic solids toys. The basic implication I want to illustrate in this post is that if we consider that game designers have encoded their thinking into the tools they use, and offer to the modders, and we pay attention to the design and functioning of the community around the tools we can start to understand how each community is operating with a different epistemological frame.
Ok, but why does that matter? The briefest answer is captured in Turkle and Papert’s work on epistemological pluralism (1991) which showed that computer science was dominated by a singular, hegemonic way of thinking to the exclusion of other epistemologies. This in turn leads to the self-exclusion of learners not conformant to the dominant epistemology. Epistemological pluralism–the valuing and acknowledging of multiple ways of knowing a domain–provides a way to frame the meaning of the different in terms of the academically oriented and interest-powered design principles of connected learning.
The exciting thing I realized is that each of these game modding environments and communities instantiates a different epistemic frame around what might be considered common skills in modding (e.g., level design, programming, etc.) Meaning that these communities break away from standard epistemologies that may exclude non-conformant participants from domains such as game design and programming. And these differences are based in the company cultures that created the environments.
The Cases and Frames
I created the table below to summarize the findings, the most important row being the Epistemic Frame Characterization, because it indicates the epistemic frame that emerged from my analysis—these are not characterizations the designers or companies used. In the following sections I’m going to give a few details on how these characterizations emerged, and some design principles that help operationalize the characterization, but full analysis will be published elsewhere.
Media Molecule |
Valve | Blizzard | |
Game | LittleBigPlanet2 | Portal2 | Starcraft2 |
Size | ~50 | ~293 | ~4000 |
Idiomatic Expression | You’re being precious | Put it to science | That isn’t concentrated coolness |
Epistemic Frame Characterization | Artist’s Collaborative Studio[2] | Science Lab | Engineering Firm |
Each company has a very different size, and I suspect that has some influence on the functioning of the design teams and as a result, the products and communities they support. I’ve also included an idiomatic expression from each group because it struck me how these expressions align to the rest of the characterization: the idea of something being “precious” is highly aesthetic, qualities associated with art; “put it to science” is a procedural kind of phrasing, and attentiveness to process is a defining quality of science; “concentrated coolness” is incredibly structural and descriptive of a design intention, which are components of engineering thinking.
MediaMolecule and LittleBigPlanet2 as Collaborative Studios
One thing that kept coming up in our interviews with the designers at MediaMolecule (Mm) was that tools aren’t what drive creativity, it is the artifacts that they allow us to produce. To paraphrase several of the Mm team-members, “A pencil isn’t inspirational, a drawing is,” i.e., seeing the drawing drives an observer to ask to take over the pencil, and try it themselves. This design principle, that inspiration is driven by the work of others, is realized through the game levels in the LBP games, where the Mm designers try to inspire the community by treating their own levels as fun ideas to share. This leads to the supporting design principle: design for sharing.
“When we started media molecule it was really really key to us that we kept the company small and we didn’t really have a rationale for that. It was a gut feeling…when you work together and when you inspire each other, it just doesn’t scale. But it’s actually even more true in terms of creative inspiration. You want to have a small group of people around you, and be constantly aware of what they are doing and what they’re into…that way the amount of cross-fertilization is through the roof…But I love the fact that we still inspire each other everyday…If someone has an idea, I’m probably going to see it within 10 minutes.”
— Alex Evans, Technical Lead, Media Molecule
This kind of cross-fertilization requires trust, which makes it safe to share unpolished or partial work. Within a small team like the one at Mm, trust can be established through management and hiring processes. In a global network of players, Mm implements this kind of sharing by constantly curating the feel of their community for friendliness, and by removing certain types of polish from their tools. Sharing at Mm is related to the design principles of designing for friendliness and designing out polish. In one interview it was explicit that a culture of polish impedes sharing, and in turn creativity; as a result LBP was designed as an environment that would minimize that cultural effect in favor of fostering creativity.
With that frame for the culture of Mm and LBP, the final piece is the experience of the tools. Much of the experience of creating in the LBP games feels like drawing or painting–even before the PS Move Painting update. You select a material, and a shape, just like you would a paint and brush, and begin to create the hills and buildings of your level by dragging that shape across the canvas. The tools themselves feel like our traditional tools for making art.
Taken together, the production tools and the way the community is crafted, make this feel like an invitation to view the world as an artist in a giant studio where a necessary part of the work is sharing ideas as they develop.
Valve and the Portal2 PuzzleMaker as a Science Lab
One of the things that made me smile while we interviewed members of the Portal2 team in September 2011, was how everyone seemed to reflect the identity of GLaDOS, the AI in charge of Aperture Laboratories’ science experiments in the Portal games. At first I thought, “How funny! The narrative ‘rubbed off’ so much on them that they talk like her.” But as the interviews went on, I began to appreciate how central a scientific process of design was to the Portal team’s work.
“Every week, we would sit down with somebody, and they would play-test [Portal2]. And I think that was super-core to what we do because, we don’t want to ever be in a place where we feel like, ‘We’re these great game designers, we’re going to tell players how to have fun, and we’ll just put it out there and they’ll enjoy it,’ because we’re so wrong when we do that. There’s probably nobody at the company who hasn’t had this tragic experience of, ‘Here’s my great puzzle,’ and then somebody breaks it in like 2 minutes, and they’re like, ‘Ok, my puzzle isn’t that great.’
“So, that’s why we just kind of put everything to science, right? We have some assumptions about what we think will work, we have some guidelines to make us think, ‘This will probably work better than other things we can do,’ so we can kind of pare it down to what we think is a good puzzle, but ultimately it doesn’t really mean anything until we’ve really given it to our customers…”
— Joshua Weier, Portal2 Project Lead Coordinator
This kind of play-testing is used company wide, and is a general part of the Valve design process. But even more pervasive than design and play-testing is the idea of approaching their design work as a scientist would. In late April 2012, the Valve Employee Handbook was leaked online[3]. Reading it will reveal many interesting things, but most relevant to this post is that the scientific method is core to every decision they expect employees to make. The design principles we uncovered at Valve reflect this as well. First, test all the time. Second, make failure part of the process—which may require some explaining. This principle is about recognizing that failure is an important part of learning. By thinking of failure part of the process of getting to a goal, such as learning a game mechanic in order to pass a level or developing a new design, failure becomes a useful mechanism, rather than a formidable opponent.
When we look at the Portal2 PuzzleMaker as the scientists’ lab bench, it is easy to see how integrated the idea of testing all the time is: just click the ‘play’ button at the top of the screen, and you’re quickly dropped into test mode. When you publish a level to the Steam Workshop, you provide a title and description, which has a feel very much like outlining a lab report. You can keep revising published levels, iterating on the design, until you get the idea (experiment) to where you want it. Each revision is tracked, like an experiment log, allowing the designer (scientist) to monitor their work. Other players complete the lab report by providing comments and feedback to the creator, creating a running log of the experiment.
The immediate experience of the PuzzleMaker even feels scientific. You have a limited set of tools such as tractor beams, faith plates (catapults), etc. from the game–about 20 total. Your activity is to configure the space by changing the layout of the test chamber and positioning and composition of tools employed.
The whole experience of the PuzzleMaker and the Workshop reminds me of my high-school chemistry and physics labs, and feels like a way to ground oneself in the scientific method.
Blizzard and StarCraft II as an Engineering Firm
From our first interactions with Blizzard, everything felt architected. There were more formal structures to engage, and almost always a process that Blizzard had in place to shape the experience. Several of the team members we interviewed commented on how this highly structured feel had become more a part of the experience as the company had grown over the last decade, so it seems fair to associate some of this change with the scale of the company. But what really struck me was the aesthetic of the game design work and the team, and how the elements came together to form a very formal identity.
There were about 100 people in the team for StarCraft 2 when we visited, and the layout of the workspace was more divided along role boundaries than at Valve or Mm: programmers were in several different locations, separated from the level designers who had their own area separated from artists, etc. This created a sense of the work really being focused individual expertise with narrow scopes, suggesting that the team was a collective of specialists. We talked to several of the editor designers, and as we did, my background as a computer scientist and tool creator screamed out subconsciously, “These are your people!”
The thing that really drove this all home for me was part of our interview with Dustin Browder, the Managing Designer for StarCraft 2 and the idea of barriers to entry in StarCraft 2 came up.
“[T]he barrier to entry for Starcraft, we know this barrier is real — we’ve seen this barrier out there where players will struggle at different points in the experience. It’s not something we’re really proud of at the end of the day — it’s something we do keep wanting to fix. We do accept a certain amount of it, because at the end of the day the e-sport experience is something that we’re supporting and that fundamentally means there will be barriers. But anything we can do to ease that out for a lot of our fans is something we absolutely want to do, and we keep working on it. At the end of the day, we say, ‘You know what, if there are barriers, there are barriers.’ The sport is what matters, right…[I]f there are barriers that exist, we will work at getting them out, but we’re not going to dumb the game down to remove those barriers. We don’t want to not have the sport, just to make it easy to get into. And certainly at other places I’ve worked at, those are the types of decisions we’ve made.”
— Dustin Browder, Game Director, StarCraft 2
Parts of this read as though they are pro-barrier, and that stuck out to me, because in other parts of the discussion we talked about how large even 1% of their player base is[4], and how hard they work to make sure that anyone buying a copy of the game has an experience worth the money. So why be pro-barrier? I have a hypothesis that this was not simply for game and e-sport reasons, but is in fact connected to an engineering ethos, and as an initial way to confirm my read of this passage, I asked an engineer to read it. I didn’t provide any context for the passage other than it was from an interview about StarCraft 2. The engineer’s response was “Oh, that’s someone that I could talk to! He gets the value of complexity and isn’t going to compromise. Is he an engineer?”
What my informant identified as being an engineer’s way of viewing the world in the excerpt included above is related to the general engineering process. Engineers 1) focus on their responsibility to make a design work, not necessarily to make it accessible to everyone, and 2) refine the design to make it clear to themselves to ensure accurate understanding of the design, while minimizing risk of malfunction, 3) given 1 & 2 documenting and describing the design for non-engineers doesn’t provide much value or reward to the engineer themselves, so they don’t invest in it. The underlying principle for engineers is that they routinely deal with complex systems, and don’t want to create partial (mis)understandings of the systems they build. An engineer will happily discuss the system at a high-level, but until you spend enough time to show your dedication to fully understand the complexity of the system they will hold off on the real details.
When you open the StarCraft 2 Editor, the modding tools included with StarCraft 2, you are welcomed into this engineer’s epistemic frame. You have a wealth of options, the flexibility to change nearly anything: an open and complex system. And this flexibility and power are prized and valued by the community based on my observation of the StarCraft 2 Modding forums, and our interviews with the team at Blizzard. Their modding tools and community have given rise to new game designs such as Defense of the Ancients (DOTA) and Tower Defense style games. These games were made possible because of the complexity of their modding tools, emerging from the flexibility of the tools themselves.
In fact this points to where the positioning of the person happens. Engineers separate solutions from the social implications of the problems, a feature facilitated by making their tools general (Agre, 1997). But more than that, the engineer is separable from their tools, left to become specialists that use, but are not used-by the tools. The StarCraft 2 Editor positions you as someone that thinks like an engineer.
I haven’t said much about the design principles we uncovered at Blizzard, mainly because the team expressed that it boils down to this:make it easy to learn, and hard to master. This again resonates with the enjoyment engineers find in complexity. Complexity creates fun, hard problems to grapple with, and that is where engineers find their rewards.
Why These Characterizations Might Matter
The ability to mod is becoming an expectation of players and learners as they encounter opportunities to tweak, reshape, and remix the things they use on daily basis. Turkle and Papert pointed out that the hegemonic epistemologies of some communities of practice exclude participation by some learners. If we want to make sure that learners feel invited and welcomed into connected learning opportunities such as modding and modding communities, that cross academic, civic, and adult driven areas of their life, then acknowledging the differing epistemological opportunities of modding communities matters. Furthermore, successfully bridging a modding community into the classroom may be more likely with an understanding of the epistemological frame of the modding community itself.
The broad observational take-aways from this post are that
- LittleBigPlanet 2 is…
- optimized towards physical experience of painting or sketching, and
- encourages the social practice of broadening definition of creativity through participation in the community.
- Portal 2 is…
-
- optimized for rapid iteration and idea exploration, and
- invites participation in social practices that replicate scientific method.
- StarCraft 2 is…
-
- optimized to maximize flexibility and power for creators, with minimal structure, and
- fosters and reinforces engineering practices through tools and community dispositions
This is a long blog post, and I’d love to hear from you. Do these characterizations reflect your own experiences of these games and modding communities? How have your experiences differed?
I’m also very curious about applying this idea to Minecraft. I’ve dabbled with it, but I don’t have a good feel for what the epistemic frame might be in Minecraft. I suspect that it will vary by the local server, but really don’t understand the game communities well enough to say yet. How would you frame Minecraft?
References
- Agre, P.E. (1997). “Computing as a social practice” In P.E. Agre & D. Schuler (Eds) Reinventing technology, rediscovering community: Critical explorations of computing as a social practice. (1, pp. 1-18). Greenwich, CT: Ablex Publishing Corporation.
- Papert, S. (1980). Mindstorms: Children, computers, and powerful ideas. New York: Basic Books.
- Shaffer, D. W., & *Clinton, K. A. (2006). Toolforthoughts: Reexamining thinking in the digital age. Mind, Culture, and Activity, 13(4), pp. 283-300.
- Turkle, S., & Papert, S. (1991) Epistemological Pluralism and the Revaluation of the Concrete. Retrieved from http://papert.org/articles/EpistemologicalPluralism.html May 1st, 2012.
[2] Note that I am not asserting that MediaMolecule was collaborative, while the other companies are not–they are all highly collaborative studios. I am referring to the idea of a group studio rather than a solo artists’ studio. See http://www.culturemachine.net/index.php/cm/article/viewArticle/83/59 for more on this.
[3] As of this writing it can be found at http://assets.sbnation.com/assets/1074301/Valve_Handbook_LowRes.pdf
[4] The off-the-cuff estimate during the interview was 1% of players is somewhere north of 50,000, enough to fill Dodger Stadium.