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.

The REMA model: The PAME model






The REMA Model: The Mario Conundrum con.




Why do you think that that’s important?





The REMA Model: Collected Links

Here’s a list of all the REMA model articles published so far.  If you’re interested in this design lens, I recommend starting with part 1 and exploring these core posts:

And some related posts if you’re interested in more detail:

Interview: Andrew Doull on Procedural Games

I had the opportunity to interview Andrew Doull this week, Unangband developer, creator of the Procedural Content Generation Wiki, contributor to the podcast Roguelike Radio, and deep thinker.

We chatted about all things procedural: the role of narrative in procedural games, the impact of the indies, the problems with a Procedural Zelda, and how Roguelikes can teach us unique things about life.

Listen here:  Andrew Doull Interview (MP3).


Games covered includes:


Trait Inflections: Intrinsic and Extrinsic Motivation

I’ve been reading Daniel Pink’s book Drive, and thinking about intrinsic and extrinsic motivation.  In particular, Rollercoaster games rely heavily on carrot/stick motivation (extrinsic rewards and punishments), and Experiment and Mastery games more on Autonomy, Purpose, and Mastery (his tools to create intrinsic motivation).

This is really interesting, because it provides a clue as to why these genres have evolved the way they have.  Since Rollercoaster games rely heavily on rewards and punishments, they have to be short (extrinsic rewards don’t motivate for very long), and rely heavily on giving you new and exciting rewards (since you get acclimated to them quickly), which story is perfect for.  Story also gives you very strong Purpose, above the gameplay, which probably helps sustain play over hours despite the limited Autonomy and Mastery.  They are happy to add story even if though it usually hurts gameplay.

Meanwhile, Experiment and Mastery games have deep Autonomy and Mastery, and so need less of these extrinsic rewards to get players to heavily invest.  They don’t have to make hard choices between story and gameplay.  Gameplay alone is enough.

The REMA Model part 8: Uses in Game Design

Now that we’ve covered the basics, here’s some of the things in REMA that have made me a better designer.

A Common Lexicon

REMA gives us a common lexicon to talk about why some games are designed differently and play differently.  That’s a big deal on a dev team – often one designer wants to make an Experiment game and one wants to make a Rollercoaster game, and they just talk past each other.  Understanding REMA, these debates can be resolved.

Set Expectations

It is useful for players and critics too.  Players play different games. When expectations are wrong, confusion ensues.  If developers use REMA language to communicate genres with audiences, rather then the meaningless “Action”, “RPG”, or “Sandbox”, it matches the right audience to the right game, and players can happily embrace each genre’s uniqueness.

Stay Focused

Once you know what genre you’re in, it’s much easier to understand what’s inside and outside your game.  The traits serve as a guideline to what has worked and what hasn’t, and give insight into how the audience thinks. This can be particularly helpful for developers who are new to their genre, and need something to relate to.

Find Inspiration

REMA can also help you find useful game references.  If you’re making a competitive multiplayer game, you already knew to look at Starcraft and Counter-strike and Chess.  But you might not think to explore Minesweeper or 7 Wonders or Demon Souls.

Predict Risks

The traits create powerful trait dynamics, areas where each traits has evolved to be different between the modes.  For example:

  • Choices:  Rollercoaster and Mastery games have few choices, but Experiment games have tons.  And the choices change nature and get more complex as you walk from R to E to M to A.
  • Length: Rollercoaster games are short, Experiment games are long, and Mastery games are extremely short.
  • Replayability: Rollercoaster games are played once, Experiment games 2-3 times, and Mastery and Application games over and over and over.
  • World Size:  Most often, Rollercoaster games are journeys, Experiment games are sandboxes, and Mastery games are arenas.
  • Goals: Rollercoaster games and Mastery games have designer-specified end goals, and Experiment games and Application games have player-specified end goals.

You’ll see these dynamics throughout the traits I identified.  Study why they exist.  They are the most powerful part of the whole REMA model.  Pay special attention to games that successfully manipulate or break them.  Understanding these trait dynamics is key to making a good design.  If you make a Mastery game that’s a journey, you’re in risky country, so try and nail that part of the design early.

Improve the Experience

Most games are going to have parts that are Rollercoaster, parts that are Experiment, and parts that are Mastery.  It adds depth and variety to the game.  Identify these places and guide the player through the transition between them – setting the tone, changing the mood, providing rewards.  Otherwise, you’ll leave players frustrated.

In more procedural games, layer the different parts of REMA play at different time scales (eg 1 minute, 15 minutes, 1 hour).  Make these secondary REMA modes infrequent, easy, and optional. For examples, look at the cutscenes and loot game in Diablo 2, or the battles in the Total War series, or the town/wilderness/boss timing in Pokemon.  The larger arc of Diablo 2 (Normal/Nightmare/Hell) and Pokemon (Journey/”Catch them All”/Arena Fights) both brilliantly encourage R->E->M transitions over hundreds of hours.

REMA also helps predict when you might need more of one particular mode.  For example, many Mastery games lack any safe space to Experiment, which means many players fail to transition to Mastery play.  One of the my favorite features of Starcraft 2, the Challenges, addresses this problem.  The Challenges were short puzzles that teach you a skill that you need to compete in the multiplayer game.  The Challenges gave players a safe space to Experiment with key parts of the game and then Master them, making the Mastery transition significantly easier in Starcraft 2 then Starcraft: Brood War.

Discover Designs

Once upon a time Metroid was an Experiment game.  What would a game look like that went back to those roots?  Or a game that combined Metroid’s Rollercoaster nature with Application play to make a metaphorical game about surviving cancer?  REMA teaches us a lot about how players learn, and by playing with the model and its traits, we can discover new directions that haven’t been fully explored.

Be Innovative

Break the rules.  REMA is a model, not a law.  Roguelikes broke the rules of Mastery games and created a game that was about mastering the average game, not an individual game.  Braid built a new sub-genre of Rollercoaster games by sending a message that could only be heard through play.  REMA predicts that you’ll lose some percentage of frustrated players when you break the model.  But no game is for everyone.  Most of the time when you do something new you frustrate 80% of players, but the other 20% become your biggest fans.  If you didn’t want everyone to begin with, that’s a great deal.