Getting six people to work on a focused goal is pretty easy — I’ve run teams plenty of times and it’s just not all that complicated. It works easily, however, because the social structure lets it basically be me with five extra sets of arms. That is, I plan and organize and command and review and collate and present. My team members get their piece done according to my plan. This is not collaboration. It’s a way that some things work, and it’s good, but it’s not collaboration.

VSCA projects, by contrast, are strictly collaborative. Each author has (theoretically) equal input and consequently organization needs to coalesce rather than emerge whole. This means that we need a richly iterative model in order to get work done. This was brought home for me recently while discussing Chimaera progress with JB, during which I tried to explain how we were going to bootstrap the idea into a game. All too often I have no idea what I am doing until I try to explain it to someone else, at which time I discover that I really do have a methodology.

The essence of VSCA collaboration is play. We never go away and write a game whole and then playtest it, but rather we playtest very coarse drafts and fragments of subsystems and revise based on the information from that and over and over and over. Always playing. We don’t have meetings, we have game nights. But we’ve had precious few game nights in the past two years that haven’t also been game designing. I don’t think I can go back to “just play”. This is play for me now.

So we don’t really do anything with a project until someone writes enough to play with. It can be just a subsystem or a dice gimmick, but it has to be enough to drive an evening’s play and discussion. So we start with this kernel of a few thousand words in which someone tries to explain the game. It doesn’t need to be refined and it doesn’t need to have a “voice” yet, but it does need to convey enough to everyone else that we can all get our teeth into it. Until this happens there is no project. I don’t care how much information you have in your head, until you share we aren’t collaborating.

Once we have that kernel it goes up at the wiki where anyone can hack at it. Now all kinds of semi-organized work happens. Links to AP reports and audio go up. New text goes in. Micro-fiction from play or imagined play goes in. Proposals are made. Things get re-organized. Images and other art tests get made and linked up. Basically the wiki becomes a multi-media creative collage of effort from the collaborators. It’s a mess. Probably no one can play with it but us. But we certainly can.

Every game night that is exploring a project is recorded. Immediately after play, someone tries to capture the essence of what we learned that night and post it up at the wiki. Early on there are more questions than rules, but that’s cool. We are confident that an organized project will show itself over time. We don’t need to make it happen yet.

The basis of iterative development is obvious — the idea is that you cannot design perfectly and then implement. That is, designs are always flawed. With that as your core premise, one solution is to design only a minimum and then get it working in as real an environment as possible, take notes, and push those back into design. Revise the implementation and re-test. This avoids designing shit you don’t use and highlights stuff you didn’t know you needed. Anyway, all of this is familiar to software designers and fits nicely into the led-team model.

It also works for peer collaboration. In fact it works better for an important reason: it establishes a certain amount of investment (even ownership) in all the collaborators. The core idea will change — although that came from one person’s head and was perhaps perfectly clear in there, in play and revision the author’s peers will take what they like and expand it. They will tear down what they don’t like. They will tell you what they saw when they played and it will be different than what the initial author saw. The game, in short order, will be other than what the originator intended. This is real collaboration and it’s terrifying.

Allowing your vision to be influenced by others requires an incredible amount of trust, especially from people who are trained to operate in an authoritative role. We (people like me, I mean) expect to command with a limited amount of dispute after a certain (brief) period of initial research. But when everyone at the table is at least as smart as you, you can no longer afford this ego-friendly attitude. And it makes you realise that, because the disputes and changes are emerging from real play and an effort to have real fun with diverse brains, it is a reflection of the interests of a potential audience as well. And consequently you are tricked into respecting the audience in the same fashion. The game now has its own design goals (or perhaps the design goal of the gestalt brain that the collaborating team represents) and these goals are roughly representative of the audience, because any gathering of four or five people probably has many general qualities that are represented by a much broader subset of people. I might not be well represented by any substantial group of other people, but the intersection of the interests of five of us certainly is.

So respect and trust are created by earnest iteration over play. Play. Let’s say that again. Play. That’s an order.

–BMurray