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?
Industry:
- steady paycheck.
- learn from others around you.
- see aspects of the game industry outside of your discipline.
Indie:
- 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

Just a quick update on my latest thoughts on REMA. Reflecting more on Daniel Pink’s work (initial thoughts) and a recent blog post on gamasutra, it’s become clear to me that REMA stages might better be represented as e Purpose, Autonomy, Mastery stages, followed by a Sharing or Artistry stage. I’ve already talked a great deal about Rollercoaster and Purpose, and Mastery is an obvious link. But the connection between Autonomy and Experiment games has really been driven home to me lately, particularly looking at how games like Skyrim and Minecraft are enjoyed. “Freedom” and “Creative” are the words at the core of this play, strongly linking them to Autonomy.

I’ve also been thinking about Civ. The importance of Management play was driven home in the BrainHex 2 studies, and Civ clearly fits in that category. And while there is some Mastery appeal, from what I know the primary appeal of Civ is the freedom and autonomy aspects – build an empire that’s your version of history. Most players play only once, and play on low difficulties where they are going to stomp the AI, rather then engaging in the available multiplayer play. In fact, Civ is a great example of the conflict between Autonomy and Mastery, as for years Firaxis has maintained the Mastery side of the game, despite the continued challenges of it, such as the unsatisfying victory conditions. Stealing “losing is fun” from Dwarf Fortress would probably greatly enhance the series for the main audience, but they’d lose the Mastery group that is their most devoted.

So I’ve been confident Management gamers belong in the autonomy/experiment group – they want to do things their way, they want options to chose from, succeed at implementing them, and have extra long sessions of progress (what I think of as “cascading plans”, which is a key Experiment game reward that drives the “1 more turn” feeling and deserves its own post). Note here its not creativity linking Experiment games, it’s Autonomy.

Putting all that together, I’ve decided to focus on Purpose, Mastery, and Autonomy by naming REMA to PAME. Daniel Pink’s work is widely read, backed by applicable and interesting research, and his words are more descriptive and have broader context. I renamed Application to Expression, which I think is also clearer, and now has better alliteration.

What’s your thoughts on this? Curious how people have been using REMA in the year since I posted it and whether these changes are helpful.

The REMA Model: The Mario Conundrum con.

Aside

It might be tricky to classify Mario as one REMA genre, but Super Mario Land 3D designers definitely used REMA as the core of their design vision:

But it wasn’t really until Super Mario 3D Land that I think I really became a lot more rigorous about enforcing that in level design, where you have a clear concept in the beginning, and that’s carried through absolutely all the way.

Why do you think that that’s important?

KH: Well, I think it has a lot to do with the acquisition of a skill, which is something that often appears very similar to the way that a narrative can develop. So, if you take a single gameplay element, let’s think about the steps that happen.

First, you have to learn how to use that gameplay mechanic, and then the stage will offer you a slightly more complicated scenario in which you have to use it. And then the next step is something crazy happens that makes you think about it in a way you weren’t expecting. And then you get to demonstrate, finally, what sort of mastery you’ve gained over it.

It’s very similar to a narrative structure that you find in four-panel comics… And this is something that ends up giving the player a kind of narrative structure that they can relate to within a single level about how they’re using a game mechanic.

The reference to manga narrative using similar form is fascinating,  It hints at a deeper connection between Rollercoaster play and Mastery play.

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).

Enjoy!

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.

Enjoy.

The REMA Model part 7: Application games

We’ve explored Rollercoaster learning, Experiment learning, and Mastery learning.  Finally, the last phase of the REMA learning sequence:  Application.

If REMA is a learning sequence, the first 3 phases are like the trunk of a tree, and Application is the branching out of that experience into player’s lives.  Application is the stage where players take what they’ve gotten from a game and apply it to outside contexts.  Where they use what they’ve learned, and share what they’ve gained. Where the output of the play becomes something to reflect and admire.  In a sense, once mastered, the play becomes performance to be shared.

Sometimes it’s literal performance, such as in social performance (Club Penguin) or comedy improv (Fiasco) or dance (DDR).  Other times it’s performance towards an end result, such as in art (Spore’s creature creator), education games in schools (SimCity, Oregon Trail), health (Superbetter), or stories (Alice and Kev in the Sims 3).  Application plau is play that deliberately use the play process to change people’s lives afterwards.

The design of this play is interesting, because this play is generative.  Designers are manipulating familiar kinds of plays to create surprising outputs.  It can be a masterwork of subtle manipulation of the other phases (Braid, Bioshock).  These games seem to me to be artistic goals of Rollercoaster, Experiment, or Mastery games, and better analyzed in that context.  (Often the Application play in these games was not intended!)  However, Application play designers are also exploring a new form of games altogether (World Without Oil).  These seem to be Application games.

Application games are still rare, and instances of Application play are far more common then games built for that purpose.  I’m not an expert in this area, so there could be a good deal more going on then I’m unaware of.  That said, the relative youth of Application games combined with the breadth of experiences means Application games don’t seem to share  traits as tightly as the other modes.  Only a few seem to have evolved so far:

  1. Shared External Goal.  The player(s) and the designer commit up front to create something, and work together to achieve it.  No jerks allowed.  (See the Narrativist paper RPGs.)
  2. Recognizable Output. Players have to be able to claim what is being created.
  3. Useful Output. Players have to be able to do something with it.
  4. Participant-Created Output. The players have an active role in shaping the output (otherwise, you don’t need the game part).
  5. Vague, Internal Success. Players need to be invested in parsing and promoting the output and declaring it finished.
  6. Tight Communities:  Performance needs an audience, and that combined with a valuable output leads to communities…
  7. Publication:  And “museum-like” repositories for the game’s output, often online.

Application game design is still young, and there’s much to discover.  But focused Application game designers are starting to appear.  The Serious Games and Narrativist Game movements are home to many of them, but others are light-hearted.  The advertising world is starting to take note, particularly in the non-profit sector.  The military is investing.  “Gameification” is a way of creating Application play in non-game contexts.  It remains to be seen whether Application games will evolve new game traits that evoke a new style of game, or whether they will focus on refining Rollercoaster, Experiment, and Mastery techniques for Application purposes.  But the unique pressures of performance create new possibilities.  I’d be curious if you’ve seen or heard of good examples that break the Rollercoaster/Experiment/Mastery game model.

So!  We’re through the REMA stages in detail.  Thanks for reading!  I hope its been enlightening.  We’ve seen how you can identify each play stage, some design traits that you can explore in each stage, and we’ve explored some of REMA’s shortcomings.  I have one more post planned on the relationships between the different traits.  But I’d also like to hear your take. Everyone seems to have a different perspective on it.  Please share!

The REMA Model part 6: The Mario Conundrum

Where does Super Mario Bros. go?

Let me tell you, in the REMA work Mario and similar games have been the biggest challenge so far for me.  Because REMA is based on a learning model and not a game design model, the categories aren’t defined by the games themselves.  It’s an interesting outcome that games seemed to have evolved to match these categories (likely a side effect of players being focused on only one mode at a time).  And it’s useful that these games have evolved unique traits that can help focus the design.

But Mario doesn’t fit.  Mario might be dismissable, because it was released well before most of the REMA traits had evolved.  But it’s an all-time favorite.  And there are plenty of other recent games that don’t fit well either.  Like Super Meat Boy.  And what about the Ninja Gaidens?  or Demon Souls?  The main design difference here from Rollercoaster games is just the difficulty.  But that difficulty forces the player to use Mastery-type play to proceed.  And player’s love it.

For any game, REMA classification is based on what is the primary focus of the player.  And the focus of the player’s play in these games 90% of the time is on perfecting a skill – Mastery play.  For the REMA model to be coherent, these are Mastery games.

But these games don’t share the traits I described for Mastery games.  They don’t have one room, they are a journey.  The structure is content driven and external.  They’ll often introduce new tools along the way that force you to restart the REMA learning process.  What gives?

I think there must be 2 kinds of Mastery games, each with a different lineage.  Mario is the kind of single-player Mastery game where designers create a series of difficult tests for players to beat.  By amping the difficulty, video game designers discovered they could create a different kind of Mastery experience from the historical, competitive Mastery game.  These games have very different traits from the historical games, from different evolutionary pressures:

  1. One Time Through Yes, you might play the levels over and over, and you might come back to 100% something, but these are linear games.
  2. Long:  And, like Rollercoaster games, to justify their value, they have lots of puzzles/levels.
  3. High Challenge:  Challenge promotes quick mastery.  These are often difficult cognitive (puzzles) or physical challenges.
  4. Punishment:  As does punishment.  These 2 are the key traits that separate these games from Rollercoaster games.
  5. Little Randomness:  A trait Mastery and Rollercoaster games share.
  6. Scripted:  The “beat it once” mentality encourages one-time construction techniques.
  7. Skill Driven: Progress is defined by tests of whether a player has mastered a particular skill or concept.  Unlike other Mastery games, the same test isn’t repeated twice.
  8. Direction:  These games are not one room games.  They are a journey, the player beating one test at a time.
  9. Content Driven:  The tests are a form of content.  Development is usually centered on content creation.
  10. Content Defined Stopping Point:  And when you run out of tests, you’re usually done.
  11. Varied, External Success:  The designer crafts the tests and the player overcomes them.
  12. Narrative:  Story serves as an excellent reward and frame outside the tests.
  13. Contextual:  The scenes and narrative often assist in the tests and slightly modify the systems, in order to vary and explore the scripted system space.

You’ll notice that nearly all of these traits are Rollercoaster traits too, except for the ones about difficulty.  And Rollercoaster designers have realized this too – most Rollercoaster games have an “Insane” difficulty mode that creates Mastery play.  Halo on Legendary is a completely different game then Halo on Normal.  The player’s goals and play are different.

This complicates things.  This makes 2 distinct groups of Mastery games, one of which is fairly close to Rollercoaster games.  And it opens up the possibility that there could be similar evolutionary splits in the other play modes.  We’ll see how it develops.  Do you think this is the right way to take the model?  Are there other groups I’m also missing?

In the meantime, I could use names for these 2 groups of games.  Ideas?

The REMA Model part 5 con: Mastered

One interesting type of play within Mastery play and Mastery games is that players aren’t always trying to improve themselves.  Sometimes players like to enjoy the mastery they already have, or enjoy the game’s explicit reward structure.  Doing their gathering rounds in WoW.  Beating new players in Dota.  Doing another round of Solitaire just for the enjoyment of it.  Players often just enjoy displaying expertise in Mastery games, only discovering something new and getting slightly better in a way that feels coincidental.

I think of this “Mastered” play as part of the core of Mastery play.  Often, our intrinsic enjoyment of something we’ve mastered is a big part of why we keep doing it.  Mastered play shares the design traits that Mastery play has, but it’s definitely a subgenre of Mastery play that has value (enjoyment) and pitfalls (grinding) of its own.

The core thing that separates broad Mastery and Mastered play is a player’s indulgence in rewards in Mastered play.  The REMA Model is learning focused, and doesn’t closely consider rewards and motivations from rewards.  REMA is just one perspective, and rewards design is another.  Rewards drive engagement and provide feedback in a way that is very useful for games.  REMA, for example, definitely exists on the different reward time slices we typically use (1 second, 5 seconds, 1 minute, …1 hour, 1 day, etc).  But REMA on the 1 second scale is not very enlightening: nearly all 1 second play is Mastery.  Reward design, however, is crucial on the 1 second level.