Over the past few months, I've spent a lot of time talking about design, but I haven't gotten into how we organize our development schedules. With the release of the public print-and-play kit later today, it seemed like a good time to talk about how game development works. At least, to say a few things about how we make games here.
Design vs. Development
I should say right away that I don't see much of a practical difference between “design” and “development” in terms of the actual types of work expected of both a designer and a developer. I could throw all sorts of platitudes at you, but basically they are part of the same process. To make a game you need to design a system and then you need to keep iterating and adjusting that systems until it best captures whatever tension you want to capture. Design requires development and development requires design.
Often I've heard some folks suggest that the designer sets the general course for the game and develops some of it's core systems. A developer iterates within the framework offered by the designer to realize the game. When it comes to job titles, I think that's a fair distinction, but it still doesn't say much about the difference between the work of development and the work of design. Even in that example both the designer and the developer are essentially doing the work of iterative design.
I wanted to say this all up front because, for the sake of this piece, I'm going to be using both words quite a bit and I wanted to make sure that everyone understood that the many kinds of labor behind the making of a game bleed into one another. For that reason, I'm going to try to focus on the jobs and processes that we put a game through before it goes to print. For those wanting a clever distinction between designing and developing, I'm sorry.
Our Process
Alright, let's get started. At Leder each game has a “Design Period” where a game is incubated. This could take several weeks, months, or years. During this time a single person (who we often call a “designer”) will iterate and ponder and push their various ideas until they take a shape that seems promising, and maybe, if you squint a little, like something that might be published.
At this point more resources are directed towards the project. This might include some concept art, but mostly these resources are comprised of the project leader's time. They essentially gain the ability to spend a significant portion of their day pushing the game further. Iteration intensifies, and perhaps other staff members are pulled into play-test sessions.
Then there's a lot of thinking about whether or not this game is looking like something we should actually put on the schedule. We have to think about our audience, our brand, our mission, and our tastes. Is this the kind of thing that we would feel comfortable selling something? Should this thing exist?
Assuming the answer is yes, we take a look at a project and try to figure out how long a project will take to actually make. This is a complicated and imperfect assessment, but we have several folks on staff who have helped take games through the publication process and, as a group, we have a pretty good set of experiences to draw on. During this conversation, I usually find myself speaking in terms of “design liabilities,” that is, unstable or new design elements that could be really troublesome and threaten to derail a project. We also talk a little about budget, production demands, and what other editorial/creative/operations resources we might need to draw on to actually make the game. From here we create a loose schedule and get to the business of making a game.
When I talk about development in the context of Leder Games, I'm usually talking about the period after the resources of the studio are brought to bear until the moment the game is at the factory. It's less a kind of labor or a job title than a phase of the game-making process.
So, for Oath, I'm serving as something of a project lead and manger. I'm also heading up the design , organizing development, and doing my best to help on the game's marketing strategy and product design. That sure makes it sound like I'm doing a lot! And while that's true, it also belies the fact that I'm also just a member of a broader team of developers, editors, graphic designers, production managers, marketers, and others who make the game possible. We aren't a large company, so everyone is expected to help in the making of games. Lots of hats get worn by everyone.
Playtesting and Version Control
Around this time, I also get together a cadre of playtesters that I think will be well-suited to the project. Generally, I don't do public playtesting calls. Instead, I try to find playtesters that I think will be critical (in all senses of the word) and challenged by the project of trying to understand the game.
If you include playtesters, it's around this time that the “team” behind each game goes from one person to more than twenty or thirty. That means my own role starts to shift away from a “lone artist” to something more like a low or mid level manager. All of that project management that got me through graduate school has paid some serious dividends in the world of game design.
Writing about this shift now, I'm struck by how seriously different the demands of each of these phases are from one another. During the first phase, that is, before development begins in earnest, I don't really need to worry about the file structure of the game's assets or it's version control. Think of it like a workshop. One person working requires only a small room. But a staff of thirty would require a large suite, with common rooms and a meeting schedule to make sure information is passing between the different team members.
Things like version control can get quite hairy. Usually I will have a bleeding edge version of the game that I'm using to test internally. Sometimes I'll branch this design and have a secondary version that is also being tested within the studio. There are a lot of adjustments that are made on a daily basis. When I was first learning the craft of design, I would share these findings with my playtesters almost as soon as I had vetted them (sometimes before). Boy, was that a mistake. The playtesting kit versions cycled so quickly that I exhausted dozens of excellent playtesting groups.
To stop this, I introduced something of a buffer. In the studio, I would happily iterate and adjust to my heart's content, but I would avoid making any iterations to the game unless there was critical fix needed or at least two or three weeks had elapsed. (As you might guess, there are lots of exceptions to this. Root was iterated very quickly with an outstanding corps of playtesters. Oath will probably have minor updates about every two weeks or so for the next month and then settle into updates once every three weeks.)
I tend to think about the current playtest version of the game as its “proper version.” I make this distinction because sometimes I'll need to take this version and create a copy for public print-and-play kits. A public print-and-play is basically out-of-date within a couple weeks of its release. We don't offer any support for them outside of the initial files. They are mostly a gift to folks outside of our team to see how the game is looking and to give them a chance to enjoy and explore what we've made so far.
There are a few other wrinkles to this system as well. In addition to remote playtesting groups, we have several local groups that play on Wednesday nights at the office. These groups play a branch of the game that is, in practice, somewhere between my bleeding edge branch and the playtesting version. We also have to send out preview and review copies which are a little like the public print-and-plays in that they are snapshots of the playtest version. Usually the delay on the publication of any piece about a playtesting version is one or two versions out-of-date by the time it is published. I think there are probably kits for half-a-dozen different flavors of Oath floating around right now.
A lot of this process is designed around a central logistical problem: kits take time to build and time to send. So, in an effort to not fatigue my playtesters, I do what I can to protect them from the generative iteration that is at the center of the process. Essentially, I'm trading someone else's logistical problem for a managerial one that I have to deal with.
This is another reason why we keep our core playtesting efforts closed. Every playtesting group places demands upon me and the team here. Those demands might include things like technical support and rules questions or just time spent reading the feedback they provide. The best playtesting groups often demand the most of my time. Thankfully, there are a lot of systems one can put in place for helping to mitigate this ask. We're using a new feedback system for Oath which relies on google forms, google sheets, and a robust discord channel. It's worked really well and I think will essentially allow us to double or even triple our core playtesting capacity.
This is great, because we've got a lot of work before us. Though Oath is far more finished now than most of the game's I've helped Kickstart, but there is still much to do, and the time we spend managing playtesting teams is time well-spent.
The Benefits of External Testing
Our playtesters give us three things: a better understanding of the game, the ability to stress test the balance of certain game elements, and an audience to test the usability and accessibility of things like rules and components. Critically, I don't care if playtesters like or dislike the game. That's always a nice bonus, but it's not their job. I don't rely on testers for market research nor do I care if they tell their friends to buy it (or not buy it). I want them to help me understand the thing we are making together.
The months of work that usually follow a Kickstarter are all about developing a deep knowledge of the game's space and the questions that orbit around the design. As those things come into focus, the nature of playtesting shifts towards trying to create the widest possible decision space for players in the game—I often call this work balancing a game though sometimes balance in the traditional sense (Nerf x! Buff y!) has nothing to do with it.
While the process of balancing continues, we will begin building out our usability studies. Some of these are conducted in our offices in Saint Paul and others happen remotely, mostly under the watchful eye of our editor, Josh Yearsley. During these tests we work hard on the physical design, adjusting wording and trying to build play aids that make the game easier to play and to think about. Josh has written quite a bit about this process before and I imagine he'll be writing more about Oath in the future.
As usability ends, we start to clean up the files and prepare the game for print. This process involves me handing off the working files I have to the staff graphic designs who punch them up into shape for both the factory's print specialists and any future language partners we might gain after the release of the first print run.
During this late stage, it's still possible for me to make changes to the design, but with every day the changes become costly in terms of the labor it would take to adjust actually make the change. The changes also become a lot riskier. Many of the systems of oversight that guided the development of the game are in the process of shutting down and so you start to lack the ability to vet what you're doing.
This is one of the great paradoxes of game development. As your knowledge of the game deepens, your ability to intervene weakens. It was so much easier to make big changes when everything was on just a few pages in your notebook.
After Images
In the years since Root was published, I'm often asked how much testing we did in the studio. How could I begin to answer that question? The final print version of the game was played only a handful of times before we sent it of to factory. But, surely the plays of near-final versions counted for something too. Hundreds of games were logged in the studio and thousands more if I include my playtesting teams. We took the game through a mountain of usability testing and vetting and showed it to close friends and confidants, but none of those versions were the final game. They were just precursors, ghosts of a game-to-be. Really, that's the work of development and game publishing. During the development process the game isn't just one thing. It's a dozen things, maybe hundreds. All of those weird little ghosts bear some resemblance to a thing you want to exist, but no single image seems to capture the whole project. With each week and month of labor, these phantoms shed until you just have a single, indelible picture left. Sometimes that final image is not quite perfect—it might be haunted by other versions which were not quite laid to rest peacefully. But, when it works well, the game appears in perfect focus: the single sum of all of that work.
And then of course you send that packet of files to a factory for duplication.
- Cole Wehrle
Visit Board Game Geek to see the original post and discussion.