The contract has been signed, so now it’s time to sit back and wait until it hits the shelves right? Not quite. There’s still some work to do. Most publishers will spend some time developing the game even further. This is common and could last anywhere from a few weeks to a few months. The publisher might have a team of people that are responsible for developing the game or there might be just one person in charge of it.
So what happens during this stage? Well, the developer plays your game over and over again, trying to see if it’s fully balanced and retains what it had when they first agreed to publish it. The most common thing that will happen here is small tweaks. The cost of one card could be made more expensive as it proves to be too powerful in their tests; the quantity of resources given out might be changed for balance reasons. It could be bigger changes that range from adding or removing certain aspects or even changing the theme of the game!
A famous story is how Reiner Knizia’s game, Through the Desert started as a game about campers. The publisher liked it but wanted to change the theme to camels in a desert – and the rest is history.
We were fortunate for this stage so far as we were involved in all suggested changes. Most of them were fine by us, but once in a while we would share our thoughts on why we would disagree. Sometimes it was because we had tried that in an earlier prototype and found that it didn’t work in the long run for various reasons. Most, if not all of the time, the developer listened to what we had to say and took action because of what we said.
For example, at one point we suggested starting players with some resources, and while at first it was thought not necessary by the developer, we eventually playtested it and found that it sped the game up considerably. Alternatively, we always had a rule in there that you could sell your buildings for a certain amount of gold. Eventually the developer realized that hardly anyone ever did that, so it was better to just remove it which removes 1 option players have – which is fine in this game as there are plenty of other choices to be made!
For us, the developer process was lengthy for Belfort and almost non-existent for Train of Thought. Train of Thought is a party game and it didn’t require any changes at all. The only development for that game came with the rules editing. Belfort is a deep strategy game and the developer playtested the game numerous times over the 6 months. Every few weeks we’d get some new reports on how the latest playtests were going. We communicated using an online forum since we were all located in various parts of North America.
It’s key in this stage to maintain a positive attitude and a humble demeanour. You don’t want to get on the publisher’s bad side at this stage. If you want a reputation, then get one that is about how easy it was to work with you as a designer. That isn’t to say that you should just lay down and accept everything they suggest. We chose our battles wisely and only really stuck to our guns if it negatively impacted gameplay. This should be one of the most fun times for you as a designer, so don’t spoil it!
When not creating games by night, I’m a mild-mannered pediatric Occupational Therapist by day. In my line of work, I constantly tell parents that a huge percentage of the problems they or their children are experiencing could benefit from improved communication. And the same goes for working with a developer – fostering an open and understanding dialog is key to ending up with a result that everyone can be happy with and proud of.
Because Jay and I work as a team though, painfully separated by huge tracts of land, we have become somewhat experts in communicating with each other. For the most part, we are able to get our points across without ripping each other’s throats out. Having access to modern technology like Skype and our forum has really enabled Jay and I to be able to do our work despite the 3-hour time difference. We have become fairly adept at putting our ideas into writing, making physical prototypes and working things out from a distance. Giving and receiving feedback with our colleagues from the Game Artisans of Canada and our playtest teams has been hugely beneficial as well. All of these skills have been definite assets when it came to working with Seth Jaffee, our Developer on both Train of Thought and Belfort.
So, working with a developer is no different than working with anyone else – communication is a game. Everyone playing just needs to know the rules, the boundaries, and share a common lingo.
What I mean by this is not necessarily the rules of the game itself (though you should know those like the back of your hand, I hope!) but the “rules of engagement”, as it were. Questions you need to answer may include: Who’s in charge of what? Who’s tasked to what? Who’s the final decision maker? What is the purpose of this iteration cycle? Arming yourself with this knowledge can help you avoid some of the common misadventures that happen with groupwork – Going It Alone, Reinventing the Wheel, Passing the Buck, and the ever-dreaded Stepping On Toes.
Fact 1: You are designer of the game. So it’s your baby.
Fact 2: You have signed away your rights to the game. So it’s basically been “adopted”.
This means that you need to understand a few things, like it’s the publisher’s call whether or not the game needs to be rethemed. It’s the publisher’s call whether or not there are too many cards in Deck A, B *and* C. And, thus, by proxy, it’s the developer’s call as he/she has been employed by the publisher to take the game and make it better suit the publisher. You need to be aware going into this relationship that the developer is not there to work for you. He has a different agenda. It’s more than likely 99.9% parallel to yours, but you’ll note that I used the word “parallel” as opposed to “same”. He may have the task of ensuring that there is the least amount of language on the cards, for example, which requires you to review how the rules work with only icons. Your agendas need not clash – in the end, all parties just want to make a good game. But it takes an understanding on all sides of the die that everyone knows what’s up.
Speaking of which, one boundary that you, as the designer, may wish to discuss with the publisher and developer is your overall vision for the game – what were you trying to accomplish when you made the game? What are some of the high priority “no sale”, make-or-break items for you? If the developer holds these in mind while he is doing his thang, everything will flow from those overarching elements. It’s important to look at the game from the macro viewpoint every now and then to ensure that the wholistic nature of the game is still intact after all of the micro changes that are made. But without talking about that kind of stuff, how is the developer supposed to know? He’s not a mind-reader anymore than you are.
Share a Common Lingo
This, simply put, means that everyone is on the same page language and terminology-wise. You will save yourself a lot of confusion and arguments if everyone knows that when you say SP you’re referring to Skill Points, not Spell Points. Having very clear rules with well-layed out phases of play and a glossary of terms can really help everyone understand each other. When everyone speaks the same language, the flow of ideas is much more seamless. It helps streamline conversations when people can refer to the same points of reference instead of having to call something the “the-part-of-the-game-where-we-roll-dice-and-move-things-but-we-don’t-pick-up-any-cards-because-that-comes-at-the-end phase” (er…you mean “The Movement Phase”).
So keep the lines open between you, the developer, and the publisher. In the end, change is generally for the positive – i.e. to make the game better (in terms of playability, saleability, etc.). Be open and accepting to feedback, because if the agendas are parallel, everyone is hoping to get to the same place. So embrace change instead of fighting it, just ask for clarification/explanation from the developer if needed.
In short, communicate.