|
1 November 2000
Originally published January
2000...
HOW TO SCREW UP
A PERFECTLY GOOD GAME COMPANY IN TEN EASY STEPS
by
François
Dominic Laramée
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 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.
- 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 long 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 face, 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
Ready for 10 more? Come
on over...
>>>
20O2 UPDATE!
|
