Sunday, February 21, 2010

The Fundamentals of Proof of Concept

By William Anderson/ President of Awaken Games

In my last article, How to Get Your Design Ideas into Production, I touched briefly on the subject of POC or Proof of Concept, as an important stage of getting your project accepted by a developer or publisher. Now, at the request of some of GIG readers, I will attempt to expand on this subject in much greater depth.

First, for those of you who my not be familiar with the term POC or Proof of Concept, it is simply an abbreviated version of your game, or product concept, designed to better sell your production or design to a company. In short, it is a condensed version of the game that a developer or publisher can put their hands on and really see what you are proposing.

Think of it this way, when you go in to buy a new home what is the salesperson going to highlight? The leaky pipes? The neighbor next door with the large barking dog and 1am jam session? No, they are going to show you all of the nice amenities that product has to offer.

This is exactly what your POC is designed to do for your game concept and/or proposed production -- sell it to a developer or publisher by highlighting the best game play features and art this concept or product has to offer!

But, before we dive into the subject of POC development fundamentals, I must dispel a myth: Your POC does not have to be a full-length level or game, it can be as simple as a few screens of game play.

Mainly, the best rule is to add as much as you believe is needed to show off the best qualities of your concept proposal. If you can stand back objectively and look at it and say, "I can really see the full direction of playability for this product based on the hands-on experience!" Then you are on the right track.

Remember that when your concept or proposal hits a developer or publisher's door, it will be judged on a number of key factors. It's best to try to keep these factors in mind as much as possible during your POC development process. Here are just some of the factors to keep in mind...

1: Acceptability…Does the developer or publisher accept outside concepts or proposals? Your early research into developers or publishers, prior to submission, should weed out this possible impasse situation.

2: Applicability… Is this the style of product they have marketed in the past or can market?
If this company has never taken on a product like yours in the past then you will more than likely have an uphill battle to get your concept accepted, unless you are a great salesperson.

From experience, the larger a publisher or developer becomes the harder it is to get them to open up to new or totally different concepts. They have established a rhythm for selling into set markets, and fear rules them changing from that path (especially if they don't have the money to risk).

I've seen mature sales people break-out into a cold sweet during meetings where CEOs start to propose taking on a project that takes them into unknown markets. It's best to play in their backyard when picking your concept proposal. Selling your concept to the sales and marketing staff can make or break your chances at acceptance. A good CEO will rarely go against his marketing staff unless he or she wants them to break out of their rut and branch off into new markets. (There are ways to make a "Don't Want" company a "Want", but that's another article).

3: Marketability… Are the market conditions right for such a concept, at the projected time of publishing?
This is truly key to understand when proposing a concept to a company. If there is a projection of a glut of 3D Shooters at the time of publication, then there is little likelihood that a publisher is going to be too hot about your 3D Shooter concept. Be very mindful about the upcoming markets. If a publisher is not totally aware about an upcoming glut of games like yours, then they may -- and more than likely will -- cancel your product during production once they see the wave coming. Or worse, perhaps, they can have you dancing your game design around fears of new features of upcoming games like yours. This can lead to long delays in production, loss of original focus of the design, and a totally frustrated team, who are also becoming unclear on what the final game is going to be.

4: Playability…Does this game play well enough to compete or dominate in the target market?
This is a very important factor. If your game concept does not offer anything new or unique, you might as well pack your bags and go home. And PLEASE don't say, "We've got better Art!" With the advances in art technologies, plenty of games have great or acceptable art, but play poorly. In short, a purity picture does not sell games anymore.

My own personal rule is that a typical game player will only be drawn in by nice art for about 30-45 seconds when they first see it, after that it's all game play. For your concept proposal to really stand out it will need some "Killer Apps", or features that set your product apart from all other concepts -- something that you can really focus on in your presentation pitch to a developer or publisher.

5: Graphics and Effects…Do the graphics proposed in this product fit the concept and are they of market quality?
Although game play in my book is always king, you need the balance it with a look that fits well with the concept and is competitive with other products coming out. This means that the quality of background art, textures, special effects, lighting, and shadow-maps must all compete with the art standard being set in today's games.

That's the basic questions that might come up, but only by truly understanding these types of questions will you be able to better position your concept or product for acceptance by a good developer or publisher.

And, as a side note, you might have noticed that Music and Sound effects are not included in the above list. This is because I've never seen a publisher expect this to be included in a POC product proposal. This is not to downplay its importance in the total balance of the product, it's just something that comes into play later during production.

Now for Proof of Concepts development fundamentals in greater depth…
By now you should have some idea of what a POC is, but if it's still not clear in your mind then, simply put, a POC, in most company minds, is "First Playable" for your concept. This would be, typically, one or more stages of play that really demonstrates the core of the game play and any killer features that set your product apart.

A production cycle for a Proof of Concept would typically looks something like this…

1: Sit down with your project staff and just get totally wacky! Let ideas flow from all directions with no rules about what will work or not from a technical or game play stand point. Campout for about a week and have some fun during this stage. Write down all the thoughts that flow from these talks. And don't be afraid to spend a little money on research material like magazines and games that are like the product you are trying to create, or that have elements that really inspire your thoughts.

2: Next, hand all of these notes over to your staff in charge of assembling this into the final design for the game. Don't worry yet about how clean this information is, just make sure it contains the heart of your product ideas.

3: Sit down with your team and talk about what ideas in this concept are the Killer-Applications for the game. This is what will make people go all tingly inside when they see it or play it.

4: Now, hand all of this research and brainstorming information over to your lead or senior designer to be compiled into a concept design document for final approval. This must be a person you trust with your vision for the game. Believe it or not, someone must be the final judge of what will make it in the final product and what will not. PLEASE don't set up a full development team committee for this process! A final review team of Producer, Designer, Lead Artist and Project Programmer is the most you will ever want in this process. These are the people you must ultimately give total trust to in making the POC and final product, and that trust must be seen and understood by all development staff members.

5: With final approved concept design in-hand, it's time to assemble your conceptual material, such as character designs and A.I. designs, game play level layouts and mechanics. Here is where a great conceptual art designer comes in really handy. If you have never worked with such a person, you are really missing out on a great experience. For clarity, a conceptual artist is not a production artist. He or she is an artist totally dedicated to providing you and your team with all of the visual inspiration needed to make their jobs easier,

6: Once all of this material has been reviewed and approved by your senior project staff, it's time to assemble your design documents, such as…
Design Document that outlines the total scope of the production in as much detail as possible. (There are some good articles here on GIG to review on the subject)

Art Requirements Document that list out all of the screens, character animations, effect items and interface items needed for the game.

7: Now, review all of the documents you have just prepared and refine it down until you and your senior staff are happy and committed to the final vision and scope of the proposed production.

8: Next, you need to have a meeting to review what within this design you really want to focus on for our POC stage or stages? Remember that you want whoever plays the POC to really get a great idea of what the final product is going to be. Once this meeting is done write down all of the best features, level elements and so on that will make up the heart of your POC.

9: Schedule out all of the tasks needed to finish and fine tune your POC product. Remember to always give yourself some buffer time to fix bugs and smooth over the rough edges.

Simple Guidelines…
> Must be simple to understand and play.
> Must look great.
> Must Not Crash.
> And if at all possible, must be on target platform.

10: Assemble a POC staffing and requirements document that outlines all of the people, equipment and resources you will need to finish your POC.

11: With your schedule and POC requirements documents in hand, it's time to prepare your cost projections for the POC stage of development. This is vitally important, as this is what you will be asking a developer or publisher for initial funding for. Again, build in some buffer funds for unknown cost that will pop up.

12: Now, assemble all of the information, designs, concept art, schedules, etc into a nice neat presentation package. This is your Concept Resume for success so make doubly sure you are happy with it before your take it on the road.

13: Lastly, take it on the road. At this point you will send it out or take it on the road to be reviewed by your target developers and or publishers. The only thing to remember during this stage is that you are only seeking funding for the POC stage of development, first. Then, after they are happy with the proof of your playability, then additional funding will be required for completion.

Don't expect a home run on your first trip to see a developer or publisher. I've worked with some large publishers who only wanted one thing out of their first encounter with a new developer -- to see who these people are and get to know them personally. Then, if they believe these people are smart, trustworthy and have the personal skills needed, a second meeting is called for. Sometimes they do not even tell the person about calling for a second meeting until days later. This is normally because they want the time to evaluate feedback from all of their own staff members who met with you or know of you or your studio.

Also -- very important -- don't get all twitchy if there are people invited along by the publisher that seem out of place. The publisher knows the skills and knowledge of their staff better than you do, and if others are asked into a meeting it's because someone trusts their feedback -- don't discount their importance. As a final note, you should understand that a POC proposal is best laid out in the same way as you would assemble your resume, with the most interesting, fun and dynamic aspects of your concept up front.

A common mistake I've seen in a POC product is where the player must dredge through endless areas of little to no interest just to find something great about the concept. Your POC product is NOT a good time or place to show off your game play pacing skills, as you slowly take the player up to something truly fun in your concept. Do what every it takes to get your audience into what game play makes your product great right away as people tend to pass judgment quickly, and if you've not drawn them in at the get-go you've lost your first impression advantage.

Copyright 2010 by William Anderson all rights reserved!

No comments:

Post a Comment