- Scope an idea to feasible size and requirements.
- Evaluate technologies for implementing the idea.
- Resolve barriers to implementation.
- 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.
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.
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.