Mel Brooks’ ‘The Producers’
Post by: Grant Rodiek
I started in the video game industry in 2005 just a month after I graduated college, left Oklahoma, and arrived in San Francisco with a Civic packed with stuff. I’ve worked at Maxis for all but one of those years, almost entirely as a producer, though sometimes as a designer, and occasionally a producer moonlighting as a designer.
In 2014, Joshua Buergel and I decided we would publish Hocus Poker and later, Landfall. This is a big decision and one I’ve personally been hovering around for years. I’ve never had the courage, the right game, or the right level of risk. I’ve always felt my professional experience has been immensely helpful to me in my table top work. Obvious examples include my diligence in crafting early rules, ability to work well with artists, experience with testing techniques, and years of experience with giving and receiving frank feedback.
But, now that I also want to be a publisher, I’ve really noticed this set of skills coming into play. I thought about how important it has been for me, but also, how useful it is. As I look around the hobby there are a TON of people who are starting out as publishers. There are obviously those who have their start in Kickstarter in just the past few years, but also POD producers, but also, young companies like Plaid Hat Games (Summoner Wars released in 2009) and Stronghold Games (Survive and Code 777 released in 2010).
As many publishers will tell you, when you are a publisher, your focus shifts from design to producer. If you listen to the Plaid Hat Podcast, it’s pretty clear Colby is more Executive Producer now than designer. It seems that’s always been Buonocore’s role (and he can correct me if I’m wrong!).
Now, I don’t dare profess to any of these people that I know better. Certainly not. But, some who only have one game under their belts, or seek to start a discussion, might find use in some of the key lessons I want to share. Or, perhaps, you’ll just find it interesting to hear about the perspectives of a video game industry veteran? This was a fun and personal entry to write, so I hope you enjoy it.
Here are the key things I think you need to be a good producer of games.
You don’t need to be right, nor do you personally need to provide the answer. Your job as a producer is to ensure the delivery of a great product. You need to check your ego, and check it often. Instead of fighting for your solution to be the one chosen, fight for the problem to be heard and addressed. Do not let issues plaguing the game be ignored due to other issues or swept aside from budget concerns.
Find and champion the person who has the right answer. Producers are managers and team leaders. Don’t abuse your management role to get your way. This means you give voice to those without power and silence the nonconstructive naysayers. You’re the moderator in the great debate that is game development. Identify the problem, listen to your team, and find out who has the right answer.
Always fight for the best team. It is so painfully easy to settle for good enough. The first barrier is money. I cannot afford the right person. The second barrier is time. The right person is busy, or we need to have this finished RIGHT NOW. People are the brunt of the cost in game development and you can rest assured you’ll get what you pay for.
Costs roll down hill in the form of wasted time, re-work, and customer dissatisfaction. Consider that a poor rules editor will lead to time you spend on the forums answering questions. That also affects your prestige negatively. Art, a potential competitive advantage and a huge way to stand out on a crowded shelf, is so easily compromised. Yet, time and time again, beautiful and distinctive games have a leg up on their uglier cousins. Invest in good testers to find the core issues with your game. Or, don’t pay to spend decks out and listen to your best buds.
Always fight for the best team. Surround yourself with brilliant people. Game development is a series of conversations solving problems. Who do you want on that problem?
Focus on the customer. A designer’s primary concern is the game. Their focus should be on the philosophy, the goals, the vision of the game itself. This is their sliver of the pie. A producer’s primary concern is the customer. These are 2 sides of the same coin, but from a different perspective. Let’s consider a few situations:
- Designer: Here is a cool mechanism. Producer: How will it be explained in the rules?
- Designer: This component is ideal. Producer: Is it $5 better for the end consumer?
- Designer: Battle resolution requires these 3 steps. Producer: Re-work it to be faster and more intuitive.
I’ve written about this extensively lately, but with Sol Rising, my experience was:
- Grant: This is a story driven game. Publisher (producer): If that is the premise, you need to infuse the actual game with more story.
- Grant: This is how the game is setup. Producer: That feels intimidating. Find a way to expedite and simplify.
It isn’t that the producer doesn’t care about mechanisms, or the novelty of ideas. It’s that they want these ideas framed in a way that they only excite the customer, bring a smile to their face, and lead to positive sentiment. It’s a different perspective, arguably the development side of things, but terribly useful.
Focus on the experience. Designers can often have a bad habit of the method by which an experience will be delivered. The steps of the mechanism, the journey from input tou output. The producer’s job is to focus on the end result. A good producer is always asking these questions:
- What is the result you desire?
- Is there a better, simpler, more fun way to deliver this result?
A key tactic is to offer solutions to achieve this. Often, designers will be entrenched in their thoughts. They don’t want to kill their babies, which is one of the jobs of a producer. A way to start the process and to generate good brainstorming is to offer solutions and alternatives. I suggested this recently with a friend’s prototype.
He had a dice-based combat resolution mechanic. He also had numerous status effects, like you often see in RPGs. Slow, stunned, poison, webbed, and so forth. I found it very cumbersome to juggle between remembering the effects of the tokens littering my board and what dice to roll. I suggested: what if when I get the effect, I get a die that represents it? For example, if I’m stunned, I roll a d4, with lower numbers, to generate a worse result. Or, if using custom die, I get a new die with different faces. The end result was the same, but the journey was arguably simpler.
Remember point number one — you do not need to have the answer. You need to find the person that does. Think of yourself as an editor reading a great story. You love the characters, you love the ending, but the in between is a bit muddy and lacks punch. Offer ways to tighten that up, get the writer/designer thinking, and watch them surprise you with a superior solution.
Communicate. I find this to be one of my greatest annoyances with tabletop publishers. The industry is plagued by months without contact, obtuse responses, and talking to a wall. I think this is unacceptable and, if you care about it, relatively easy to fix. But, I digress.
Good communication is simple and follows a few clear rules.
- Be clear with expectations. There must be precision in what you expect. If you want creative solutions, be clear that that is also allowed. When you waste other people’s time, such as artists, be prepared to compensate them.
- Be clear with due dates. I want X, with these specifications, by this date.
- Share with everyone what these are. If possible always use face to face communication to discuss these items. Then, follow up in writing so everyone has a thing to reference.
- Be concise. Stop wasting everyone’s time. The more you write, the less it’ll be read. Furthermore, the more opportunities you present to be confused or misconstrued.
At the end of the day, talk to your team. Be honest, be precise, be concise, and don’t let issues fester.
Stop by to check in and see what’s going on. This is more applicable to a physical development team, but also applies to a remote team. This sounds nuts, but act in a way that you fear is annoying. At work, I frequently stop by the desk of an animator, modeler, other producers, whatever, just to say hi, ask what they’re up to, and see if I can help at all. These are anywhere from 15 seconds to 10 minutes. It builds rapport, gives me insight into their day to day, and sometimes, I find issues that I can help prevent before they spin out of control.
If you’re a board game publisher working with remote developers, such as a graphic designer, design partner, or illustrator, get their IM client and name. Every now and then, pop in. Ask them how things are going, if they need help, or ask if you can see what they’re working on. Be a curious fan of what they’re doing, not a tedious micro-manager.
Don’t be afraid to ask what you’re team’s up to. You’re paying them! You’re the customer! Go make friends and ask!
I asked Twitter for questions. Here is the answer to the one I received!
How different is video game design from board game design? - @deadlyaccurate
The short answer is, more different (currently) than it should be. In my opinion, one of the top problems plaguing game design, and arguably one of the reasons you see such an influx of brilliant, simple indie games, and a flourishing mobile market, is that many digital games have become far too complex. Simply because one CAN affix a series of calculations to a digital game mechanism does not mean one should do so.
The result, most often, is that there is so much going on under the hood that a player cannot make an intelligent decision regarding their action. If the outcome isn’t fully understood, in many cases, it could be random. Oblivion, the predecessor to the brilliant Fallout 3 and Skyrim, had one of the most obtuse leveling systems I’ve ever seen in a game. It was so complex that me and many others had to make obscure decisions to ensure we could keep up with the game’s difficulty curve.
Board game designers, unless you’re a terrible one, constrain the amount of calculation and computation required. After all, players must do it themselves while also trying to have fun. As board games are largely component driven (cards versus dice versus miniatures), decisions about user interface are very core to the experience. I think mobile design has improved this, as mobile games are so driven by the quality of their interface, but it’s something all digital designers should keep in mind.
The biggest difference, which won’t change, is the scale of the operation and timing. A board game company can be quite successful with 1 or 2 full time employees and contractors for a variety of things, including illustration, graphic design, testing, and manufacturing. Yes, there are indie developers who do everything, but it’s rare to find someone who can do quality 3D animation, 3D modeling, illustration, coding, engine development, online coding, web coding, tuning, writing, and more.
It’s also much faster, typically, to iterate on a board game. Now, this differs wildly by platform. It might take weeks or months to implement a system in The Sims on PC. On mobile, we could implement changes in an hour. The biggest issue is 2D versus 3D (in many cases), as well as offline versus online. Those elements can exponentially change the workload per feature. With a board game, a 100 card deck is quick to modify. A 500 card deck with all unique cards? Or having a pile of tokens? It’ll take longer.