[MUD-Dev] [BIZ] HOW TO SCREW UP A PERFECTLY GOOD GAME COMPANY IN TEN EASY STEPS

[Michael Tresca]

From: http://www.gignews.com/fdloriginalten.htm

Mike "Talien" Tresca
RetroMUD Administrator
http://michael.tresca.net

--<cut>--
HOW TO SCREW UP A PERFECTLY GOOD GAME COMPANY IN TEN EASY STEPS
by Francois Dominic Laramee

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 cliches

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!
--<cut>--
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev