Top two reasons why student projects fail

This article is not only for students, but also for faculty who are advising students on their projects (either extracurricular, or as part of a project-based "Capstone" course).

The sad reality is, most game development projects fail. This us true for student projects, and it's also true for big-budget "AAA" industry projects. With industry projects the reasons for this are many and varied, though there are some common themes; there are tons of project post-mortems available for you to see for yourself on sites like Gamasutra.

With student projects, failure is much easier to predict, because I think the vast majority fail for one of two reasons: overscope, and overreach.

Overscope starts like this: "I love playing God of War / Gears of War / World of Warcraft / Something of WarSomething. You know what would be great? If we made a game just like that, only better!"

Some professional industry projects start like that too. These are called "sequels." If made by a different team, they are instead called "clones" (or if you're feeling generous, "homages" or "spiritual successors"). Why can the industry succeed at this (sometimes) when virtually every student team fails miserably?

The main reason is pure hours worked. Let's take a typical console game: you're talking a team of anywhere from 30 to 200 people, working 40 to 80 hours a week, for 2 to 5 years. Even at the low end, that's 30 people x 40 hours/week x 100 weeks = 120,000 hours. Add to this the productivity difference between experienced professionals and totally green students (with programming this has been measured to be somewhere around a 4x to 10x difference), so a high-school or college team would need to put in 480,000 hours to make "the next Gears of War" or whatever. And that's a minimum. For a typical student who has the time to commit maybe 10 hours per week, that student needs 47,999 close friends. It's not gonna happen!

When I see a student saying they've got a 20-person team to make a game, I cringe. That is way too many people; communications overhead will kill the project alone, if scope doesn't! If that many students are interested in making games, they would do far better to organize themselves into a few 3 to 6 person teams, work on separate projects, and occasionally swap around their works-in-progress to the other teams for playtesting and honest feedback.

What's the cure for overscope? Go to the other extreme. Design a game that you can do in one week or less. If the game comes out looking good, you can always spend the next week adding another small set of features. If it comes out horrible, you're not so attached that you can't abandon it and try again with a brand new project. This does mean an adjustment in expectations -- you might not make the next Final Fantasy game, but you can make the next Tetris, the next Everyday Shooter, the next Spelunky!, the next Narbacular Drop. Look at the IGF winners, particularly the Student Showcase winners. Look at the best games from Global Game Jam or other high-profile events like it. Don't make a massive, sprawling game; make a small, tight, focused game that does one thing and does it well.

Genres to stay away from: RPGs, Sims, "open world" games, and anything else that is extremely content-heavy. A student team just can't churn out as much content as a large team grinding for years, so even if you manage to make a working engine (which in itself is questionable), at most it'll feel like a short demo -- several years of your life for ten minutes of gameplay is not a good use of your time. The only exception is if you can distill the genre to its core: an RPG playable to completion in 5 minutes, a Sim with only one action, an "open world" game that takes place within a single screen with no scrolling, or some other ridiculously simplified variant.

Overreach is an entirely separate problem, although it's often true that both problems manifest on the same projects. Overreach sounds like this: "Yeah, I've never designed a game before... and I only know a little programming... but I have this Great Idea for a game, and I'm sure I can figure it out if it means seeing my idea come to life."

Why is this a problem? First, some basic facts about game development:
Designing games is really hard, especially for someone who hasn't done it before.
Game programming is really hard, even for someone who knows "normal" programming, and especially for someone who knows no programming at all.
Making good-quality game art and audio are really hard, especially for someone who hasn't done it before.
Making an original game is really hard, even if you have done it before.

Combine any two or more "really hard" tasks, and it becomes a pretty much impossible task. This is the mistake that an overreaching student makes: they are trying to run without having learned to walk or even crawl.

The cure for overreach is patience. If your Really Great Idea is worth making, learn how to make it before you try to actually make it. If you're learning programming, then just learn programming -- program something that is already designed (i.e. a "clone" of another game), and that already has art (you can either use placeholder images like colored squares that you threw together in Microsoft Paint, or you can use free tile sets available all over the place on the Web). If you're learning game design, just learn design -- make a board game or card game, and stay far away from any kind of programming task. And so on.

Once you've built the development skills, one at a time, you'll be ready to put them together to make an original game. But jump in too early, and you will likely never finish.