Page 2 of 3
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.
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.
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:
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.
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:
To achieve this, we use a huge host of tools, including:
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:
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.
Page 2 of 3
