The Seven Deadly Risks

One of my favorite takeaways was from Tim Chang at GDC 2012's "Pitching Secrets Revealed" session. He enumerated the seven risks of a pitch -- things to cover if you want to look really good when pitching your idea. I loved this clean wrapping of general risks because the considerations of a pitch are -- or should be! -- the same considerations for rolling out actual development.

I mentioned these risks in a previous post when talking about how I chose which idea to go with for my first independent project. They're listed below with a bit of commentary.

1. Team

Have you considered who's going to actually implement your idea? There's a reason recruiting agencies exist -- good talent is hard to find. Thoroughly think through your idea such that you know what personnel can feasibly carry your idea across a finish line.

2. Execution

How is what you want actually done? Do you know how other, similar ideas were done and where they failed or had difficulties? This is a universal risk that, though unpredictable, benefits from proactive mitigation.

3. Technology

Does your game's engine exist? Who provides back-end services to handle your grand features?

If all your idea's required technologies don't exist, guess who has to build that! If they're all available and ready for your team, guess who has to hook them up to your product -- doubtlessly without any bugs whatsoever from those technologies, right?

4. Market Risk

That isometric facebook game probably sounded like a fantastic idea! You know your demographic and are going to be successful once you give that niche market what they want in six months. Oh, Farmville came out after your first month.

By the time your product ships, your users could care less about your product and more about clicking cows and super meatboys. Understand the trends of the space your product is in and whether or not that shift can be mitigated or predicted.

5. Regulatory

Especially when releasing abroad, a change in laws can really hinder your product. At GDC 2011, I met a Shanghai native that told me bones, skulls, and pandas were all present in some of his other games... but World of Warcraft has had to rework loading screens, models, and various other regulatory costs.

6. Competitive

Just because your idea is great doesn't mean someone else won't do it better and before you do.

7. Scalable Business Model

Your product has released and you are doing fantastic. Your investor is wondering: how is your business model going to scale such that your company doesn't topple over? Even if you haven't hit your wave of success, there are lots of great talks from GDC 2011 where small developers learn -- the hard way -- that going from 6 to 12 to 24 people brings about huge changes in culture and communication.

Overall, this was a fantastic panel to attend. I recommend watching the whole thing on the GDC Vault, especially if you are an independent developer. In my case, having a catchy "7 Deadly Risks" helped convey exactly what my considerations were for my first project -- and I'll formally be considering them in my larger, future project.

Building A Small, Independent Project

I have the opportunity to build something for a month or two, so here's a very high-level description of how I approached that.

1. Scope an idea to feasible size and requirements.
2. Evaluate technologies for implementing the idea.
3. Resolve barriers to implementation.
4. Implement idea.

Scoping an Idea to A Feasible Size, Enumerate Requirements

Everyone, including me, has lots of ideas. If caution isn't exercised, one could iterate forever on those ideas.

Here are the ideas that I went through for examples of how they didn't end up as my project.

• "The game idea" that is in the back of my head, much like that one that's in the back of your head if you're the type to read this piece. Definite risks: team, execution, technology (engine, specifically), market, regulatory, competitive. Possible risks: scale of business model.
  
• A player-to-player feedback tool to evaluate a player in any game. Definite risks: execution, market, regulatory. Possible risks: competitive, scale of business model.
  
• A set of game design apps that distill popular implementations, exposing the simple game designs that lie underneath. Definite risks: execution, market, scale of business model.

In the end, it made sense to have a single instance of the third idea since that was most feasible and quick to implement. Feature sets are reduced to simply the main interactions between the software and the user, the back-end data storage (if any; this could be luxury), and a way to get some money to keep me going.

Discovering and Identifying Technologies

GDC 2012 was my opportunity to find out what technologies could be used for whatever idea I implemented. I'd like to note a specific question I was often asked that implied I had things backward.

"Danny, what game are you going to make?"

I hadn't concretely selected which idea I was going to implement. How do you know that a technology has not been developed that solves the largest, most difficult part of your most monstrous idea? To commit myself wholly to a specific idea -- and then set out to see how new technologies could be fitted to it -- made little sense and would have felt limiting.

As of this writing, I have no regrets with my chosen order. HTML5 was being pushed the most heavily; I see much prototyping potential and can appreciate its contrast against previous platform-limited technologies.

Removing Obstacles Between Potential and Action

The organizations at GDC were also useful for gauging how projects get started -- specifically, how startups are finding their first steps. I never even knew there was a way to simply ask for money if you could properly pitch a great idea.

Due to my current circumstances and my small-scale project, I do not need funding. Even if I did, I would say -- from what I saw at GDC -- that investment is currently nearing the end of its initial wild-hype stage. Investors know what they want from game pitches and even the newer player-driven organizations have gone through lessons in investing (I'm specifically thinking of http://indie-fund.com/ and their move away from open submissions). It still seems relatively easy to get funding, but not as easy as perhaps it was a year ago.

Doing this small-scale project is a great proving grounds, and -- if at all successful -- would make for a more confident impression on investors in my future, larger projects.

Action

Every week, I am holding myself to feature milestones and abiding by what I'm reading in The Lean Startup, which I've found refreshingly in line with my general disagreements in the industry. The focus is on feature and implementation delivery, not on deadlines or planning.

Here are my milestones as they stand.

• Decision on which technologies to use. Decision on project, scale, feature set, and market space for 1-month implementation and deployment. Week of 03-05 to 03-11, the week of GDC.

• Prototype of general behavior. Week of 03-12 to 03-18.
• Single, final implementation of general behavior. Prepare implementation for ship on markets. Hypothesis: friends will download and install the app. Week of 03-19 to 03-25.
• Validate hypothesis or course correct. Add menu, which offers image changing, payment option, and exit -- with some form of metrics for usage, frequency of selected options. Hypothesis: users will change the image, users will pay to help out the developer. Week of 03-26 to 04-01.
  
• Validate hypothesis or course correct. In menu options, add ability to change background sound and interaction sound, metrics. Hypothesis: users will change the sounds. Week of 04-02 to 04-08.

If this turns out well, I hope it leads to a humble startup. If this doesn't turn out well, then I'll at least have the experience of trying an independent project. That experience will only strengthen my skills in a future job and the product itself will show my chops are good enough for a gig.

What I also want to share is this experience, and its decisions, with anyone who is interested. I get questions about various game development practices and aspects -- such as Scrum methodology -- and this is a great chance to let people simply ask me about them. If that sounds like something you'd like to see in the world, feel free to support me on kickstarter. You can see what goes down without leaving your job or having to start your own projects/company!

If you're from my hometown, El Monte, or from another "poor" city, I'm especially interested in informing you. There's a lot out there that you simply will not see in our cities, that I would have never seen if not for the fantastic input from experienced individuals. It's my turn to pass knowledge on; my potential company will be the way I do so.