Reasons for Modest First Projects and Incremental Learning

I asked another question to the community with @HobbyGameDev on Twitter recently. For the most part the responses were incredibly illuminating about what challenges new game developers were experiencing. I love these kinds of questions and responses since it helps keep me firmly connected to people's real needs.

Although I was able to field a number of exchanges within @reply tweets, the most important one to address that couldn't fit in that space is perhaps this exchange:

I want to be clear that I am in absolutely no way intending to draw any negative attention, attitudes, or ill-will toward our good friend in the world, Orange Rectangle (or O.R., for short). I asked my question with the specific purpose in gaining a better understanding of the challenges people were experiencing, and O.R. then offered an answer in good faith to help me. I attempted to offer some real details (those numbers are from Uncharted 2, by the way) in the sincere hope that this might help lead to a startling realization.

It did not. Instead O.R. dug deeper into the trench, now on the defensive. Then O.R. lobbed a grenade, suggesting that the problem here must be that I just don't know what I'm talking about.

If I thought O.R. was just trolling, I'd simply ignore or block them to prevent any further attention being stolen from the many people out there who are really interested in making videogames. However I've met and spoken with enough people face-to-face sharing a mindset similar to that of O.R. to believe this is worth addressing directly. That this is still a fairly common way of thinking for people getting started out seems to me a sign that it hasn't been suitably explained, or at least not yet in a place that's easily found by those who are looking.

I offer the following to our friend O.R., and of course to others who may share his mindset:

Dear O.R.,

I'm not saying you can't or shouldn't. Maybe you'll pull it off. That'd be awesome. More power to you.

I suspect many people doubted Notch when he started work on Minecraft. Although by that time he had already been programming for 25 years. People were probably skeptical of the team that made Angry Birds. That may have just been extrapolating from the 51 games that Rovio made before that project became a new standard for mobile gaming. The success of Super Meat Boy was not guaranteed. However Tommy Refenes had been making games for 18 years before that, and Edmund McMillen, Tommy's collaborator on the game, worked on 14 finished games before Super Meat Boy (including its free Flash precursor, Meat Boy).

Even with their accumulated experience, these now famous developers still didn't make games with the look and feel of a modern Call of Duty or Uncharted. From a technical, team size, and content creation standpoint, Minecraft, Angry Birds, and Super Meat Boy are tremendously less complicated than either a Call of Duty or Uncharted sequel (let alone a brand new intellectual property).

Many videogame developers at some point bite off more than they're ready to chew, for at least one project, and can sometimes take away from that experience some helpful concepts for later. For me that was Guinea Pig back in 2004 (screenshots here and here).

A screenshot from Guinea Pig, for which my engine used skeletal animation (authored by a custom tool), clothing/skinning, blood/bullet decals, real-time fully destroyable terrain, dozens of weapons types, parallax scenes, dynamic fire systems, hi-res “mode 7″ semi-3D aircraft effects…

So, with that in mind, why not just attempt the dream game first, and if it doesn't pan out, just learn some lessons in the process?

Here are a few reasons that I think should at least be considered.

Why Not Start With Uncharted/CoD

I'd like to make a case here for why those tutorials don't start with a Call of Duty or Uncharted style game (let alone a variation with world building and other additional features), and instead focus on games like Pong or Asteroids.

In Daniel Coyle's The Talent Code: Greatness isn't Born he talks a lot about deep practice, or edge practice. As a takeaway from his multi-year international study of what world class experts in a variety of disciplines consistently do to get there, he explains:

Or, if I can reframe that in terms of a more widely recognized system of incremental learning: no matter how strong, flexible, and quick someone is, there are still steps that they need to progress through in order to earn a black belt in karate. Skipping over essential steps means instead of productive edge learning atop a solid foundation, a person instead tends to wind up with sloppy, ineffective actions detached from the many lessons figured out by prior generations.

While I do not claim to be a world class expert, as Coyle's subjects are, I have enjoyed some recognition for my commercial videogame work, which started more than a decade prior by doing exactly the same kinds of simple historical game remakes that I consistently encourage others to try when starting out. By starting small and moving toward increasingly complex games, a solid foundation of applied design principles and practical coding habits can be formed incrementally, with lessons picked up along the way that are appropriate in size to be learned from.

This Pong remake was some of my first experience with AI. Around the time I was playing (and modding a bit for) Quake 2. I wasn't crazy for retro games – I didn't even play Atari's original Pong until 8 years later – but I was interested in creating games that I could finish and strive to make well.

Over the years I've now seen a number of people massively overshoot their means on an early project and fail spectacularly. In most cases that unfinished game is the last one they work on, never fully recovering from having dug a pit of embarrassment and fighting through considerable frustration every step of the way. Getting some practice before diving headfirst into these kinds of undertakings can help steel us to the complications that they entail.

For example, by the time I bit off more than I could chew on Guinea Pig, I had already completed more than 15 other smaller games in the years prior. That steady momentum beforehand gave me the ability to pick myself back up and promptly get back up to full speed on new projects when that one didn't pan out.

This progression of foundational skills was also a central philosophy to both videogame development clubs I helped start: before someone has been a lead or solo developer for a game of early 1980′s-gameplay complexity, they're typically not ready to lead a team of others on a game of late-1980′s gameplay complexity, and so on. This begins with late 1970′s complexity: Snake, Breakout (not Arkanoid yet, that's mid-80′s!), Asteroids, or Space Invaders.

My first graphical game was based on the late 1970′s game Snake. Again: not because I grew up with it – I was born in 1984 – but because in terms of game mechanics and programming it was a realistic place to start.

For those developers that truly are extraordinarily efficient and clever, who say “that's so easy, why bother?” I have two responses: (A) that's grand, then you'll have no problem knocking it out in 30 minutes, or in an evening at most, after which when you come back with it completed you'll have impressed and earned the trust of more potential collaborators. And: (B) even if you know how to get started, and know that you know enough to work your way through it, going through the actual process of doing so will involve sorting out some details, processes, unexpected complications, and chunks of code that will together speed up and simplify working on the games you take on later.

Being able to do something and having actually done it are not the same thing. In particular, after you've already done it you'll have expanded the domain of what you're ready and able to do next.

Being Unprepared Isn't Bravery

As my friend Nicholas Brown commented:

There is a certain amount of fearlessness, unreasonableness, and boldness that successful entrepreneurs, innovators, and cultural leaders of all kinds have had at their core. However, the fact that some amount of fearlessness is a factor in success does not automatically mean that an even greater amount of fearlessness linearly correlates to greater success, nor that it's the only factor. Bold leaders still need a viable strategy, considerable experience and connections in the relevant domains, and a certain dose of patience and discipline underlying their persistence and determination.

At the heart of Coyle's research in The Talent Code mentioned earlier is the idea that we can learn most from those experiences which are just beyond our reach. That's at the core of deep, edge practice. When we extend ourselves greatly beyond our past and present proven capabilities, there are often too many convoluted ways to make mistakes for us to figure out how to make sense out of what isn't going right, let alone to learn from it.

First Projects Are Always Rough

We tend to learn most rapidly when we're still very new at something. Anything about the field can be absorbed as new learning. We quickly overcome the awkwardness and inefficiencies in dealing with whatever development environments, programming languages, and content tools we're working with. If you put a few months into learning how to paint landscapes well, your work at the end of that time would likely bear no resemblance or fit to the first ones attempted. Because of that rapid learning, going in this case from one new painting attempt to another gives practice and opportunity to rethink the initial decisions, and will likely work out much better than just spending all of those months retouching the very first painting started.

As Coyle (again, from The Talent Code) explains about the famously talented and accomplished Brontë sisters in relation to their work as novelists:

Because our first work is inevitably rife with beginner errors from learning as we go – even world famous authors first wrote amateur junk – insisting on making an idealized dream project as your first undertaking is unfair to the vision, condemning it to be rife with beginner errors. This is instead an ideal time to experiment a bit with modeling the proven past successes of others (those that are reasonably achievable within our means), including simple historical cloning as a form of initial practice and not as a shady business scheme. The Brontës started that way.

I'd say try getting some of the junk of your system first on titles that can be finished far sooner, aren't as personally important (read: not yet highly original), and won't involve pulling others into the risk involved (even if not risking your and their money, then at least out of care and respect for their time in something that has a reasonable chance of not finishing or finishing well).

A Composer That Hasn't Played

When someone wants to play piano, do they begin by immediately composing original works? I don't doubt at all that in the history of all civilization there are people who have tried to do that. Generally, though, we have not heard of them or their work.

We start with learning a bit about notes, sheet music, and scales. We build up to childishly simple sequences like Mary Had a Little Lamb. We move up, through consistent and focused practice, to trying to merely perform well some the more advanced classical works far before trying to compose our own.

The reason we see so many introductory materials about games like Pong and Asteroids – including the Hands-On Intro to Game Programming (my own approach following that path) – is because those are the Mary Had a Little Lamb of videogame creation, a tried-and-true way for someone new to game development to get oriented and learn to perform full, simpler classics before trying to become the next Bach or Mozart from day one.

Building an Aircraft Carrier… First

Where the above music analogy breaks down is that composers are often able to write music primarily alone. While that is true for a subset of videogames, it is not the case for the size and scope of videogames that you've identified as your target.

If someone is interested in making a boat and decides that the kind of boat they wish to design is an aircraft carrier, that's necessarily going to require a massive scale of teamwork, money, experience, earned trust/credentials, compromises, and a lifetime of work leading up to that point. It either won't be the first ship they work on, or the rushed result will involve so many compromises that it will not come anywhere close to what is typically expected of this ship type.

While it's true that we don't have many of the same material constraints and labor challenges as ship builders, what we are unavoidably faced with are literally millions of design, artistic, and technical decisions, from the very large to very small, which we have to make about everything in the game.

Faced with all of those decisions, making them well at every step either means having the experience from enough variety of past projects to make informed tradeoffs between alternatives (which is why teams generally want professionals experienced in videogame making, not just people who “can program” or “know Photoshop”), prototyping like crazy to find even a few small innovations that work, or adhering fairly strictly to conventions.

However, note that even companies filled with experienced, full-time professionals creating massive games that do adhere to most conventions of their genre still manage to go through $20 million just to get their game done and complete. These companies are in the business of maximizing profits and minimizing costs, with both internal and external pressures to figure out ways to do more and better work with the lowest possible expenses.

It still costs them $20 million or more to make what may appear to be a formulaic and relatively straightforward followup to an existing franchise (note that the actual changes and additions involved are often quite complex, but the differences may be difficult for someone who is not on the team to fully appreciate).

An Idea is Only as Good as Its Execution

One of the other common themes that arise in advice from experienced developers for others just starting out is along the lines of “ideas are a dime a dozen” or “no one cares about your great game idea.” This is in regard to what you're calling your “secret” that you suggest will, alongside world building, set your first game apart from Call of Duty and Uncharted.

My entries presenting my take on this include Stop Arguing About What Makes a Better Game and Start Before You Have an Idea, which covers an idea I often explain to others as:

Most successful games aren't a particularly genius idea. Conceptually they're usually pretty blatantly derivative but are polished in their execution to an amazing degree. When the idea is at least unusual, perhaps one that has been done before but not well enough yet to achieve widespread commercial significance and recognition, at best that concept serves as a marketing point to get people talking about it. But people generally don't keep playing a game, nor recommend a game to their friends, based primarily on whether a game has an interesting idea, unless it also has world-class execution and refinement. Provided it's got world-class execution and refinement, an interesting or original idea is often not even needed.

Pick A Fight You Can Win

Sometimes there's a confusion that because one or two indie games succeed financially in a genre previously thought dead (point and click adventure, for example), or with a very weird type of game (much of what's found in IndieCade or IGF), those games have been proven to be economically viable after all.

The underlying misunderstanding though is that what may be a tremendous amount of money when split only 1-8 directions among a small team of indie developers working out of their homes or a tiny shared office does not even show up on the radar of the kind of money that AAA companies burn through in only a few months of salaries for massive teams comprised entirely of experienced developers, legal/business personnel, and support staff along with paying for sprawling office complexes, retail distribution arrangements, television/billboard advertising budgets, etc.

Part of the way this all holds together is that even though a few individuals (out of the many, many more trying) might make enough money to pay their own costs and then some, it's still often far from being something that the big studios can take seriously as a business opportunity.

In 2010 I made a strange iPad entertainment app that paid my rent for 18 months. That registers as a medium success – weirdly putting me somewhere in the upper percentile in terms of return. While it clearly didn't make me wealthy (my rent at the time wasn't much), many more developers lose considerable sums of money or generate very tiny revenues in the range of fewer than dozens of dollars from ads, virtually non-existent sales, etc. Also, as a fair warning: the App Store was definitely a lot less of an over-saturated mess in 2010 than it is now. (Speaking of which, back in 2008 I developed a game for the app store that earned considerably more than that… for the publisher, which is how I learned a lot about being the weaker party financially in a negotiation.)

Anyhow, for perspective, a massive publisher pays their CEO more money than that 2010 app's total earnings in what calculates to about 24 hours of their time. That's not including the salaries of 9,000 other people, the costs associated with massive facilities, or the remaining mountains of money expected leftover for annual profits, etc. They have truly staggering ongoing costs to keep up with, which means they can't afford to take risky chances on little weird stuff, or on genres that are no longer desired by mainstream players. They deliver on what they have solid evidence to think will make a sizable return on their investment. Projects that don't meet that goal get eliminated. They're a business.

This is why when we see advanced indie developers succeeding commercially, it's usually not by doing better at what the big companies are in position to do well, but instead from some combination of strange projects (with regard to their execution, often not in the main idea; i.e. tons of personality in an otherwise relatively simple experience), retro genres that the AAA companies haven't been able to justify for 10+ years due to the shrinking level of market demand for such games, or the intersection of both (meaning tons of personality in a retro genre that has otherwise lost most of its market significance). With the rare exception of some mod teams that quickly get swallowed up into the machine and vanish for years doing polish work, indies stick to guerrilla tactics in niche domains that the huge companies can't justify meddling in.

It's not a matter of purely creative vision that Minecraft is built out of 1-meter cubes textured with pixel art, instead of having the look and feel of Uncharted or Call of Duty. It's small team resourcefulness.

(For more along these lines, read up about Blue Ocean / Red Ocean Strategy.)

Minecraft is basically 3D pixel art.

Funding Will Affect Design

Getting funded does not mean that you have the freedom to design your perfect game. When money gets involved, it tends to influence what gets made, even when sometimes only out of some crude evolutionary feedback loop where the games that do well in a given market space tend to soon be followed by variations from competitors.

But what about something like KickStarter, in which customers prove that they're there before development even begins? The space is filled with people that, because they've never had to work with a real budget before, tend to not know how to schedule and plan a commercial project.

If KickStarter sounds like freedom, it's worth looking up Code Hero, which raised $170k, well past their $100k target. I'll spare you the web search, and share this update from last year. Effectively, they ran out of money long ago and are now an entirely volunteer effort. Here are their KickStarter updates.

Where I'm Coming From

Although I started as a hobbyist, returned to making games as a hobby, and help other people get into videogame making at hobby-scale, what I'm suggesting about the nature of huge commercial-scale videogames is not just guesswork.

I've worked professionally as a game designer on the size of games and teams that you're talking about: games that take years, 80-200 full-time professionals, and tens of millions of dollars. I've also worked professionally as a game designer at other commercial scales: at a casual games start-up, in a gameplay R&D company, and as an iPhone game developer both independently and through publishers. I am familiar with at least a cross-section of commercial videogame development.

More importantly to this exchange I have also, with zero budget, served as a lead or solo developer on more than 85 completed freeware games with 3-18 month production schedules, and hundreds of same-day playable prototypes. Some of those were for class projects, some were created in clubs that I established, and many were just developed on the side.

Being in a position to compare those professional and nonprofessional experiences, I can say with total certainty that I have found infinitely more creative freedom in the projects that have no budget or funding than I've seen in working on games with a big budget.

That applies no matter whether I was being paid steady salary, hiring/paying/leading a team of others, funded by outside investment, or even when completely self-funding projects and theoretically having total directorial control. Games that cost money to develop have a certain obligation to prioritize earning (at least) that money back, which places certain inflexible outside demands on the work.

Make Finished Games. Without Funding.

There are ways to make videogames that don't require getting anyone else's approval, taking anyone else's money, or handing over veto control to your design ideas.

It takes time and a lot of work. There's no easy shortcut to it. But it is a way.

That way is to start small, building your way up from modest beginning principles based in time-tested classic designs, toward the point where you're prepared to do your more grand and elaborate game ideas justice, so as to have to ability to realize them without making compromises in service of financial obligations.

In other words, the way is to make videogames for free for awhile, incrementally advancing your skills and design understanding with each new project.

If however you choose to still push on the route of seeking substantial external funding, especially without any track record yet of completing any simpler games, I wish you only the best. Good luck.