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 innova tive 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.