Become a Computer Game Developer: Working with Other People








Chapter 3






Working With Other People


Do lone wolves travel in packs?

In Chapter 1 we discussed some of the roles game
developers must play in order to bring a game to market. The fact is, very
few people are capable of playing all of those roles. So how many people
does it take to develop a game?
According to an ad for the Computer Game
Developers Conference (Miller Freeman):

At last count, it takes about 217 people
to design, produce and market a killer game.
I asked noted industry commentator Mark Shander about this, and his
response was:

Yeah, they're right... It takes up to 20
or so to do a game (depending on the time frame and the complexity of
the programming, artwork, etc.), 10 or so to market, publish and sell
it, and 187 to stand around, collect salaries and bitch about the stock
dropping. Yes, that's correct.
So clearly, the experts agree it takes a lot of people to build a game.

But what if you are not a lot of people? What if you are just starting
out, don't know anybody, can't get a job, and you still want to be a game
developer? What then?
I think you can go a long way on a game project without bringing other
people into it. You can design a game, you can write a game, you can even
market and sell a game, all by yourself. The only problem is, it probably
won't be a very good game. Even brilliant, artistic people who spend years
working on a game will have trouble producing a game that can compete with
a game developed by a team. Therefore, if you want to be successful as a
game developer, you should plan on eventually working with other people.

Typical Game Development Relationships






Employee
You work for them. They pay you. They
deduct taxes from your paycheck. You own no part of the game, and
you get paid the same whether the game succeeds or fails.


Contractor
You work for them. They pay you. You
pay your own taxes. If the game succeeds, you might receive
royalties, and if it fails, you may have trouble finding work next
year.


Partnership
Partnerships are good. Scott Miller and
George Broussard have a long-standing and successful partnership in
Apogee Software . If you can
make a partnership work, you are in good shape. Problems occur when
you get sick and tired of your partner goofing off and sticking you
with all the work.


Sole Proprietership

You take all the risks. You own all the
rights to the game. You try to hire people but can't pay them so you
promise them royalties which may or may not actually accrue.
Actually, this model works well when you do have enough money to
hire an artist and a musician, and pay them on a work-for-hire
basis, as I did on Diana
Gruber's 3D Casino Las Vegas.


Loosely-woven
team of high-school buddies all working on spec.
Nobody gets paid. Nobody has any money.
You live with your mom. When your mom complains, you tell her she
should be glad you didn't decide to start a rock band in her garage.

This model, believe it or not, actually works well for some
people. Low-budget, low-risk games produced by high-talent (though
sometimes inexperienced) teams can be very successful. Just be
careful. Remember you are swimming with sharks. Somebody should be
in charge of watching the business end of game development.
However you choose
to work as a team, it is important to understand who owns what part of the
game. Don't let legal issues bog you down, but do have a clear
understanding as to what each team member is expected to do, and what each
team member expects to receive.
A good source for self-help books on such things as software
copyrights, trademarks, and intellectual property ownership issues is the
Nolo Press . A cynical and
opinionated source of information on the business of game development can
be found in Chapter 4.











Click here to read about
Fastgraph for Windows.



Home Page | Contents
Chapter 1 | Chapter 2 | Chapter 3 | Chapter 4
Chapter 5 | Chapter 6 | Chapter 7 | Chapter 8
Glossary | Author | Books | Links Discussion




This site created and maintained by Diana Gruber .
Graphics designed by Susan
Kelleghan .

Copyright © 1997 Ted Gruber Software, Inc.
All Rights Reserved.