You've been thinking about it for years.  You can't help it.  You know you have what it takes.  And above all, you know that the jobs which are out there, inside or outside of the gaming business, are never going to provide you with the challenges and the opportunities that you crave for and deserve.  So you prepare for the big day, and you wait.  It isn't easy, but you save a little money, gather a team whom you believe will be able to carry a schedule, and you go into business for yourselves.

Every year, hundreds (maybe thousands) of groups of people just like you make the same decision.  Some of them make it big.  Most fizzle within months and are never heard from again.   To you, that would be a fate worse than death.  So how do you avoid it?

There are no golden paths to game development stardom, but there are many, many tempting roads leading right into the abyss.  Here are just a few of them.  Trespass at your own peril.

#1 - Choose the wrong product

In the last year alone, I have met with at least 20 development startups.  Of these, all but three were working on run-of-the-mill, multi-player first-person shooters for the PC.  And one of the three has since dropped its (rather original) project and switched to a standard FPS.

Depending on who you listen to and on your definition of a commercial release, there are between 1,200 and 3,000 PC games released every year.  In recent years, several hundred of these (at least) have been either first-person shooters or real-time strategy games.  Knowing this, and knowing that Carmack and the guys from Valve and Blizzard and Westwood have been monopolizing the top of the charts for years and aren't going anywhere anytime soon, I would avoid those genres like the plague.  Unless, of course, I could find a very unusual angle to differentiate my product from the pack.  Needless to say, none of the 15+ groups I mentioned earlier came close to that.

Be realistic.  Odds are you won't ever be able to outcode Carmack.  Your chances of coming up with the #1 shooter of the year while he's alive are slim at best.  Betting your future on it is ridiculous.  And even if there is a market for, say, 5 great FPS games in the same year (a risky proposition), there are hundreds of other teams going after that tiny slice of the pie.  Might want to start looking for another pie, huh?

Going head-to-head with a crowd is not the only way to destroy your company.  I know of a small development house which once spent years developing a hockey game for the PC, and then decided to go up against EA Sports without a license from the NHL.  Somehow, they survived despite sales of about 5,000 units (most of them at liquidation prices), but not without skipping a payday or two (or ten).  I also once met a group of moderately talented kids who spent months on what is essentially an (unplayable) air hockey game in a tube, where you try to hit an old guy's head past the opponent instead of a puck.  How they could ever think for one second that they were going to make it to retail with that kind of junk is beyond me.

The bottom line: "Market research" and "originality" are not dirty words, people.

#2 - Turn the company into a soap opera

Game developers are like simple chemicals.  (No, not because they're cheap and smelly.)  In the right combination, they can make miracles.  Screw up the mix, and you can blow up a city.

There are many ways in which human resource snafus can lead to disaster.  Witness the following horror stories:

• Cat Herding Syndrome: You put together a team of highly qualified pros, but they can't get along.  Within months, they spend more time in the conference room plotting office coups against each other than working on the game.  Project collapses.  (See ION Storm for details.)
• Prima Donna Syndrome: You have one guy on the team who can't work with anybody else, but you keep him around because you think he's irreplaceable.  This sort-of happened to me once: my predecessor at Company X had actually recruited the lead programmer for our online game straight out of jail.  He got along fine with everyone as long as we never tried to check up on his progress or set a deadline; then he went ballistic.  The project ended up 300% over budget, never saw the light of day, and the guy skipped town with the source code.  We would have been a LOT better off getting rid of him quickly and training someone else to take over his duties; no one is good enough to justify that kind of aggravation.
• Misplaced Greed Syndrome: A bunch of 3D artists get together to develop an adventure game.  Only problem is, they can't afford both the hefty salaries they want for themselves AND real programmers, so they make do with amateurs.  Project collapses.
• Unstoppable Inertia Syndrome:  At my first game job, we had one programmer who was so unbelievably bad it wasn't even funny anymore.  Any project assigned to this guy, however trivial, would take 5 times longer than expected and would ship with a feature set cut in half.  He would SCREAM at the computer for hours every day, disrupting the whole team's work.  I caught him snoring on business hours, loudly, more than once.  Better yet: since it was a union shop (!) and he was quite old for a game programmer, he was one of the highest paid people on staff!  After a while, everyone else wanted his head on a stick, morale plummeted, and productivity followed.  However, the boss was a very nice guy who detested conflict, so he couldn't bring himself to fire the punk, who kept his job for over four years.

Don't be afraid to hire a professional recruiter.  The good ones are invaluable.

And a final word of advice: be honest when you are interviewing people.  If you have a mandatory unpaid overtime policy, say it.  If you have no intention of growing beyond a single project team or to promote from within, say it.  It might make recruiting more difficult, but you won't get much good work out of people you lure to your company through false advertising, either.

#3 - Choose the wrong license

The right license can mean 50,000 extra copies of a pretty good game, or in some cases 200,000 extra copies of a great one.  But not every license is created equal.  Buy a license to a fad, let the product slip two years behind schedule, and you'll have a worthless product on your hands.  Spend $100K on the rights to a box office bomb, and you'll kick yourself all the way to the soup kitchen.

A while ago, I was approached to design a game based on a superhero.  The character is very cool, and I had no trouble coming up with numerous ideas for a kick-ass game.  However, the intellectual property holder insisted that we add absolutely NO content to the hero's universe and not contradict anything that had been published in the comic book (which made all of the interesting bad guys, long dead in the series, off-limits).  I was almost glad we didn't get the assignment, because the game we would have been able to turn out in these circumstances would have been a disgrace to the character's legacy.  What little I heard about the project that was finally approved confirmed my worst fears.

#4 - Assume that anyone can design a game

Listen, and listen carefully: Running a basement Dungeons & Dragons campaign for 6 months in high school does not qualify anyone to design complex entertainment software.  Beware of the frustrated programmer or artist who starts his own company because no one at his existing job ever listens to his brilliant ideas: there may be a reason why no one listens.  (Also beware of people who sneer at designers because they don't code or can't animate: design is a very difficult job, and requires far more skill than most developers are willing to admit.)

Sure, some people get the knack of game design the very first time.  (I have met one.  Operative word: One.)  Most people don't.  "Most" means: you are probably one of them.  Do NOT overestimate yourself.  If you want to become a game designer, work with a pro, and learn your trade.  Otherwise, you may get a nice trip to Egoland, but you won't get a game.

I have seen companies waste months of development because the boss kept interfering in areas far beyond his competence.  I have seen a BRILLIANT development team go absolutely nowhere because their outstanding graphic and AI technology was wasted on a non-game some hack had come up with in an afternoon, thinking that great looks would be enough.  Don't make the same mistake.

#5 - Assume that people will accept lower salaries to work in game development

It's a fact of life: game development salaries are typically lower than in other fields of the software industry.  Companies involved in networking solutions or business software usually require college degrees (and they make profits), while game studios are still, by and large, seat-of-the-pants operations.  Therefore, they can (and must) pay less.  However, I believe that this "fact of life" is about to become history.

Game development is getting more and more complicated every day.  Writing cutting-edge software for the PSX2 *is* rocket science, and it will require the very best and brightest programmers and artists in the world.  Now, these people can be separated into two categories: those who can't imagine working outside of game development, and those who can.  As long as we could get by with only the first group, we could keep wages down.  As the industry grows, it will require more and more people from Group #2, and to get them, it will have to match the salaries and benefits paid by the Intels and the Lucents and the Lucasfilms of this world, because, as a job applicant pointed out to the PHB in a Dilbert cartoon, smart people are not often actively looking for pay cuts.

So, unless you are willing to settle for naive, inexperienced, second-tier developers, don't budget too low.

(Besides, you'll probably be better off with one really good guy making $100,000 than with two mediocre ones making $40,000 apiece.)

As a corollary, do not expect top people to accept lower salaries in exchange for bonuses and cuts of eventual profits.  Some risk-takers might be willing to go for it if the potential rewards are high enough (and I do mean HIGH), but savvy developers know that a) very few projects, even the high-profile ones, actually make enough money to pay for bonuses and profit sharing, b) accounting can be quite creative when it comes to profit sharing plans, and c) why would they take your $50K + $20K bonus package when they can get $75K guaranteed elsewhere?

#6 - Take too many risks

This is a tricky one.  These days, you can't get a publishing contract without a 50-70% finished product, and you can't get capital to look at you without at least an impressive demo.  So, if you are starting out, you have to spend some time and effort on a product that may never be funded.  That's a risk you can't avoid.

But that's as far as you should go.  Once you are satisfied with your demo, stop working until you have the people and the resources to FINISH development.  In the meantime, find a job elsewhere if you have to.  Running out of money 75% of the way into a project will never get you anywhere.  At best, you'll sell the project at a substantial discount to save the company.  At worst, you'll lose your house and your health.  Never underestimate the psychological and physiological effects of financial trouble.

#7 - Too much management

Let's face it: game developers are unruly, undisciplined, opinionated folks.  You'll have enough trouble imposing whatever structure you really need without going off on power trips.

For example, development studios are chronically messy.  Artists need room to draw, programmers must have books and listings all over the place, and office space is pricey, so there is never enough room for everything, and stuff will pile up.  It's a fact of life.  Now, that doesn't mean that you should let your studio turn into a fire hazard, but it does mean that forcing everyone to shove their stuff into boxes once a week for inspection is both useless and offensive.  Another example: project-management software really shouldn't be able to specify task durations in increments of less than one day; if something takes 30 minutes to do, there is no need to keep track of it in a time sheet.

I have seen near-riots sparked by over-eager managers planning on imposing daily meetings, factory-style hiring/layoff cycles and even (gasp) dress codes and regular working hours.  Sure, "the way things are" might seem inefficient, but sometimes inefficiencies are a good thing, no matter what they tell you at graduate business school.  (I know; I've been there.)  Remember: small victories now may come at the price of disaster later.

#8 - Not enough management

On the other hand, the days of "creative chaos" are gone.  What we do isn't hacking anymore; it's software engineering.  When you program an engine for 3-6 products, the code has to be a lot more robust and general than it was back when we erased everything from the hard drive two days after release.  And when there are 30 people working on the same product, someone has to keep track of which of the 3,000 asset files are final and which are place-holders.

Beginners often try to make do without producers, saying that they don't need oppression to get the job done.  Well, they may not need oppression, but a clear idea of where they are going is still a pretty handy tool.  I know of a team that wasted a whole year of effort because they had no change control policy, which let different programmers make incompatible on-the-fly architecture decisions while a bored designer ran amok and rewrote everything several months into production.  And I still have nightmares about a certain project which was supposed to turn gold two weeks after I was hired as head of studio at Company A: the producer had implemented no quality control policies, all of her experienced staff had left and been replaced by newbies, nobody had bothered to check up on the work, and as a result this six-month project was only completed at the cost of a seven-month red-eye marathon and a major feature hatchet-job.

#9 - Believe the clichés

No matter what the press say, do not assume that you have to be id or Blizzard to be successful.  You might think that the elusive Holy Grail of retail is the only way to become a "real" developer.  Not so.  Some people out there make quite a good living writing small games for internet portals, edutainment, shareware or even the dreaded hunting games which terrorize the editorial staff at your favourite gaming magazine.

There are many, many opportunities in entertainment software that have never been properly exploited.  If you have the guts, try to come up with software for the elderly, or for the stay-at-home mom.  We did, for a cable set-top box, back in the early to mid 1990's.  These games made a viable platform out of a brown box with an 8-bit CPU, 20K of memory and a crappy remote, which you had to rent (at 8$ a month) to be able to get pay-TV or PPV.  There are still over 100,000 of these units in the field today.

Hey, the PC version of Who Wants to Be a Millionnaire sold close to 600,000 copies in one month during the 1999 Christmas season.  That's more than Baldur's Gate, Half-Life and Tiberian Sun did in the entire year.  (In fact, according to PCData, only Roller Coaster Tycoon and Sim City 3000, neither of which feature exploding intestines, sold more copies in 1999.)  And I bet it didn't cost $3,000,000 to produce, or require the 3D programming skills of a minor deity, either.

#10 - Assume that you need the best of everything

This is the most difficult thing in the world to do: decide when enough is enough.  If you want the best AI, best 3D, best networking technology, best music, 3D sound and support for every nifty input peripheral in the world, you'll spend $10,000,000 and die of exhaustion long before your game is ready to ship.

In all likelihood, your means are limited.  Therefore, you must decide early on which unique selling points (USP) you can't afford to give up, which would be nice to have if you have time and money left at the end of the project (you probably won't), and where you can get by with a journeyman's effort.  If you are doing a shooter, you probably don't need to equip your zombies with neural networks and hidden Markov models to learn the player's behaviour.  On the other hand, for a turn-based strategy game, you don't need dead-reckoning to predict opponents' positions, and since network lag is not critical, a standard DirectPlay layer is probably enough.

Know where to save, and you'll have more to spend on what counts.  (And by the way: multi-player is a feature like any other.  It costs time and money to implement, and with everybody going after the deathmatch crowd, you might do well to ditch the networking and release a really good single-player game!)

Conclusion

Game development is rewarding work, but it is tough work.  Believe me, there is no need to make it any worse than it needs to be.  Hopefully, this article will help you make it a little easier on yourselves!

François-Dominic Laramée, January 2000

Discuss this article in the forums

Date this article was posted to GameDev.net: 2/1/2000
(Note that this date does not necessarily correspond to the date the article was written)

See Also:
Running your own Game Company

© 1999-2011 Gamedev.net. All rights reserved. Terms of Use Privacy Policy
Comments? Questions? Feedback? Click here!