Sponsored By

Rapid Prototyping: Tips for Running an Effective R&D Process

So you realize that it's important to prototype your ideas before launching into production -- but how do you do it? Arkadium's director of R&D, Tom Rassweiler, lifts the veil on his company's process and explains why it shifted to central R&D for new game prototypes.

October 17, 2012

14 Min Read

Author: by Tom Rassweiler

So you realize that it's important to prototype your ideas before launching into production -- but how do you do it? Arkadium's director of R&D, Tom Rassweiler, lifts the veil on his company's process and explains why it shifted to central R&D for new game prototypes.

As the director of Research and Development at Arkadium, I'm tasked with identifying unique and successful game mechanics for our future games. Based on my experience, I'd like to share some tips on how to implement effective prototyping with the use of an R&D team.

The decision to move to a central R&D model was not made lightly. We have a long track record of successes nurtured via an ad-hoc method of idea-creation based on individual and team initiative. However, a variety of changes in the game industry and in Arkadium's target platforms have dictated our forming a dedicated R&D team.

The use of prototyping and how to predict whether a game will be fun or a flop

Due to new distribution methods, new audiences, and new platforms, the game industry is now rewarding unique, creative game ideas like never before. New, lucrative genres are being discovered and capitalized on, such as endless-runner, mobile asynchronous multiplayer, touch storybook, and unique physics (rope, slingshot, fluid).

In response to the increasing complexity of the industry, the idea of effective prototyping is very hot. Companies such as Double Fine, Firehose Games, and PopCap are extremely vocal about the advantages of the rapid prototyping process. At GDC 2012, there were 14 talks that were focused on prototyping, compared to six in 2011 and five in 2010.

Prototyping is useful because the best way to know whether a game will be fun is to play it. You can discover problems and stop development on unprofitable ideas early. You can focus on the core elements/risks of the game without distraction, and you can collect feedback and analytics from real players about the potential success of the game mechanic before sinking a lot of money into it.

When a company is searching for a new hit game mechanic, quantity equals quality: the more game mechanics you try, the more likely you will find a unique game that has the potential to be a hit. A classic example is Rovio Entertainment. Rovio is frequently cited for having released more than 50 games without a hit before launching its record-breaking Angry Birds. So the more ideas that are tested, and the faster and more efficient the prototyping and prototype evaluation, the more likely you will find that hit game. Had Rovio effectively prototyped these games quickly before releasing them, Angry Birds might have been released much earlier.

Signs that you need more prototyping

The advantages of prototyping are generally well known, and most development teams spend sometime prototyping before each project. However, it is also generally true that teams never feel they have enough time to prototype well, especially when clients or managers are heavily focused on quick revenue.

Often, this tension is good. Teams should have deadlines for prototypes, and short schedules for prototyping ensure that they stay focused and avoid getting drawn into over-polishing. However, be alert for the following warning signs that mean your company may need to invest in more prototyping, and possibly even to create a dedicated team for it.

  • You've pitched games to clients, or started projects and then a couple of months into development (or worse yet, at the point of release) you realize that the game mechanic is neither fun nor intuitive. A prototyping team can keep your company from wasting time and investment on games with deep problems in the mechanic.

  • If you hear yourself saying, "Our competitor uses this solution all the time, and they must have done user testing, so let's just do it that way" -- then you're just following other teams. You're not innovating. Worse yet, you're not learning anything for yourself. R&D can help you develop your own solutions.

  • If you're a company that previously made small games with small teams, but are starting to expand into bigger, more complex projects, you will need to set aside more time upfront for prototyping and evaluation.

  • If you are having problems developing successful microtransaction-based games, you're facing a corollary of the above problem with project size: microtransaction-based games require a lot more time to create content, balance the economy and test. This extra time will be wasted if the mechanic isn't perfect.

  • Finally, be wary if you're having a hard time building a quality brand with your consumers. Building a quality brand requires that you release successful games consistently. Good prototyping can help you avoid releasing flops and ruining your company's image and your player's trust.

The resources you need to create an amazing prototyping team

If any of the above warning signs sound familiar, consider expanding your commitment to prototyping and possibly setting up a dedicated team. This means assessing the resources you and your company will need to create it.

Most importantly, you will need full support from top management to effectively provision, protect and maintain that team. Prototyping is often considered the least important task. Consequently, a team that is prototyping will often lose developers, designers, or artists to "more important" tasks. This can be devastating. Being treated as the least important team hurts morale and quality, and losing and adding members during development will break the team's focus and create friction. The company needs to be convinced that prototyping is a high-value activity.

Initially you will need a small team of at least three or four people who have cross-disciplinary skill-sets, including art, design, and programming. This doesn't mean that every individual be expert in every skill (though that wouldn't hurt), but each individual should have at least two of these skills. If each member of the team isn't self-sufficient, it becomes important that they communicate and cooperate well.

Each member should have responsibility for the resulting quality of his or her prototypes. When I say "quality", I mean the resulting fun. There may be a manager in charge of the team, but avoid including someone who will start making all the decisions for the team.

For one thing, it recently has been demonstrated that diverse teams will create better solutions and predictions than experts, and more importantly, most decisions should be resolved through testing and data rather than through relying on anyone's personal opinion.

You will need people to test your prototypes -- possibly a lot of people. This initially can be solved by asking people from the rest of the company to play the prototypes and provide feedback. However, in the long run, you should have a budget for external testers, because you need play-testers from your target demographic who have not been "tainted" with the earlier builds.

Last but certainly not least, you want to be smart about setting expectations. Don't expect hits immediately, or even within the first several months. Expect and value failure. I know this sounds crazy, but if you prototype a promising idea and quickly find that it isn't fun, the early failure of this idea will have saved your company months of wasted effort had you put that idea into full production.

Idea creation

Now that you're convinced you need to do more prototyping, and you've put together your team and set expectations, your first challenge will be to collect game ideas. Most people in the game industry have some good ideas, but ideas from a small group of people are never enough. When you are collecting ideas, you want to collect as many as possible, from a variety of people with different perspectives.

Arkadium decided to make the process of idea creation and prototype evaluation as open as possible. Not only because we think that hiding this process could be bad for morale, but because every game company is filled with creative, passionate people who would love to contribute if only they were given the opportunity. We make it easy for any Arkadium employee to submit ideas, and offer monetary and prestige incentives. You should always remember that your company's next hit idea could come from any employee.

Effective use of rapid prototyping

After my team has selected an idea, we follow a process of rapid prototyping and idea evaluation based on the theory that "you can't be sure it's fun until you've played it", and you should embrace "failing fast and frequently".

These are the key steps we take during this process:

  • Collect as many game ideas as possible

  • Create playable prototypes of the best ideas as quickly as possible

  • Use peer review and analytics to discover the best prototypes for further development

This seems like a pretty simple formula, but the details get a bit tricky when trying to strike a balance between prototype quality and development speed. We've learned a lot about this process, and we're excited to share some of our discoveries with you.

Focused goals put the "rapid" in "rapid prototyping"

R&D at Arkadium makes a lot of prototypes. To give you a general feeling for the speed of development, one programmer is expected to build a prototype every two to three weeks with enough function, art, sound and contextual help to get peer and public feedback that is meaningful. Any developer used to working with timelines defined in months or years would probably be terrified at this proposal. So it's important for an R&D team to recognize the differences between a prototype and a full game, and where it's appropriate to cut corners and where it's not.

Most importantly, the goals of a prototype are different from the goals of a full game.

Here are some of the primary goals of a production game:

  • Attract the most players

  • Keep them engaged as long as possible

  • Instill brand or character loyalty

  • Make money

To achieve this, we use a huge host of tools, including:

  • Excellent core mechanics with unique features that adapt perfectly to its device

  • Eye-catching art

  • High quality sound and music

  • Demographically-targeted theme

  • Attractive and inviting characters

  • Long-term retention content, unlocks and achievements

  • Complete help system including first user experience, contextual help and full explanation of rules

  • No critical bugs, and good performance on a broad range of devices

This list only scratches the surface of the myriad of tools used by a developer when making a hit game. For example, a discussion of how to choose the best "demography-targeted theme" could take a whole book. So, in order to let a programmer create a prototype every two weeks, we have to loosen our goals quite a lot.

Our goal for prototypes, created at Arkadium, is to create enough of a game to expose the unique core mechanic and let people decide if it's fun.

For this, we use a simplified set of tools:

  • Excellent core mechanics with unique features that adapt perfectly to its device

  • Art of high enough quality that users aren't distracted by it

  • Sound only to punctuate the game mechanic

  • Enough help that users understand how to play the core mechanic

  • No critical bugs, and good performance on a specific high-powered device

As you can see, by comparing these lists, there are a lot of elements we are able to ignore. You and your team need to have a laser-focus on the main goal of creating a fun, playable core mechanic as quickly as possible. Our team uses a two-week deadline; you may want to set your goal a little shorter or longer, but having a tight target will ensure that you stay on track and keep focused.

How to know when you're done

So you've been developing the prototype, and iterating quickly with playable builds every two days while avoiding all unnecessary features. Two weeks are up. Are you done?

Our team reviews all our finished prototypes against a checklist at the end of the process to be sure that the prototype is complete enough that it will let us successfully evaluate the game idea. Here is the checklist we use:

  • Visible and up-to-date UI elements for all key stats (score, time, level, etc.)

  • Visible goals and indicator of progress. A player should know their goal at any point in the game and how close they are to achieving that goal.

  • Art is consistent and of high enough quality that it isn't distracting.

  • There is a clear message when the game is complete (win or lose). It provides an evaluation of success and allows the player to play again.

  • There are visual and audio cues every time the player has been successful and taken steps towards the goal.

  • A player who has no prior knowledge of either the game mechanic or the idea can start the prototype and understand the mechanic enough to make meaningful progress without any other help.

  • The prototype has imbedded analytics-tracking to allow for evaluation of success with a public beta test.

After evaluating the prototype against this final checklist, our team will release it for evaluation within and outside the company.

The last thing to be aware of is that most prototypes that use a unique, new mechanic fail with audiences. Players will try them for a bit and get bored. Only a small subset of prototypes will show promise for further development. Embrace this failure if you have followed the above steps and released a prototype that fulfills its core goal of "exposing the unique core mechanic that lets people decide if it's fun". If people say it's not fun, then just be glad you tested it early as a cheap prototype, and didn't try and build a full product around what proved to be a bad idea. Move on, and get excited about your next experiment.

How to tell which game to move into full production

Throughout the entire process we rely heavily on feedback and analytics. At each playable step in developing a prototype, we expose it to widening group of play-testers (co-workers, friends and family, or volunteers). Based on evaluation of these playtests, we decide to either iterate or trash the idea and move on. So if you've completed the prototype and still haven't trashed it, you must believe that it has revealed a seed of unique fun.

But how can you choose between a variety of prototypes that each have this unique seed of fun? For this, we rely heavily on analytic data collected from average players in our demographic. You can get data in a variety of ways. One is to put the game on Facebook as a stand-alone app, and then use targeted Facebook ads to attract a small group of tightly targeted users. User-reported feedback, including polls and comments, is sometimes useful, but I set a higher priority on feedback from data such as "time spent per unique user".

One question we often face here is how to balance the need to keep your fledgling ideas secret from your competitors versus the value of the data. This is a tough decision, but in general the value data tends to be worth the risk.


It is true that the computer game industry has grown a lot during the last few years, but it is still in its infancy in terms of new game mechanics. Mobile game players increased by 22 percent in the last year alone, representing a brand new demographic of gamer. Platform manufacturers are also ushering in a variety of new ways for players to interact with their games, including touch, tilt, gyroscopes, gestures, and even mind control. It's come to show that rapid prototyping is the best way to capitalize on these exciting developments. I hope that this article and others like it will give you new tools for discovering unique and innovative mechanics, and will help us take the industry to new heights of success.

Read more about:

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like