See this story on slashdot (
Why Being a
Computer Game Developer Sucks)
I don't agree with quite a bit of it but it was an interesting read.
First off I agree with the idea that making games is not all fun and
creativity. It's a ton of hard work. At this point in time, a couple
of months before Christmas I will generally be at work from 11am to 12am most of
time and often quite a bit more. Weekends probably more like 3pm to
11pm. This does bother me. I do often wish I had a job where I
had to work less. On the other hand I'm getting paid very well. Much
better than your average non game programmer and according to a recent article
in GameWeek much better than your average game programmer.
His article reminds me of an article in this month's LA Magazine about an
actor that committed suicide. The article goes on to tell about how tough
things are in Hollywood with nearly a parallel for everything in Talin's
article. Things like stupid managers, crazy schedules, only a very few
making most of the money etc. My response to that part of Talin's message
would be, "So what, Just like the movie industry, music industry, book
industry, comic industry etc only a very few people are successful. You
should have known that before to started and if you didn't that's nobody's fault
but your own. Deal with it or get out." People are in
this industry for many of the same reasons they are in the others above.
They love the particular topic, and for fame and fortune and just like the other
industries the fame and fortune will only come to a very very few.
As for specific points:
1) It amazes me to find managers who have copies of classic works like Rapid
Development_, _Writing
Solid Code_, and _Peopleware_
on their bookshelves, yet somehow fail to actually apply the principles in those
books.
I've read these books and applied them to one of my projects. It was
the worst project I ever worked on. The problem is those books were
written for average programming. In other words things like writing
databases, applications, compilers, bar code readers, web browsers, operating
systems, etc etc. Those are completely different beasts from games.
Why? Because games are about the ART of creating something that is fun and
ascetically appealing. That means that an artist, game designer and
program need to often sit at the a computer together and trying out tens or
hundreds of variations on something. Example: you're making a character
action game and you need to fine tune the jumping action. The game
designers says, "make it go a little farther...Okay, now a little
higher. Okay, now how about sliding a little after landing....Oh that
really doesn't feel quite right. How about making the whole action a
little faster." Then the artist might say, "when he's about half
way up the jump could you tilt him back 30 degrees? Hmmm, okay after that,
from half way up to half way down rotate him forward 50 degrees. Now, when
he hits the ground scale him in Y to 50% and in X to
150%." etc. etc. Making games, or at least good games, is a
super interactive and iterative process and if you go read those books above you
will see that none of them cover this. Why, because they are all concerned
with "average programming". In making a compiler for example, it
is relatively easy to write on paper what features you want and how they should
work. You then hand that spec to a programmer and for a couple of weeks or
months he sits in his office with no need of interaction with
anybody. It is not easy to write on paper how to make a jump feel
good and look good. These books tell you to spec out everything in
detail yet as you can see that's nearly impossible. They tell you things
like all programmers need there own office. Yet putting everybody in their
own office discourages that interaction and iterative processes of tuning a
game's feel and look.
I'm not saying there is nothing of value in those books but they do not
generally fit making games. I'm also not saying that you shouldn't have an
achievable schedule with realistic deadlines. Which brings up
2) The whole process by which games are budgeted and scheduled, for
example, is something that I find amazing that anyone could take seriously.
It is true that most game companies budgeting and scheduling abilities leave
alot to be desired. Still there are companies that know how to do
it. Naughty Dog, the company that I'm at now has not missed a deadline in
4 years. Sega of Japan with over 400 people in their arcade software
development department almost never misses a deadline.
What do these companies have in common? One is they they don't hire
people who suck. I've worked at about 10 different game development
companies and that's a pretty uncommon thing I will admit. Most companies
don't realize that bad people make bad late products.
Another is that they don't have producers (managers) that aren't actually in
production. Actually in neither company is there the title of
"producer". At Sega of Japan there is the
"planner" The planner is the game designer and project
manager. His job is to design the game as a part of the team and supervise
and approve all parts of it. When something is drawn or coded he's the guy
you ask, "Is this what you wanted?" He often hands out diagrams
and sketches of what he needs you to draw or implement.
This is as opposed to the producers found in most game development companies
which basically sit at their desk 4 days a week and play games and then once a
week ask the team how they are doing and give unwelcome advice and then report
to upper management what they think is going on.
My point is if this describes your situation quit and go work for a better
company.
3) I should also mention that the games industry has little respect for
experience
This is patently not true. If it were true there would be no agents
and/or headhunters of which there are quite a few in this industry. The
games industry has no respect for experience they deem as not useful. If
they do find your experience useful you will get the job. If you've
shipped several successful hit games using current technology you will have no
problem finding a job. I'm sure people like Sid Meier, John Carmack, Brian
Hook, Sandy Peterson and a host of others could get a job almost anywhere
because of their experience. On the other hand somebody who has only
written some mediocre 2d games several years ago is going to find their
experience is no longer considered useful.
4) Failed Products
Talin says there are lots of reasons for failed products. Crappy
products, crappy marketing, crappy distribution, crappy placement at the stores
etc.
But, ultimately it usually comes down to the fact that not enough people
wanted to play your game. Especially in this day and age when you can put
your game up just by uploading it to some file website. If your game is truly
something tons of people get addicted to it will spread around this new wired
world. If on the other hand people don't want your game nothing is going
to make them want it.
The perfect example of this is the Sony product "Ape Escape".
It's a great game. It's polished, well done, reasonably fun to play, it's innovative
and it's had a huge multi-million dollar marketing campaign and great
distribution and placement in stores. It's even received tons of super
great reviews in the various gaming magazines. In spite of all of that,
for whatever reason, people are not buying it. People just either don't
want another character action game, or they don't want one about a kid with a
net catching monkey's. They do want a very tedious and non innovative game
about walking around an catching little monsters. Why? If I knew I'd
retire.
I agree that people think that making a game is 100% fun. From personal experince, its fun untell your ideas are laid out and you gota stay up from morning to night coding or doing whatever. Well I don't have much time to keep explaining but, most of his points are vaild to me, some not as much as others.