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.
Subscribe to:
Post Comments (Atom)
5 comments:
Part of the reason why I'm leaning away from game design and more towards game theory is because of this. I know that I'm guilty of this on many parts. I'm worried that advice like this will discourage people from trying to make anything at all. People seem to become game designers because they have ideas that they want to see in reality. If you take away that motivation, then they won't be excited about being a game designer. I'd say it's better to have a project fail than to never have a project at all.
Then again, I'm always trying to do things I know I can't, so my perspective may be skewed.
@ inCobalt:
I actually see it as the other way around - better to have a successful project than a failed one. I'm not trying to dissuade anyone from trying, rather I'm giving my best advice on how to try in a way that gives the best chance of success.
For most students I've run into, it is hugely demoralizing to spend hours each week for months at a time only to abandon a project that collapsed under the weight of its own ambitions. It can feel like you'll never get that project working, and it's very easy to give up after something like that, especially if you've put a lot of hard work and effort into it already. Because you get to a point where you can't take it forward any more, but you also can't go back and start over because you'd be abandoning too much work, so the project is really dead.
Far better to save those great ideas for later, and bring them out again when you can do them... and in the mean time, concentrate on doing something you KNOW you can succeed at, and build up from there.
Yes, it's a slow process. There's no sexy "nothing-to-big-success" story here. But if you look historically at all of the really great student projects, the ones that win awards, I think you'll find that pretty much all of those students already had some idea of what they were doing ahead of time.
Your article is right on the nose. I had to complete a senior project course and I was put in a team to make a game for our final project, even though only two of us had some experience making a game. The project was based on a simple idea: FP survivor/horror game reminiscent of Condmned. But because of many objections from our professors about our direction the game ended up having to take place in the future, having to kill creatures and we had to incorporate a biofeedback device which would take data from the players heart rate and feed it into the game causing visual and auditory effects to change within the game and build up the horror. They expected us to learn an engine, program, and incorporate the device in a matter of 6 months. Needless to say the project fell through and I have to repeat the course this year in order to graduate. And what depresses me is that the professors still carry this mind set that students should be a jack of all trades when it comes to making any type of digital project whether it be games, animations, etc.
I believe in starting small, too. Start with just one fully-developed level, which you can finish in a few weeks. Then just add more levels and additional features as you go along.
We started doing this last year because you're right. Many of the former graduates abandoned their game projects.
I teach video game dsign to high school students in grades 9-12 they are competive and sometimes that works to my advandage. I beleive that each game desgin or in my case each of my student have a different motivation for building the games, and the effort they put forth is evident by the detail and quailty of their game. I do feel that they have to have small successes to not get discouraged. While encouaging them to build small games while planning and modifying their dream game they remain motivated to push toward the finish line.
Post a Comment