Designing for failure: Rapid, iterative prototyping for casual games

[Music] so hi thank you for coming everyone my name is Scott Chauncey GLE this is a talk about the design of games but it's also a talk about the design of development I've been working in the casual game space as a designer for the last nine years and during that time I've seen a lot of different prophecies in place I've designed and worked on games that have seen massive success games that haven't and games that never shipped and you learn a lot from being a part of success but I've come to find you actually learn a lot more being intimately involved in failure and maybe the most important thing I've learned is that failure is unavoidable but the trick to game development may be any creative process is to anticipate and plan for that failure and create for yourself the opportunity to learn from it and try again and learning from failure is actually a facet of many of my favorite games games create a space in which failure is not just permitted

but often a part of the mastery process games like super hexagon flappy bird or even triple-a titles like the dark souls series proficiency builds from successive failures into quote Jake the dog sucking at something is the first step to being sort of good at something but I don't think many companies today are designed to anticipate failure or even learn from it and my time in the social mobile casual free-to-play game industry has shown me that fear of failure often leads to a risk-averse strategy a notion that the safest way to avoid failure is to only do the things that are proven to work with companies that stick with these so-called fast follows or a perpetual risk of stagnation because the company is not built to try new things the industry is a hole over lies and what's established what's proven these best practices to try and guarantee that the thing they're making it's similar enough to the successful thing that someone else made and I don't think this is necessarily a sound strategy and I've watched companies spend years developing something safe only to have it ultimately underperform failing to pull audiences away from the multitude of

similar games in the App Store what's more the fallacy of sunk cost leads companies to double down on struggling development aggressive staffing mid production design pivot pulling resources from other projects pushing release to the next quarter or the next quarter always of throwing more and more money and time at a problem all in the name of avoiding failure well because we're an industry that focuses on what worked and not enough on what didn't or what it took to get to a thing that worked and the story of success is always a story about failure and just most folks only read the last chapter now we all know Kings asserted their reign over casual games with candy crush saga in 2012 but before they were king they were king calm a game portal with a litany of casual titles and a strong community whose metrics would help King determine which of their games to further develop and move to other platforms candy crush was actually the third game that King moved to Facebook and the first one they moved to mobile and others would follow but most didn't back in 2009

Rovio made their marketing casual games with Angry Birds but Rovio also shipped 51 other games for four Angry Birds and would have risked bankruptcy had the game not succeeded that same year PopCap ships plants versus zombies which win odds become a massive success with the leadership at PopCap at the time didn't expect plants vs. zombies to be successful it was too strange and unlike other things for them to believe it could capture a large enough audience regardless they gave a small team the time and space they needed to develop it and ship it knowing that the company would remain afloat even if the weird risky thing they tried didn't pan out even if PVC had been DOA haha PopCap would have moved on smoothly no worse for wear in all three of these cases failure plays a critical role success sometimes means getting it right on the 50 second try we're trying lots of low risk things before committing more resources to one bigger thing and success sometimes means creating the stability to try something weird and assuring that failure leads to learning rather than crisis now this is a talk

about prototyping for casual games but it's also a talk about redefining what failure means and how building and nurturing a culture of prototyping can allow companies to fail successfully and create the best environment for success to occur what I'm proposing is a system structure process for exploring failure early and often and because all good methods need name I'm calling this the four F method failing fast to find the fun thanks to Mitch Zamora who provided the clever name the process is primarily inspired by my time working in the pop labs prototyping group at PopCap together with a single engineer we developed four different prototypes iterating testing and deciding for ourselves when it was time to walk away from each and move on to the next thing the fourth of those prototypes tested extraordinarily well and was further developed by a team of 10 and soft-launched in Canada in 2015 though ultimately not successful I learned a lot from all of our prototypes and the lab as a whole and this process is a loop because we need to get it out of our heads that design exploration

prototyping development is a linear process an escalator leading to an inevitable shipped product when in fact it should be a series of circles and at any point in the process there needs to be consideration for whether it's time to loop back moving forward should never be the Assumption the escalator doesn't always lead somewhere good unlike my experience in pop labs for F is based around creative partnerships a designer and an engineer in close collaboration tackling problems together and I view this is a true equal partnership the engineer is not there simply to execute the designers grand vision the work produces a synthesis of both the creative and technical and like any relationship communication trust and mutual respect or critical depending on the prototypes need you may need an artist as a third or a second engineer but keeping the team small is important to ensure that everyone has a voice in the process while still maintaining cohesion and every time this team loops together they become better at the process and their working relationship improves and like any team the more experience they have working together the stronger their output and fourth can

give a team a lot of experience in a very short amount of time now Thor always begins in the box and from the box one or several ideas can come together to form a plan for a playable prototype that can be built in a short amount of time once built the prototype is tested with a variety of audiences and from there the team determines whether they want to iterate further on the current prototype or shelve it in favor of something else the box is where all of your neat ideas for games live and it's a critical part of 4s it limits the dependency on any one idea and allows those involved to constantly chew on the other ideas on the backs of their minds the Box encourages a playful approach to ideation that doesn't put too much pressure on any one thing to be the thing keeping the box filled allows you to more easily put down things that aren't working because a lot of stuff isn't going to work and it's also admission that some ideas aren't really fully cooked and they need time to percolate before they're ready to come out of the box now when I think about the concept of the box I I think a Pixar and how in a single lunch meeting back

in 1994 John Lasseter Andrew Stanton Pete docter and Joe Ranft generated the rough ideas that would become the studio's next four films and the ideas they generated weren't fully cooked but they were varying approaches to ideation rendering humans and CG was still a technical challenge so a bug's life was planned as a story devoid of people the secret lives of toys worked well for Toy Story so Monsters Inc was about the secret lives of the monsters under your bed Finding Nemo came from Andrew senton sympathy for the fish in his dentists aquarium and while he started with the character himself this idea of a sad robot left alone on a planet still doing the same menial tasks he'd been programmed to perform centuries earlier and in the same way what's in the box are incomplete prototypes or even fully formed ideas there are pieces of interaction or sources of inspiration open questions or clever solutions to constraints and limitations maybe it's a certain toy in the children's play area at IKEA the iPhone slide to interlock interaction leaving across rooftops in Saints Row 4 the idea of a casual Metroidvania bussing your own tables at restaurants

rock climbing goats tinder the box is there to constantly tickle your brain to be played with twisted around mashed together some things might bubble to the top a game mechanic will begin to form in your mind at that point you have to determine what to build and how you're going to build it and planning for a prototype is about determining the shortest path of something playable that prove the concept or hypotheses but the proof is not going to come from those familiar with its Genesis that proof has to come from actual players who have no idea what you're trying to do or the thinking behind what's in front of them and the problem with most prototyping I've seen in casual games is that the mota types are built for the developers themselves and sharing those prototypes with anyone other than their creators involves a lot of pre explanation and caveats what's more those prototypes rarely stands enough on their own to should be shown to people outside of the team or company and criticism of the prototype can often be explained away with oh we can clarify that with a tutorial or I probably didn't explain this well or well the visuals would make that part feel a lot more satisfying a

key part of this process is you're not building prototypes for yourselves you're building them for an actual audience and you want the feedback to focus as much as possible on the things you're trying to test rather than the rough edges this means that your prototype needs to stand on its own the entirety of what players are evaluating has to be contained within the game itself so when I say a prototype needs to be playable I also mean that it needs to be usable a playable prototype for a casual game does its job best if you can hand it to an uninitiated player watch them figure out how to play without needing to explain anything and witness they're honest and immediate reactions to the experience give a quick example so these are two versions or prototype that the developer Deki cost helps me build the mechanic is identical in both but the one on the left is lacking a cascade effect when cards are removed from the board making it unclear what happened to the selected cards and where the new cards come from the animation here is critical to the players understanding of how their interaction affects the environment the Cascade isn't polish it's actually integral to the product side doing its job at the

same time it's still important to turn the prototype around quickly and get it in front of players as soon as possible and this means cutting corners as much as you can while still having a presentable usable facade reuse existing code grab art from the internet if you're in a large company borrow what you need from other Studios one product site we built at PopCap was made almost entirely of assets from the Facebook game Pet Society and borrowing those assets from the Playfish studio with any a allowed us to build a prototype quickly although the player character we used was from a Google image search once your prototype is built it's time to do the hard thing and have people play it to watch them play it and collect copious amounts of feedback this is going to require being confident thick-skinned and tight-lipped your team's internal notes and feedback are valuable but never in isolation consider your subjective feelings on your own work as a hypothesis to be proven disproven by exposing the work to wider and wider audiences the closer someone is to you and the project the more that bias will affect their evaluation the most Onix feedback that you can receive

is from people who don't know you and who are reacting solely to the game that's in front of them that said you should take advantage of any opportunity you have to actually observe someone playing your game ask them to think out loud narrate their experience what they're noticing what they like what frustrates them what confuses them see how they react to different moments in the game watch the screen to see what they're doing and what they're trying to do and how it relates to the way they're reacting and during all of this and I mean this in the kindest way possible keep your mouth shut don't explain don't get defensive just observe because the more that you say the more it's going to color their experience replace testing outside of your social sphere I strongly recommend user testing calm it lets you upload builds and expose them to targeted demographics complete with recorded footage of their gameplay and survey questions and user testing was indispensable for us within pop labs collecting external feedback on our prototypes and they have tools that make it easy to timestamp your notes and create highlight videos from the play test all the feedback that you receive

needs to be collected categorized and considered and evaluating the feedback means asking a few questions what's working what isn't what could we iterate on and most importantly do we keep going or do we try something new and here we arrive at a critical part of the process the decision whether to iterate on what you have or put it down and go back to the box and there's always a chance that after one iteration you'll quickly determine that the concept doesn't pan out and the decision to put it down will be easy most likely however it's going to be hard to make that kind of call most of the time you're going to think well maybe if we try this it'll work and this is again where the sunk cost fallacy rears its ugly head iteration on any concept takes time and walking away from something you've invested in always feels like admitting defeat and feels like wasting work but this is where the box is important because part of the decision to shelve or iterate is about whether you and the team still feel passionate and confident about what you're building and whether there is something in the box that is tempting you or some open question in another design that is clicked

sometimes you're going to shelf something sometimes are going to shell something because you know it's not working sometimes you'll shelve because exploring how to make it work is costly and not worth the time and sometimes they'll shove something simply because something else caught your attention and there's momentum and excitement behind that something new and chasing something new can actually be incredibly fruitful so after spending his first year as an indie dev building an ambitious tactical strategy game my friend Eric Ryman switched gears to collaborate with game designer Dana Nelson on a co-op mobile title but during a break in development Eric wanted to try something he'd been toying with in his brain so he took two weeks to build the first playable of clone drone in the danger zone and the games now in early access and has proven extremely popular with streamers clone drone quick success turned it into a full-time project for Eric and has actually allowed him to bring on a second engineer to aid in its development all because he had an idea that had been percolating wanted to try it out and had a path to do so quickly an Eric story and Eric's story

illustrates the importance of both the shelf and the box the value of a process that lets you put something down in favor of trying something else that's one win too and it's called a shelf for a reason projects on the shelf aren't dead and buried they're displayed proudly as a record of progress and accomplishment they're easily returned to and they exist as reference material for both you and your peers does the metric for prototyping success is not how many projects you get greenlit it's the number of things you've tried a major part of the 4f process is celebrating everything you put down it's a mark of experience and a moment of excitement as you pick up something else and this isn't just about exploring new ideas it's about the building development mastery creating team cohesion before teens ever enter production fostering healthier relationships to critical feedback and motivating teens to think different the process requires room to

breathe and insulation from executive oversight as much as possible nothing being prototypes should be expected to go into full development or ship investing in R&D means investing in something separate from normal development expectations and pressures the more pressure you put on every prototype to work the more teams are going to feel up sunk cost and everything they try and the more likely they are to fool themselves and others into thinking something's working even when it's not for the sake of moving it forward an order hit some quarterly goal but this also means teams need to be critical of each other and maintain a practice of honest critical feedback the studio as a whole needs to demonstrate that it is capable of autonomy and if you wait for someone higher up to tell you how to manage your time you lose that autonomy now I worry about our industry a lot for a variety of reasons but games are my passion and making games is what drives me and I want our industry to be more open to exploring the full range of what games can be and having that kind of exploration happening within casual games is extremely important because casual games are for everyone and I like

to tell people that I make games for everyone and it's about diversity and inclusion but it's also about scale more than any other part of the industry casual games have the potential to reach the widest audiences and they accomplish this by offering simplicity approach ability they defy the prior games literacy that so many console and Triple A games require as a prerequisite for enjoyment when you make casual games you are inviting the world to play TM we developers owe it to our players to bring the light to even the smallest moments of their day to create playful opportunities to connect or reconnect with others to make them smile even when they need it the most and we can't devote so much of our trades repeating the same patterns expecting different results we need to move casual games forward it's not just good for our players it's good for business anyway I hope you'll all join me in making better games and making games better thank you I'm popular I think I'm just bringing that kind of like failure thing to real

sharp focus the other thing I wonder about I've got to know if your feeling is the same and the number of companies invest in that space well it's still relatively small life here and but is this what the indie scene has been able to do just give us a space where we can do that so although we're taking the risk when we do do that you know it's interesting they my friends who have become independent developers I love them they're great people but many many of them jump into one immediate project this darling that they have and what they want to invest their time into and they'll spend one or two years just focus on one single project and it's a really great example of someone who did that his first year was was on this tactical strategy game and it was only when he made the decision to actually put it down he was able to begin exploring things more more loosey-goosey and that was really the moment that he was actually able to turn success kind of thing we need to do more of that I'm glad you very much thank you

[Music]