Paint It Back: Interview with Ed Brown

Paint It Back, a nonogram puzzle game, was released for the iOS this week.  It’s been my go-to game since, bringing back delightful memories of Picross.  The starting 30 puzzles are free.  The remaining 110 puzzles are only $2.99 (which is insane given what I paid for Picross 5-odd years ago).  It’s worth checking out.

The designer, Ed Brown, is an old friend from when he used to work at Popcap, and I had some questions about the game’s development.  I asked him if it was ok to share his responses with you, and he said yes, so I threw in a couple more questions for background, and here you go:

What inspired you to make Paint it Back?
The release of the iPad and my wanting to play Picross DS on it.  
How long did it take?
Pretty much three years.  But two side projects that took three or four months each and a few periods of sloth account for some of that time.  
Who worked on it?
I worked on it by myself up until it was time to add characters to the game.  I wasn’t liking what I was coming up with so I looked for a local artist here in St. Louis and found Jeff Weigel.  He drew the characters, the paintings in the ghost scene, the ghost, other stuff. 
What engine did you use?
Cocos-2D for iPhone.
What was the hardest part of transitioning to iOS from PC?
Probably learning objective-c.  It takes me a while to get comfortable in a new language.
Where can people find it?
Apple App Store.  [Here – Ed]
The images are quite varied and funny, but also quite limited in fidelity.  How did you come up with images?
There wasn’t one single overriding approach that I used, other than to draw them on an iPad using a pixel-art app called “Edge Touch.”  Sometimes I’d start with the title and then try to come up with a fitting image.  “Deer Tick Flying First Class” was one like that.  Others were finished scenes that needed punching up.  “Mugged While Tightrope Walking” was originally just a guy tightrope walking.  Some started from drawing random shapes and trying to see something in them.  A lot of the smaller paintings came from this method. 
Who did the art?  Both painting and scenes.
Jeff did most of the stuff that looks like a real illustrator did it – characters, paintings in the ghost scene, other stuff.  I did all of the puzzle paintings, ui, effects, animations.  A lot of stuff we worked on together, so it’s hard to say who actually did it.
How long did it take?  When did you start in earnest?
The whole game was 2 – 2 1/2 years of actually working on it most every day.  The time to create a single painting could take between 10 minutes or 10 hours. Some were a real pain to playtest and revise down to only one solution.  I’m looking at you, “Crazy Stairs.”  I made the majority of the paintings during the evening while hanging out on the couch watching tv.  That period stretched over several months.
How did you decide on the size for a painting?
That was dictated by the painting itself.  I found early on that trying to force an image to fit into a standard nonogram puzzle size like 10×10 didn’t always make for the best looking painting.  I decided to support strange grid sizes like 16×20 or 24×32 because a painting would just wind up looking right at that resolution.  If I liked how a painting turned out, I’d have to add support for that grid-size.  There’s paintings in the game that are the only ones at that particular resolution.  
How did you figure out what order to put the paintings in?  How did you figure out what was hard/easy?
I originally made around 75 paintings without thinking about where they would live in the game.  At some point I was looking them over and realized I could group some of them together by common themes in their titles.  The rooms came out of this.  After that I created paintings for specific rooms.
Determining the difficulty of a painting was just play testing the drawn image.  If it was unsolvable without guessing, I’d alter it and re-test it until it was solvable.  
How did you approach naming the paintings?
No single approach.  Although every painting title had to at least be intriguing. 
Who did the music?  It’s very catchy.
Coda.  I decided to use tracker music, looked around the net for a music person, and found Coda’s extensive backlog of songs.  I picked out a few I liked and Pay-Pal’d him the licensing money. 
Why the 2 modal buttons for paint and block?  How did you arrive at that solution?
Up until two weeks ago it wasn’t modal.  More than one beta tester suggested it to be modal, so I tried it out and I thought it was an improvement.  A user was complaining of accidentally painting squares because of fat fingers.  This helped to cut down on that.
[I’d recommend trying some of the puzzles without using the block tool, for extra challenge.  I find it kicks the mental gears an extra notch.  -Ed]
How much testing did you do, and when?
I started having people test it around a year before it came out.  The tutorial went through -many- iterations.  At first it was 17 paintings – and people complain about the 7 paintings in the current tutorial being too long!
Why does the game support device rotation, but only after the first few levels?
The tutorial room doesn’t support rotation.  I took the lazy way out there.  It has to do with the way I handle the recreating the scene when you rotate.  The artist’s dialogue complicated matters.
Why did you do Paint it Back over other concepts?  What’s the story of how you knew PiB would be what you shipped next?
A lot of reasons:
– It was a project I could handle largely by myself.  
– I liked making the paintings.
– There seemed to me to be an opening in the App Store for a quality nonogram game.
– It was a game I would want to play if I wasn’t making it.
– The theme of “museum art” seemed like new territory to explore in a game.
The project just felt right to work on.
What do you hope players take away from the game?
Mild amusement and satisfaction.
Having done both indie and industry, what are the highlights of each?
– steady paycheck.
– learn from others around you.
– see aspects of the game industry outside of your discipline.
– you can’t beat working on your own ideas.
– non-standard work schedule, if you want.
– you own all of the assets.
And what are you planning next?
No specific plans – totally depends on the reception to PiB.  If it goes well, I’d definitely  consider making more paintings.  If there was a scene of people making their own paintings, I’d ask people to submit them to me and I’d pick my faves, group them into a room, call it “Outsider Art” and release it as a free in-app-purchase.
I’ve got a backlog of game ideas I’d like to prototype.  I’ll probably pick one and start tinkering.  Or maybe I’ll do absolutely nothing for a while.  That sounds good, too.

1, 3, 8, 25, 50, 100, ?

I’m going to throw out another hypothesis here:

I claim there are Team Size Ranks, numbers which are the average thresholds at which group dynamics fundamentally alter by orders of magnitude.  It’s well known that communication because more difficult as you add people to a team because there are NxN communication paths in any group.  It’s sort of roughly understood that things seem to roughly change too at certain thresholds – at some point you need a team manager, etc.  What’s less understood is that there are key trip points where teams need to explicitly morph into something new or they will thrash and suffer.  I claim these trip points are roughly at sizes greater then 3, 8, 25, 50 and 100.

In my experience, these thresholds radically alter the roles on the team.  If you go up a level, all of a sudden, everyone has a different job.  Being a producer means a different thing then before, being a lead means a different thing then before, being a designer means interfacing with X more people, even being a coder is different!  A “lead” of 8 can still write or design whole systems.  They can lead by example.  A “lead” of 25 can’t afford that any more.  They don’t have time.  A “lead” of 50 probably can’t remember everyone’s name, let alone delegate, and probably needs “sub-leads”.  And most of the time people aren’t trained or ready for that switch.   Their identity is still caught up in the “lead” of 8, and they’ll fight to preserve that.  Identity is the hardest thing for people to change.  It’s what they wanted!  It’s why they took this job!  It’s their calling!

As teams grow, individuals become partnerships, then tribes, then tribes of tribes, then tribes of tribes of tribes.  And each requires a radically different kind of management.  With 100 people, producers have to be very careful with their impact, because the 100×100 matrix means their input will propagate far.  At their best, producers shield and stop problems before they even hit the 100 person level – limiting them to a smaller scale.

I’m very aware of this dynamic on teams.  These numbers are scary to me.  Very scary.  Teams make great games.  And breaking these size barriers seems to be the biggest threat to them.  Like throwing them into a giant whirlpool they may never come out of.  It’s extraordinarily dangerous to throw 50 people on a team, even if they were a team before, because you jump a size barrier here.  All of sudden, every person on that team is trying to understand a new role, something that can take a year or more to stabilize again, often with high attrition.

In fact, I’ll claim people can only go up (or down) 2 levels comfortably, and then start to really flounder beyond that.  At that point, it stops being the job they wanted, and they’ll want to retrain or change jobs.

Some other interesting side effects:

As you go up, relationships require different skills and more specific compartmentalization.  Each individual has to be more specialized, more focused, on a 100 person team.  It’s much harder to be a generalist.  You can’t want to touch everything – it requires too many communications to do that.

As a consequence, people (and work) done best with cross-discipline Face to Face interaction are happiest with small teams, and vice versa.  Agile can help here, but you’re always sacrificing communications somewhere for the sake of others.

As you go up in size ranks, relationships become less human.  Face to Face is a 3, maybe 7 person thing.  Doesn’t work anywhere near as well with 100 people.  This can be really disconcerting for people, particularly if they were used to solving problems on a smaller team.  In 100 person teams, decisions start to become very impersonal, because they have to.  The nature of the information management requires abstracting it out.  Yet if you’re used to dealing with things directly, this can be very confusing.

I don’t know what’s the next ranks are.  I’m pretty sure there’s more steps, starting around 200.  Large corporations have thousands of employees and exhibit all the characteristics of large scale, yet even more extreme.  My guess is there’s some empirical pattern here, but I haven’t been able to derive it on my own.

Maslow’s Tribal Hierarchy

Reading my usual deluge of ideas, I came across an old one:  Maslow’s Hierarchy of Needs.

What struck me about it this time though was how closely the Hierarchy mirrored the Tribal Stages (TED) of the Tribal Leadership research:

  1. Stage One, or basic animal survival, seen through gangs and prisons
  2. Stage Two, or security of employment, seen through rejection of leadership and a culture of fear.
  3. Stage Three, self-empowerment, seen through a culture of rock stars
  4. Stage Four, and the top level of the hierarchy: creativity, acceptance of fact, seen in a team depending on each other for success.

Interestingly, Stage Five matches the top level of Maslow’s hierarchy as well – companies and teams working for the good of humanity.  In fact, it seems to match the top level better then Stage Four does, although otherwise the comparison holds.  Maybe there’s another layer to the triangle, one around social needs and good of the local community?

Regardless, I found the connection intriguing.

Management: Helping people work

I find people get confused about what management means.  There’s nothing worse then floundering around on a team and not being sure whose supposed to do something.  Sometimes you think you need the help of  “management”, but can’t tell someone where to come in and where to butt out.  To paraphrase the Peopleware guys, management is about helping people work.  Anything that helps people work that isn’t the work itself  is management.

In practice, this means the goals of a manager are:

  • Get everyone able to solve their problems
  • Keep everything the same as much as possible

Notice that I didn’t say help people solve their problems.  That’s more like doing the work.  Making it so that the problems can be solved is very different.  Continuity, ritual, keeping everything the same as long as you accomplish the first goal is very important too, because it provides an inherent structure and culture that people can make assumptions about and depend on.  That’s why it’s so hard to make big changes like switching over to Agile.  But if Agile can accomplish those 2 things in the long run then it’s worth it.

Of course, that first one’s a really doozey.  The first issue is just seeing the things that will really help someone else is hard.  Frequently, the easiest way to do that is to get distance and perspective from the work, which is why I try and put aside the work when I’m trying to manage and help from afar.  But once you see the problems, I frequently don’t know where to start.  After chasing these problems down for several years, I’ve discovered they are usually caused by larger feedback loops.  Feedback loops driven by common problems shared by teams everywhere.  I’ve noticed there are 3 principle that cover it all.  To break these feedback loops and get people solving their problems all you need, in priority order, is:

  • Priorities
  • Laser-like Focus
  • Morale

Priorities is about having a hyper-clear direction, an accurate, communicated, up-to-date goals list, with everybody on the same page.  All known questions accounted for and able to be set aside until answerable.  Laser-like Focus is about taking each of those priorities, in order, one at a time, and knocking them out of the park.  I’m talking, serious, no distractions, no bumps Focus here, full stop.  Morale is about making sure that people are happy, the team is satisfied, in control and driving their work so that they can relax, support each other, and bring their best work to the table.

It’s really seems that simple.  I can’t say it’s the best solution, or that it will solve everything, but each time teams get a handle on these goals things just seem to magically come together.  Each principle supports the others, jelled teams form and stop asking questions, grabbing at random tasks, and instead start knocking work out of the park.  Take a look at this comment thread of stalled Interactive Fiction projects.  One-person teams, all running into this same set of 3 problems.  Look at Getting Things Done, which proposes a system to target these exact same goals.  Hitting those 3 principle while staying consistent and working inside the classic 3 business constraints of time, money, and quality just seems to be the formula for success.  I use these every day even in my personal life, and it has not only helped me get things done, it has also helped me figure out where I’ve gone wrong.  But for a bigger team it takes full-time dedicated people, hard day-after-day work to actually shape these up.  True managers, not just leads or producers, who consistently prioritize, focus, and love fixing this problem – helping people work.

Making Games: Programmers

Why does having a programmer in charge of your company make such a big difference?

I’ve been at a number of companies over the years, and there’s always a marked difference between the companies run and founded by programmers and those that aren’t.  I hear it from other programmers too.  I’m not sure why, but at a programmer-led company programming tends to seem, well, better grounded.  Relaxed.  Expected, maybe.  Every time we compare process notes, it shares one common thread.  Not Agile.  Not size.  Programmers who made the ultimate call.

You see this translate to the marketplace too.  Will Wright?  Programmer.  Valve?  Gabe was a programmer.  Blizzard?  Yep, programmers.  Looking Glass?  The whole company only believed in programmers.  EA and Activision?  Early years – founded by programmers.  Bioware, Firaxis, programmers, programmers.  These people who run companies, they all share a common hands-on background.  Even Scrum – comes from programmers.  When you take a step back, the list is staggering.  Sure, many of these people have also become designers – something I haven’t missed, trust me.  But their starting place seems too remarkable to go uncommented.  It’s not complete – there are large teams in particular who have had success, usually led by producers with a tight team of leads.  But the commercial industry seems dominated by either small-ish teams of the former or ginormous money-sucking teams of the latter.

I’m not implying causation, just correlation here.  Trying to guess, having a programmer in charge means there’s no black box.  Video games are software first, game second.  Programmers have to understand that at their core.  It’s this hard truth that has so far made design so difficult.  If you can understand what the software takes, if you can get hands on in what you have, if you’ve done it yourself in the same code base, there’s a level of understanding that comes with that.  If you can’t, it seems more likely you’ll focus on the game part first – usually the design.  You can end up underappreciating that whole engine part, relying on others to just meet your design goals.  I wish it was always that simple though.  At some point, risk or difficulty becomes high, hard choices have to be made, priorities have to be set.  And it seems like in those times history seems to show the programmer-leaders react better.  They’re better informed or better prepared.  Software first means things about priorities, means things about workflow, ultimately means things about culture, that even today it seems you need to understand making software to truly understand the craft of making games.

Of course, I’m probably biased.


I’ve been reading the IDGA Quality of Life White Paper and trying to write about crunch.  And I’ve been finding it terribly difficult.  Not because understanding the role and effect of overtime is difficult, but because talking about it publically is.

There’s this implied threat that if you don’t fully support the company’s interests in voluntary and involuntary overtime, they won’t hire you.  But the company’s interests are gray.  Frequently crunch makes a project worse, but sometimes makes it better.  The morale and health of the people at the studio are in the company’s interest, but the best judges of how to serve that interest are the employees themselves.  Sometimes even a team wants to work overtime and management stops them.  And yet, talking about crunch and overtime in a reasoned, rational way as a potential employee, even from the company’s interest alone, is seen as a threat.  To me it just seems like a step – a step both towards better employee quality of life and a step towards more successful projects and more successful companies.  I believe the single greatest factor in a game’s success is the team’s drive to create a great game.  And the second greatest factor is their happiness and amount of stress.  Anything we can do to manage and improve these two factors is a tool that we should use wisely and well, and a tool we should fully understand.  Not a tool we should put on an alter behind a curtain and strike down any who question it.  Questioning is part of understanding – if there are no questions there is no discussion, and with no discussion there is only blind ritual.

So read the white paper.  While not perfect, it goes over these things far better then I can.  And encourage your teams to talk about crunch openly.  Work to ambush potential hires in employment agreement about crunch, but rather to talk about it respectfully in the interview.  So that when the time hits, your team will be right there with you, best they can.  Or maybe, just maybe, you’ll find a way to avoid crunch altogether.

Game Development: Time

I was reminded this week how important a role time plays in everything we develop, and how technology is shrinking it.  It’s easy to miss it in the day-to-day, but most of what we struggle with, the miscommunications we have, the problems we tackle, are ultimately just an f(t) where t is really long, too long for us to not need help.  Pathfinding and UI and game programming is hard not because it’s hard, but because it takes enough work to get it right, enough time, even if you can point to the answer when you start.  Design docs are just a way of pointing at a result (even if they’re ultimately inaccurate), because just making the result takes far too much time in concept, and the designer never has the time to do it all themselves.  Prototyping is just another step on that path, an evolutionary time-saving improvement enabled by technology – it’s a fast way of getting something more helpful done, but still what you actually want is something else.  Meeting notes may be tedious to post, but they save time communicating (and rehashing) the imperfect discussions.  All these tedious problems go away if you have infinite time, or perfect technology.  It’s easy to forget that – to say “don’t ever write design docs” or “cancel all the meetings!” – because in a sense they are a waste of time.  But they are occasionally a necessary waste of time, and not a waste at all, because what you are really doing is steps towards solving a long, hard, complex problem like making a game.  A problem that brings people together and gives us work.

We don’t have the technology to make that easy yet.  Someday.

flower: credits

There’s one sadness about flower for me – the credits.  Why does it take so many developers to make such a simple idea?  Huge!  I can’t find the complete list, but the credits feels like 100 people, including tons of support and publishing personnel as well.  The credits level of flower (fantastic!) feels far too long, like somehow the credits list wasn’t designed properly.

It’s not a simple game, by any means.  Fantastic polish.   And I know (from experience!) how much work such titles take these days.  But that doesn’t mean we should accept it.  flower is a simple idea, and should require straightforward execution.   Compare it to Jenova Chen’s first work, Cloud.  Cloud was done by one person, Jenova himself..  And yet it incorporates a similar aesthetic and ideas.  Flash forward to consoles 5 years later and flower takes a full team.

It’s not surprising, but it makes me sad.  What will it take for games this good to be simple to make again?  When the auteur can be the author again?

(Edit:  Check out Michael and CrashT in the comments who gave some hard team numbers that seem inspiring)


In the commercial game industry on the inside most big projects are Art-driven.  This is rather surprising – most developers would say they want to be Design-driven.  Small teams like indies seem to be Design-driven, like Braid or World of Goo, but less often Art driven, like Tales of Tales.  But in my experience most big projects seem to get caught up in the art.  I’ll never forget my interview at Blizzard North years ago.  I asked them which department they thought drove development, expecting them to say Design.  Blizzard is known for having some of the best designed games in the industry, so it seemed clear.  But the interviwer said if anything they were Art-driven.  When I expressed my surprise, he couldn’t help laughing at my shock.  Design-driven was almost a foreign concept.  When I asked the same question to Blizzard South, with a more defined Design culture, they still emphasized their Art.  I’ve heard of this time and time again.


If we all want to be directed by Design, if smaller projects are Design-driven, why are big game projects different?

  • Art departments are usually double or triple the size of the other departments.  Environment art in particular is usually the limiting factor in why many games can or can’t ship, justifying larger teams.
  • Art departments usually have some of the best tools.  Maya is state of the art, and additional effort is spent to improve art tools to increase efficiency and reduce level production time.  Conversely, there’s not even a common consensus for what standard system design tools are, and most teams have few or no systems tools, limiting what design can create and explore.
  • Art gets a bigger reaction.  Audiences love high quality art, whereas it’s extremely difficult to convey large-scale game designs in a demo, particularly to executives.  Thus every game has to deliver high quality art early, but design is rarely a requirement.
  • Art is well researched.  Every school has an art department.  It’s an established field with easy reference and intuition.  Game design is still relatively new, the details of dynamics are poorly appreciated, and playtesting is still rare.
  • Because Art has more people, better tools, and is easier to promote, it can create definitive prototypes more easily then design.  This allows them to more quickly shape the game’s vision.

I do strongly believe art is important.  Critical.  In fact, I believe that art plays an under appreciated role in inspiring and pushing system design.   But the processes game teams follow push Art past inspiring Design and into driving it.  Art is “easier” to see, and that naturally drives it to the forefront, creating a feedback loop.  In part, I think this is why we see unproven game designs even at the end of the project, designs that just aren’t fun.  Games that all feel the same but look incredible, and just get sold back within a week.   And Design takes the blame and gets even less respect.  Nobody on the team wants that, including the artists and the designers.  How can we help Design?  How can we all break the loop and bring the balance back?

Maybe we can wait on art even longer, recognizing they can shine when called on, focusing on smaller early art departments who work primarily on pipeline and support until we’ve got a truly good game.  For that we’d also need people approving games based on design, not art, which I’ve requires rethinking the business side.  We could also create the Maya-equivalent for systems and level designers, so that they can actually iterate and prototype through their ideas.  And we could find a common design language and train people in it, so that developers and executives will recognize good design and demand to see it from their Design departments.  This is all happening, slowly.  We’ve heard many of these answers before, and the top development teams are already executing on these ideas.  What’s new is seeing the production loop that drives this to happen, and controlling that system to make sure it balances both approaches, rather then letting it control you.