Jason Della RoccaIt's fairly well known that, as a whole, the game industry is prety immature on several levels. Jason Della Rocca discusses how immature production practices and poor quality of life are bankrupting the game industry.
Issue 40 - Friction Costs
- Thread starter The Escapist Staff
- Start date
Original Comment by: plusnine
http://http//plusnine.buhananrecords.com
I hope wal-mart moves into the online game arena. imagine a Deer Hunter spinoff called Quail Hunter so realistic that you can turn to your left and shoot another player in the face with your shotgun. before the game's 3-D engine can render a drop of blood you'll be tackled by ploygonal secret servicemen into an SUV. now THAT's entertainment.
http://http//plusnine.buhananrecords.com
I hope wal-mart moves into the online game arena. imagine a Deer Hunter spinoff called Quail Hunter so realistic that you can turn to your left and shoot another player in the face with your shotgun. before the game's 3-D engine can render a drop of blood you'll be tackled by ploygonal secret servicemen into an SUV. now THAT's entertainment.
Original Comment by: Patrick
Great article, I'll definetly apply a lot of this wisdom when my company is seeing enough money to hire people. Rapid prototyping is a very crucial methodology I'm employing on my current project, even though I think my design is fairly tight on paper, its true that you can never know until first playable. Better sooner than later, right?
I'd like to get to a point where I can spend a million dollars on a project, but for now its more like spending 30K (the dev kit, my team is tiny and we pay the bills through other work) to make a million. Unfortunately, if the game does gross a million, I'll only see a tenth of that or less. But thats another article.
Great article, I'll definetly apply a lot of this wisdom when my company is seeing enough money to hire people. Rapid prototyping is a very crucial methodology I'm employing on my current project, even though I think my design is fairly tight on paper, its true that you can never know until first playable. Better sooner than later, right?
I'd like to get to a point where I can spend a million dollars on a project, but for now its more like spending 30K (the dev kit, my team is tiny and we pay the bills through other work) to make a million. Unfortunately, if the game does gross a million, I'll only see a tenth of that or less. But thats another article.
Original Comment by: Mark
I'd have appreciated a little bit more detail into the way the industry treats its developers, but in all a very insightful article. I approve.
I'd have appreciated a little bit more detail into the way the industry treats its developers, but in all a very insightful article. I approve.
Original Comment by: george
Great article and there is lots to do but one thing I'd really like to get clear. GAME DEVELOPMENT IS NOT SOFTWARE DEVELOPMENT, It is Entertainment. 70% of most teams are artists. Our job is not to follow a functional spec, our job is to create entertainment.
Those parts of the process that are software development may benefit from software development practices but trying to shoehorn a process that is fundamentally not software development into a software development style is bound to fail.
Do you think Spielberg follows SCRUM and Pair Directing as he makes his movies? I doubt it. To me, games are about a game director (and his team) expressing themselves through games to make entertainment similar to a movie director. All entertainment works this way, music, movies, books and games. Creative processes like movies IMO would never work through some forumlaic system.
It's precisely that creative process which makes making games fun and enjoyable. Convert it to SOFTWARE DEVELOPMENT and it will turn into just a boring job where I punch in from 9 to 5 and fulfill the functional specs on my scrum goal list. Yuck.
Great article and there is lots to do but one thing I'd really like to get clear. GAME DEVELOPMENT IS NOT SOFTWARE DEVELOPMENT, It is Entertainment. 70% of most teams are artists. Our job is not to follow a functional spec, our job is to create entertainment.
Those parts of the process that are software development may benefit from software development practices but trying to shoehorn a process that is fundamentally not software development into a software development style is bound to fail.
Do you think Spielberg follows SCRUM and Pair Directing as he makes his movies? I doubt it. To me, games are about a game director (and his team) expressing themselves through games to make entertainment similar to a movie director. All entertainment works this way, music, movies, books and games. Creative processes like movies IMO would never work through some forumlaic system.
It's precisely that creative process which makes making games fun and enjoyable. Convert it to SOFTWARE DEVELOPMENT and it will turn into just a boring job where I punch in from 9 to 5 and fulfill the functional specs on my scrum goal list. Yuck.
Original Comment by: CMMI5 and hacking away
Oh gimme a break George, you're expressing one of the biggest misconceptions I've heard from some people in the game development community
Sure, go ahead and look down on professional engineering practices as somehow not applicable to game development. Such an artiste...
I will grant you that having a formal "process" does NOT guarantee quality. For example being rated CMMI5 doesn't mean you make good products, it just means you passed a test. However, having a disciplined mindset when you approach your development, having decent processes in place, AND then adhering to those processes is a big help. Next you're going to say that you're too busy coding to worry about creating a requirements document.
First off, the LACK of any formalized development practices are probably the biggest failure of the industry... and I'm not talking about using a CM tool, which obviously most developers have mastered. That's not really rocket science. I'm talking about stepping up a notch where people actually use better project management skills in all areas of game development, not just software. WTF else would we be hearing about games suddenly switching from 3rd person to an FPS perspective in midstream? Or shipping without multiplayer support. Uhhh, that's not really a software issue, it's a failure to identify key UI or technology requirements, track risks, and mitigate them early.
But that's OK, I get the same attitude from our systems engineers. They don't "get" the whole define-how-your-system[game]-works-before-you-write-the-code part. What's their product? Oh yeah, a Word document. Doesn't have to be logically consistent, or god forbid actually execute. If you could, it would delete its own source out of embarrasment and then core dump.
Oh gimme a break George, you're expressing one of the biggest misconceptions I've heard from some people in the game development community
Sure, go ahead and look down on professional engineering practices as somehow not applicable to game development. Such an artiste...I will grant you that having a formal "process" does NOT guarantee quality. For example being rated CMMI5 doesn't mean you make good products, it just means you passed a test. However, having a disciplined mindset when you approach your development, having decent processes in place, AND then adhering to those processes is a big help. Next you're going to say that you're too busy coding to worry about creating a requirements document.
First off, the LACK of any formalized development practices are probably the biggest failure of the industry... and I'm not talking about using a CM tool, which obviously most developers have mastered. That's not really rocket science. I'm talking about stepping up a notch where people actually use better project management skills in all areas of game development, not just software. WTF else would we be hearing about games suddenly switching from 3rd person to an FPS perspective in midstream? Or shipping without multiplayer support. Uhhh, that's not really a software issue, it's a failure to identify key UI or technology requirements, track risks, and mitigate them early.
But that's OK, I get the same attitude from our systems engineers. They don't "get" the whole define-how-your-system[game]-works-before-you-write-the-code part. What's their product? Oh yeah, a Word document. Doesn't have to be logically consistent, or god forbid actually execute. If you could, it would delete its own source out of embarrasment and then core dump.
Original Comment by: CMMI5 and hacking away
Not to be completely inflammatory... Don't take this as a slam of the "game" developers vs the "real" software industry because what I've seen of corporate America says it's no better at following good development practices. However the expectation on crunch time is just much less. So we're allowed to produce our crap in 40 or 50 hours, not 60 or 80.
Not to be completely inflammatory... Don't take this as a slam of the "game" developers vs the "real" software industry because what I've seen of corporate America says it's no better at following good development practices. However the expectation on crunch time is just much less. So we're allowed to produce our crap in 40 or 50 hours, not 60 or 80.
Original Comment by: Jare
http://www.iguanademos.com/Jare
I must agree with the previous poster in the idea that game development is NOT the same as software development. Creative work doesn't follow the same rules as engineering; one deals with the unknown (what's creative about building something that already exists?), the other with the known (and how to build it more efficiently). Engineering is a very important part of the effort, but let's not kid ourselves that we can apply engineering principles to the whole task of creating a game - we might end up just swinging the pendulum over to the other side. In fact, with all this gloom and doom about the death of creativity in the games industry, I'd hate to think that in our effort to improve work processes, we end up contributing to that other problem.
I disagree with the emphasis on laziness as the driving factor in our less than optimal. It seems that the game industry is in a state of almost perennial crisis. In such atmosphere, few people can afford the long-term commitment to improving work standards (processes and QOL issues). From this armchair, it's easy to point at all the mistakes and short-sightedness prevalent in development studios, but when you have the proverbial Sword Of The Failed Milestone hanging over your head, long-term benefits at the cost of short-term risks may not be the best idea.
At Harvey Smith's "Creative Directors" roundtable this past GDC, I took a mental note of the fact that when discussing about recruitment, all that is required from a newbie game designer is "potential", whereas there were many if's and doubts when discussing designers with a curriculum: if he's not burnt, if he can adapt, if he can learn, if he can accept, if he can... The point I'm trying to make is that, evil as CEOs may be, they are not the only factor in driving experienced talent out of the games industry.
http://www.iguanademos.com/Jare
I must agree with the previous poster in the idea that game development is NOT the same as software development. Creative work doesn't follow the same rules as engineering; one deals with the unknown (what's creative about building something that already exists?), the other with the known (and how to build it more efficiently). Engineering is a very important part of the effort, but let's not kid ourselves that we can apply engineering principles to the whole task of creating a game - we might end up just swinging the pendulum over to the other side. In fact, with all this gloom and doom about the death of creativity in the games industry, I'd hate to think that in our effort to improve work processes, we end up contributing to that other problem.
I disagree with the emphasis on laziness as the driving factor in our less than optimal. It seems that the game industry is in a state of almost perennial crisis. In such atmosphere, few people can afford the long-term commitment to improving work standards (processes and QOL issues). From this armchair, it's easy to point at all the mistakes and short-sightedness prevalent in development studios, but when you have the proverbial Sword Of The Failed Milestone hanging over your head, long-term benefits at the cost of short-term risks may not be the best idea.
At Harvey Smith's "Creative Directors" roundtable this past GDC, I took a mental note of the fact that when discussing about recruitment, all that is required from a newbie game designer is "potential", whereas there were many if's and doubts when discussing designers with a curriculum: if he's not burnt, if he can adapt, if he can learn, if he can accept, if he can... The point I'm trying to make is that, evil as CEOs may be, they are not the only factor in driving experienced talent out of the games industry.
Original Comment by: balance
This is an issue that has been on my mind for years and I aggree with the sentiments expressed. However, I certainly read the stats provided with a grain of salt -- ie. 1000% ROI, what does that mean? Ten times the productivity out of a team because they built UML diagrams? Sounds iffy to me.
Personally, my teams are moving to detailed capacity planning and more formalized review processes etc. However, none of that will ever change the fact that as you near the end of a project, good ideas come up and regardless of the fact that everyone knows that it will increase the work load, they also know that in the end the product will be better and hopefully sell more units and therefore that feature gets added. Yes, we try as hard as possible to design and plan as best we can, but in an industry where the number two product gets 40% the revenue of the number one product in any given genre, there will always be a "crunch time". Our goals should be to fully understand what decisions we make and to ensure that work-life balance is a criteria of the decisions. I want crunch time to be about a last sprint towards quality, not a death march to squash enough bugs to pass certification.
This is an issue that has been on my mind for years and I aggree with the sentiments expressed. However, I certainly read the stats provided with a grain of salt -- ie. 1000% ROI, what does that mean? Ten times the productivity out of a team because they built UML diagrams? Sounds iffy to me.
Personally, my teams are moving to detailed capacity planning and more formalized review processes etc. However, none of that will ever change the fact that as you near the end of a project, good ideas come up and regardless of the fact that everyone knows that it will increase the work load, they also know that in the end the product will be better and hopefully sell more units and therefore that feature gets added. Yes, we try as hard as possible to design and plan as best we can, but in an industry where the number two product gets 40% the revenue of the number one product in any given genre, there will always be a "crunch time". Our goals should be to fully understand what decisions we make and to ensure that work-life balance is a criteria of the decisions. I want crunch time to be about a last sprint towards quality, not a death march to squash enough bugs to pass certification.
Original Comment by: anonymous
I I can understand why upper management feels the need to force their employees to burn the candle at both ends (short term benefits) but the fact remains that the first person with talent who figures out what kind of ROI can be realized through improving workplace conditions and retaining a committed core of developers over the long term is going to _completely_ _blow_ _away_ the competition.
Middle management is paid to think short term.
Upper management should be paid to think long term.
Sure, it's an oversimplification but it illustrates a point. If middle management is thinking so short term that they're willing to use up talented developers and drive them to the brink of madness, isn't the indication that the wrong pressures are being placed on them by upper management?
I I can understand why upper management feels the need to force their employees to burn the candle at both ends (short term benefits) but the fact remains that the first person with talent who figures out what kind of ROI can be realized through improving workplace conditions and retaining a committed core of developers over the long term is going to _completely_ _blow_ _away_ the competition.
Middle management is paid to think short term.
Upper management should be paid to think long term.
Sure, it's an oversimplification but it illustrates a point. If middle management is thinking so short term that they're willing to use up talented developers and drive them to the brink of madness, isn't the indication that the wrong pressures are being placed on them by upper management?
I don't know, I think it's a problem with American culture at large. There's a definite "If you're not working 12 hours a day, you're not REALLY WORKING HARD!" ethos in this society, and it's not just software engineering. Unfortunately, I don't have a solution.
Original Comment by: Tired of the Talking Heads
This article is classic JDR... shooting off his mouth about game development as if he's qualified to do so. What's the last game you shipped Jason? Oh, right, I forgot, you don't make games, our IGDA pay your salary so you can lecture us about how bad everything is.
I wish the talking heads and publicity magnet types would find another field to grandstand in, and let those of us who make games for a living do that.
This article is classic JDR... shooting off his mouth about game development as if he's qualified to do so. What's the last game you shipped Jason? Oh, right, I forgot, you don't make games, our IGDA pay your salary so you can lecture us about how bad everything is.
I wish the talking heads and publicity magnet types would find another field to grandstand in, and let those of us who make games for a living do that.
Original Comment by: Jeff
I agree with most if not all of this article, much of which has irritated me from the beginning?That is, when I started in the gaming industry after spending most of my time in the application software development industry.
I was happy to see the "Game Development is not Software Development" argument was here in the comments. This is also a source of irritation. I believe the two issues are directly related. Some game team staff, to include producers, like to think they are developing something that isn't software and therefore shouldn't even consider the tried and true processes of the software industry. Why? Well in my opinion I think many are scared that they will lose their ?artistic freedom? and control within their own products/projects. If the industry starts adopting practices that these individuals are ignorant toward, these individuals will be minimized.
On that note, how exactly is game development different from software development and how would a majority of those in the industry even know?
Creating an art asset is part of the whole package of an entertaining game, just like creating functional GUI art is to a software application. Project managers, programmers, designers and artists all work together to provide a visually appealing, interactive and entertaining piece of software just like Project managers, programmers, designers and artists all work together to provide a visually appealing, interactive and functional piece of software.
Lastly, I think it?s safe to say that the article was about programming and design staff, their quality of life and more efficient project management. If you have a staff that consists of 70% artists, I doubt those are the people spending 80 hours a week at the office. The people getting abused are the programmers trying to make combat systems, physics and content systems work -- so the customer can actually see the art assets that were created.
At least a decade of research and proven methods for software development shouldn't be cast aside when we have the ability to barrow these same methods and mold them into processes that work for our industry. Stop being a gaggle of prima donnas. Look for similarities, not differences.
I agree with most if not all of this article, much of which has irritated me from the beginning?That is, when I started in the gaming industry after spending most of my time in the application software development industry.
I was happy to see the "Game Development is not Software Development" argument was here in the comments. This is also a source of irritation. I believe the two issues are directly related. Some game team staff, to include producers, like to think they are developing something that isn't software and therefore shouldn't even consider the tried and true processes of the software industry. Why? Well in my opinion I think many are scared that they will lose their ?artistic freedom? and control within their own products/projects. If the industry starts adopting practices that these individuals are ignorant toward, these individuals will be minimized.
On that note, how exactly is game development different from software development and how would a majority of those in the industry even know?
Creating an art asset is part of the whole package of an entertaining game, just like creating functional GUI art is to a software application. Project managers, programmers, designers and artists all work together to provide a visually appealing, interactive and entertaining piece of software just like Project managers, programmers, designers and artists all work together to provide a visually appealing, interactive and functional piece of software.
Lastly, I think it?s safe to say that the article was about programming and design staff, their quality of life and more efficient project management. If you have a staff that consists of 70% artists, I doubt those are the people spending 80 hours a week at the office. The people getting abused are the programmers trying to make combat systems, physics and content systems work -- so the customer can actually see the art assets that were created.
At least a decade of research and proven methods for software development shouldn't be cast aside when we have the ability to barrow these same methods and mold them into processes that work for our industry. Stop being a gaggle of prima donnas. Look for similarities, not differences.
Original Comment by: Jon
I read this site out of interest as both gamer and a programmer, though the programming I do isn't games. I'm a huge fan of formalized design and implementation process. That's how my CRM project team changed a typical 9-to-7-and-then-9-to-midnight day into a more manageable 9-to-5.
Identify a feature as fundamentally stupid, flawed, or impossible?
ROI: you don't waste the time coding, debugging, trying to salvage wasted effort. You may be able to refine the feature without wasting time implementing it the bad way first.
Identify a cleaner, easier, simpler way to implement a feature?
ROI: less code means better performance, portability, less time spent debugging. If someone else has to look at the code for your feature they'll get up to speed more quickly.
Identify functionality you can add to a feature free or with minimal effort?
ROI: your feature's better.
Identify all your integration points and solve API snags before anyone's written a line of code?
ROI: API changes waste time, more or less depending on your programming language and the importance of the change, and are often a headache in source control.
Figure out everyone's tasks and timelines before implementation starts?
ROI: no developers blocked on code that someone else hasn't written up yet, no resource-allocation panic as the deadline looms and you're trying to split outstanding tasks up and assign the parts to unfamiliar developers. Even if it does come down to that, at least the new developer's got an authoritative design doc for reference.
Planning for shorter work days?
ROI: Happy, less-stressed programmers care more about the app (game in your case) they're working on. They use fewer ugly hacks to make things work, and introduce fewer bugs from programming while sleep-deprived. They don't turn a blind eye on bugs and flaws in order to get their feature complete, and can take a little extra time to fix it.
1000% ROI... can adding one day of feature scoping, detailed design, or design review to your timeline save 10 from the other end? I don't know about worst-case, but I've been through scenarios where we didn't do any of this stuff successfully. Yeah I can think of a couple cases where spending a day on Word or conference calls could have - or better yet sometimes did - save two work-weeks of implementation / integration / debugging.
I read this site out of interest as both gamer and a programmer, though the programming I do isn't games. I'm a huge fan of formalized design and implementation process. That's how my CRM project team changed a typical 9-to-7-and-then-9-to-midnight day into a more manageable 9-to-5.
Identify a feature as fundamentally stupid, flawed, or impossible?
ROI: you don't waste the time coding, debugging, trying to salvage wasted effort. You may be able to refine the feature without wasting time implementing it the bad way first.
Identify a cleaner, easier, simpler way to implement a feature?
ROI: less code means better performance, portability, less time spent debugging. If someone else has to look at the code for your feature they'll get up to speed more quickly.
Identify functionality you can add to a feature free or with minimal effort?
ROI: your feature's better.
Identify all your integration points and solve API snags before anyone's written a line of code?
ROI: API changes waste time, more or less depending on your programming language and the importance of the change, and are often a headache in source control.
Figure out everyone's tasks and timelines before implementation starts?
ROI: no developers blocked on code that someone else hasn't written up yet, no resource-allocation panic as the deadline looms and you're trying to split outstanding tasks up and assign the parts to unfamiliar developers. Even if it does come down to that, at least the new developer's got an authoritative design doc for reference.
Planning for shorter work days?
ROI: Happy, less-stressed programmers care more about the app (game in your case) they're working on. They use fewer ugly hacks to make things work, and introduce fewer bugs from programming while sleep-deprived. They don't turn a blind eye on bugs and flaws in order to get their feature complete, and can take a little extra time to fix it.
1000% ROI... can adding one day of feature scoping, detailed design, or design review to your timeline save 10 from the other end? I don't know about worst-case, but I've been through scenarios where we didn't do any of this stuff successfully. Yeah I can think of a couple cases where spending a day on Word or conference calls could have - or better yet sometimes did - save two work-weeks of implementation / integration / debugging.
Original Comment by: dougnoel
Good article. I spent five years in the game industry on the QA side. Most of it in online games. The best games I worked on were ones that were planned instead of haphazardly thrown together. The idea of games as an art form has merit. But saying software development is not necessary for a good game is like saying good technique is not necessary to create a good painting. Naturally talented, untrained, world-famous artists are the exception, not the rule. The same goes with game development. Every garage game is not DOOM.
I left the game industry before my particular ship sank. They couldn't pay me to come back. I mean that literally. I make more now as a QA Engineer than I ever did supervising a whole QA department for a large corporate gaming company. I also have 40 hour work weeks. In every interview that I've been on since I left the industry, no one would pay me what I make as a QA Engineer to manage a QA group. The state of QA is another topic, but the issues are similar to the ones Jason points out in this article.
I have known many producers, programmers and testers who burn out after a single project. Sometimes they take a different job in the industry, hoping it will be less stressful. Sometimes they leave. Many of the people I know that are still in the industry do not have families.
I enjoyed working on games. But I didn't enjoy it so much that I'd take a huge pay cut and have no life outside of work. that's one of the thrusts of this article. When the pain outweighs the thrill of working on games, people leave and don't come back. the net effect is that the pool of experienced developers grows slowly because the biggest lesson learned is that most game companies don't value their employees.
There are a couple of comments that seem to miss the thrust of this article. (At least as I see it.) It's not about killing creativity by creating process. It's about using process to create 1.) Repeatability, and 2.) Employee Satisfaction. Proper development techniques work just fine in the web development industry. And as far as I can see, creating an online store isn't that different from creating an online game. It's all about creating a good experience for the customer.
I think attacking Jason is silly. Just because his job isn't to make games doesn't mean he doesn't know what he's talking about. The Penny Arcade guys have never made a game, but they still have valid input about the game industry. It's also nice to see a nice rational article about this topic (with supporting data), rather than another rant by disenfranchised programmers. I would have like to see more non-IGDS supporting documents, but realistically there aren't a lot of groups out there researching this kind of thing.
Doug
Good article. I spent five years in the game industry on the QA side. Most of it in online games. The best games I worked on were ones that were planned instead of haphazardly thrown together. The idea of games as an art form has merit. But saying software development is not necessary for a good game is like saying good technique is not necessary to create a good painting. Naturally talented, untrained, world-famous artists are the exception, not the rule. The same goes with game development. Every garage game is not DOOM.
I left the game industry before my particular ship sank. They couldn't pay me to come back. I mean that literally. I make more now as a QA Engineer than I ever did supervising a whole QA department for a large corporate gaming company. I also have 40 hour work weeks. In every interview that I've been on since I left the industry, no one would pay me what I make as a QA Engineer to manage a QA group. The state of QA is another topic, but the issues are similar to the ones Jason points out in this article.
I have known many producers, programmers and testers who burn out after a single project. Sometimes they take a different job in the industry, hoping it will be less stressful. Sometimes they leave. Many of the people I know that are still in the industry do not have families.
I enjoyed working on games. But I didn't enjoy it so much that I'd take a huge pay cut and have no life outside of work. that's one of the thrusts of this article. When the pain outweighs the thrill of working on games, people leave and don't come back. the net effect is that the pool of experienced developers grows slowly because the biggest lesson learned is that most game companies don't value their employees.
There are a couple of comments that seem to miss the thrust of this article. (At least as I see it.) It's not about killing creativity by creating process. It's about using process to create 1.) Repeatability, and 2.) Employee Satisfaction. Proper development techniques work just fine in the web development industry. And as far as I can see, creating an online store isn't that different from creating an online game. It's all about creating a good experience for the customer.
I think attacking Jason is silly. Just because his job isn't to make games doesn't mean he doesn't know what he's talking about. The Penny Arcade guys have never made a game, but they still have valid input about the game industry. It's also nice to see a nice rational article about this topic (with supporting data), rather than another rant by disenfranchised programmers. I would have like to see more non-IGDS supporting documents, but realistically there aren't a lot of groups out there researching this kind of thing.
Doug
Original Comment by: Joshua Scholar
http://nightstudies.net
Horrible engineering practices and horrible working conditions are not only why I no longer work in the game industry, they're why I quit programming altogether.
Let's face it, American corporations treat their non-management employees like crap - you're a sucker if you're willing to sacrifice 65 to 90 hours a week to work like slave in an unnecessarily high pressure, high failure rate environment (see horrible engineering practices) with no job security and often poor pay.
http://nightstudies.net
Horrible engineering practices and horrible working conditions are not only why I no longer work in the game industry, they're why I quit programming altogether.
Let's face it, American corporations treat their non-management employees like crap - you're a sucker if you're willing to sacrifice 65 to 90 hours a week to work like slave in an unnecessarily high pressure, high failure rate environment (see horrible engineering practices) with no job security and often poor pay.
Original Comment by: Outsider
I don't work in the game industry. I just happen to personally know / spend time with a few of them.
I can't agree with the Game Development isn't Software Development arguement. As a programmer I've seen how a badly written, not well thought out,constantly changing, requirements doc can lead into 100+ hr weeks. That being said, a similar game design doc could lead into headaches and burn out down the road.
I agree with what Jon and Jare.
I do agree that what the article was targeting wasn't the "artists" but rather the programmers, other technical staff and producers, that spend hours trying to fullfill the requirements laid out to them from the designers.
In my opinion, each game is a start-up. You begin with an idea, develop it, bring in a few people and from that come out with what your game will be. Get those architects and engineers to figure out how they're gonna do it and how long it'll probably take. When you've figured that out, start hiring your core team and begin building. Keep a flexible workforce through outsourcing / contractors so that in case you come up with a new idea or direction you can slip the date without burning too much cash, because if you have borrow more money the publisher is going to take you and have its way with you.
And now as an outsider I'll remark about some of things that bother me from watching the game industry.
I'd really like to see game companies hire interns.
Stop practicing incest. It seems to me that the game industry likes to hire from their own pool. It's a catch-22 it seems that in order to be in the game industry you have to be in the game industry. How do you get into the game industry? It seems like you have to join QA and crawl,backstabb, and suck up to get anywhere. Those that put their heart and soul into games burn out because they have to deal with these type of people and the drama that they bring.
Unprofessionalism. I see drama. I see me fire you in a heartbeat.
As a kid all I wanted to do was to make games. So I went into programming. Now after hearing and watching the people I know work to make games, I can't say that I want to be in the game industry as it is today. Instead I want to change the way the game industry does business so that those that I know can stop being torn apart by the industry they wanted to work for.
I don't work in the game industry. I just happen to personally know / spend time with a few of them.
I can't agree with the Game Development isn't Software Development arguement. As a programmer I've seen how a badly written, not well thought out,constantly changing, requirements doc can lead into 100+ hr weeks. That being said, a similar game design doc could lead into headaches and burn out down the road.
I agree with what Jon and Jare.
I do agree that what the article was targeting wasn't the "artists" but rather the programmers, other technical staff and producers, that spend hours trying to fullfill the requirements laid out to them from the designers.
In my opinion, each game is a start-up. You begin with an idea, develop it, bring in a few people and from that come out with what your game will be. Get those architects and engineers to figure out how they're gonna do it and how long it'll probably take. When you've figured that out, start hiring your core team and begin building. Keep a flexible workforce through outsourcing / contractors so that in case you come up with a new idea or direction you can slip the date without burning too much cash, because if you have borrow more money the publisher is going to take you and have its way with you.
And now as an outsider I'll remark about some of things that bother me from watching the game industry.
I'd really like to see game companies hire interns.
Stop practicing incest. It seems to me that the game industry likes to hire from their own pool. It's a catch-22 it seems that in order to be in the game industry you have to be in the game industry. How do you get into the game industry? It seems like you have to join QA and crawl,backstabb, and suck up to get anywhere. Those that put their heart and soul into games burn out because they have to deal with these type of people and the drama that they bring.
Unprofessionalism. I see drama. I see me fire you in a heartbeat.
As a kid all I wanted to do was to make games. So I went into programming. Now after hearing and watching the people I know work to make games, I can't say that I want to be in the game industry as it is today. Instead I want to change the way the game industry does business so that those that I know can stop being torn apart by the industry they wanted to work for.
Original Comment by: Mark
I think it's a bit difficult to pigeonhole American corporations or even just the software industry into any one particular environment.
Anyway. I'm just some wild-eyed idealistic college kid trying to break into the industry (and I love programming enough that I'd probably stay in software even if game development does burn me out), so maybe I'm wrong (and I can't back my opinions with experience anyway), but it seems to me that the trick to streamlining game development is to get involved in a project as early as possible and trying (in as forceful a way as you can remain polite and adhere to your job description) to steer it in a direction so that as many decisions as possible are made as early as possible. And then if a petty manager prevents a more efficient development cycle, either stick it out until you get enough seniority to make changes yourself, or quit and find somewhere else, or somewhere in between.
I think it's a bit difficult to pigeonhole American corporations or even just the software industry into any one particular environment.
Anyway. I'm just some wild-eyed idealistic college kid trying to break into the industry (and I love programming enough that I'd probably stay in software even if game development does burn me out), so maybe I'm wrong (and I can't back my opinions with experience anyway), but it seems to me that the trick to streamlining game development is to get involved in a project as early as possible and trying (in as forceful a way as you can remain polite and adhere to your job description) to steer it in a direction so that as many decisions as possible are made as early as possible. And then if a petty manager prevents a more efficient development cycle, either stick it out until you get enough seniority to make changes yourself, or quit and find somewhere else, or somewhere in between.
Original Comment by: GameProgrammer
I agree that the games industry generally lacks the best development practices, but it's not because the companies are stupid. There is a very different set of forces at play in the games industry than with most other software development. Fundamental among these is the fact that most software has a very short development cycle (~1 year) and when the software is shipped, it is gone. There are no patches to Madden for PS2, no expansion packs, no planned obsolescence, no product maintenance. The day the software ships, there is nothing for the team to do. The best they can do is hope the game is sucessful enough that they can work on a new version. If so, they will reuse a lot of the code of the previous version. But the more they make it like the previous version, the more they get criticized for making a product just like the previous one. This is ironic because in most other aspects of software development most people want the new versions to be just like the previous ones but with refined functionality. This fact alone has many development and business ramifications that most other software doesn't have.
One of the ramifications of this is that average number of lines of code that games programmer write is well above the typical industry average. Over the course of two years on a major game I was on, most programmers on the team averaged ~100 - 200 lines of code a day. I could write a chapter on all these differences alone.
The point I am making here is that instead of blindly criticizing game companies for having bad practices, we might want to consider how it is that game companies have a different situation and consider how we might best be able to deal with the situation.
Lastly I'll mention that game development companies do in fact do many of the software practices that outsiders claim they don't.
I agree that the games industry generally lacks the best development practices, but it's not because the companies are stupid. There is a very different set of forces at play in the games industry than with most other software development. Fundamental among these is the fact that most software has a very short development cycle (~1 year) and when the software is shipped, it is gone. There are no patches to Madden for PS2, no expansion packs, no planned obsolescence, no product maintenance. The day the software ships, there is nothing for the team to do. The best they can do is hope the game is sucessful enough that they can work on a new version. If so, they will reuse a lot of the code of the previous version. But the more they make it like the previous version, the more they get criticized for making a product just like the previous one. This is ironic because in most other aspects of software development most people want the new versions to be just like the previous ones but with refined functionality. This fact alone has many development and business ramifications that most other software doesn't have.
One of the ramifications of this is that average number of lines of code that games programmer write is well above the typical industry average. Over the course of two years on a major game I was on, most programmers on the team averaged ~100 - 200 lines of code a day. I could write a chapter on all these differences alone.
The point I am making here is that instead of blindly criticizing game companies for having bad practices, we might want to consider how it is that game companies have a different situation and consider how we might best be able to deal with the situation.
Lastly I'll mention that game development companies do in fact do many of the software practices that outsiders claim they don't.
Original Comment by: Jon
I'm just defending the claim of 1000% ROI is unreasonable for good software development practices.
I can imagine that the resourcing and cultural issues being discussed look a lot like the ones I've been through, I certainly can't imagine how one could do any worse. We won our freedom with highly reliable scheduling estimates. Product Management doesn't second-guesses my group when we say how long features take to implement any more; I remember the first release of our product where were told by the CEO himself that we would have half the manpower and half the time we said we would need. They've stopped trying to shop around for other dev teams (e.g. the guys they hired in India) to see if anyone is willing to quote them less time to implement; they're almost certainly going to overrun to what we said or probably worse. I think it took us 2 or 3 years... maybe 5 complete development cycles (new versions of the same thing)... to get our point across.
I'm just defending the claim of 1000% ROI is unreasonable for good software development practices.
I can imagine that the resourcing and cultural issues being discussed look a lot like the ones I've been through, I certainly can't imagine how one could do any worse. We won our freedom with highly reliable scheduling estimates. Product Management doesn't second-guesses my group when we say how long features take to implement any more; I remember the first release of our product where were told by the CEO himself that we would have half the manpower and half the time we said we would need. They've stopped trying to shop around for other dev teams (e.g. the guys they hired in India) to see if anyone is willing to quote them less time to implement; they're almost certainly going to overrun to what we said or probably worse. I think it took us 2 or 3 years... maybe 5 complete development cycles (new versions of the same thing)... to get our point across.