There was a lot of interest in this MMO project because of the positive karma associated with NASA -- there are a LOT of space program fans in the game industry. Unfortunately the great deal of interest and outpouring of support from the development community seems to have convinced NASA they don't need to pay for quality product.
There is no professional company who is going to deliver professional product without getting paid. What they are looking at now is the amateur market, unless someone with spare burn like Google is going to take interest. (Probably the most effective way this could be done at this point is through a Google-MMO team partnership.) AFAIK this does not include any major game companies, and in particular any major MMO companies. MMOs are still indie enough because of the business model (you're dealing directly with customers/players, you're not shipping through a publisher upon whom you depend for your milestone payments) that they have to care about their day-to-day survival. So the people who know the most about this space are not going to be able to get involved for free. By virtue of the system they are setting up NASA is looking for people who are not the best at what they do, which is very sad, because they could easily have had the best in the business. The people that I know who submitted replies to the RFI were very put off by NASA's "just kidding" gotcha with this project and want nothing further to do with it. There may be others who didn't, but there is not currently a good model for success here. If it had been initially presented this way, it might be different, but now they've alienated professional teams by bait and switch, which is more damaging than if they'd never suggested the RFI in the first place.
It would have been very feasible to make a strong core MMO for $3 mill, build a space engine with physics and interesting core gameplay and art. Not from zero, though. Anyone who can make money at this is going to be doing things that make money, executing on THEIR dreams at a professional level of investment and business. They were eager to work with NASA, but NASA is not providing enough add to make this worthwhile any longer, and that's quite sad.
What they also seem to not understand is that it takes a pro team to execute on something like this. Thinking that you can charity/indie it for nothing or use the engineering resources available to NASA and not include a professional game developer is how you get the edutainment crash.
Agreed that this is not a "final solution" measure when it comes to better process. But the advantage in addressing the overtime issue is when it comes to tracking productivity in general. Product does not equal time, but time is a trackable resource whereas frequently the product itself is inconsistent (lines of code do not equal time do not equal product, either, for instance).
When you track time, and particularly when companies are held accountable (ie paying) for time spent, what this does is give them incentive for committing to reasonable delivery dates and content. When the company has a penalty for overcommiting, when it makes a commitment *to the developer* to have reasonable scheduling, there is a catch in place to track and therefore analyze and evaluate the efficiency of the process. So it's not really about the money *alone*, though compensating people for the work they put in is reasonable and positive too.
The general problem is when a company will overcommit to what they can deliver in a certain timeframe, and when they can't make it, the developers are the ones to suck up the penalty, while the company (as a whole, as a unit) can frequently have no "memory" of this happening because there is no tracking system in place. Free Radical here is not saying they are going to plan to run heinous overtime -- in fact it's highly likely they wouldn't be able to afford to. What they are saying is that they will hold themselves accountable for maintaining a schedule, and will compensate if they fail to do so. Ultimately overtime is a management/business failure (either in terms of planning or hiring the people that can deliver on what they plan), so for it to be only on the shoulders of the individual developer is not reasonable. When crunch actually results in numbers on a sheet that go to the top of the company and suddenly becomes an issue of "whoa, this title was X over budget because of X overtime", things are more quantifiable and are addressed faster, as opposed to the slow erosion of company morale and high turnover that results from heavy OT situations without tracking or compensation.
Paying by the hour isn't the be-all end-all to this situation, but if it results in more conscientious scheduling, that scheduling will benefit everyone. The developers are still core salary, the majority of their paycheck is coming from a salaried rate, and the difference paid in overtime -- and when there is serious crunch that is actually going to cause the company overtime, it is not a case of some people getting the work done on time and leaving and others continuing without them, it's usually the team as a whole -- is not going to be significant enough, I think, to provide a motivating "penalty" for people who work faster than others. The majority of the cases where this is going to apply are going to be beyond the scope of a regular work schedule, and if someone is milking overtime pay without getting management permission for that overtime due to an extenuating circumstance, that's an individual problem that would likely be addressed one-on-one.
You'll have to explain what confused you before I can answer -- I don't know which "post" you're referring to or how it could be "fake", but neither of them were. To be absolutely clear, I was mocking your highly reductionistic short-sighted view of the situation.
There is no competent business model that relies on overtime. The fact that overtime becomes an issue is as a result of poor business practices. In a salaried work environment (which almost all software development environments are) "overtime" should not even be a concept because the purpose of salary is to pay for product and not for hours. When the business environment degrades to the point where you have to start counting in order to address a compensation issue, that is a failure. (Note that the "to address" is key there -- it is smart to count from the beginning purely for purposes of refining production process and billing clients.) There are countless studies that have shown that productivity decreases dramatically when you pass the 40 hr/week model. "Overtime" is occasionally necessary as triage, but should never be part of a "business model". If you plan for crunch, you are setting yourself up for a world of pain.
It's nice for you that you don't care about the people who make the goods that you consume, I suppose, but I find that short-sighted as well. It will and does cost you, in the long run.
Wow. It took you three years to find the essay and still all you can manage is knee jerk testosterone fairy tale rhetoric? You have the power to google: use it.
(This is "ea_spouse", by the way.)
No, neither of your conjectures are or were correct. This happens to the best in the industry, which is one of the reasons why you don't see a lot of the very established industry personalities talking about it. It isn't something any of us are proud of, but we are still in the process of fixing it. In this particular case there was a lot of history -- very common history -- having to do with financial stress from prior project collapse, EA bringing in a crop of people from that collapsed project (also common), and offering a contracted "signing bonus" in lieu of relocation assistance because in any place other than Los Angeles the commute would have been reasonable, but relocation assistance is based on miles traveled, not hours. So there was a contract for a period of time that could not be exited. And when people get in these situations, do they leave as soon as the contract is up? They sure as hell do. The ability to get another job is not the issue. It is that this situation is not acceptable regardless of whether people can exit it (which they do, constantly, and if you think this level of turnover is either efficient, healthy, or financially advantageous to the company you need to go back to school).
What the knee-jerk "me me me" responders to this issue don't realize, or refuse to realize, is that exiting the situation addresses the symptom but doesn't provide a cure. Frankly paying overtime does the same thing, but the critical difference is that once a company is actively tracking hours and paying overtime, it has the incentive to plan better and make it such that the overtime situations happen as infrequently as possible. The money is not even the issue. It is that it creates an incentive and a data-gathering state -- because a great number of game companies five years ago didn't even *track* how much time was being spent on a project -- that improves the overall process of making games, and therefore improves the games themselves, which is what we all want. And going home once in awhile is nice too.
Yes, it is obvious that when you work in a situation like that, you leave. In fact it is amazing to me that some people don't seem to realize that this is so obvious it doesn't need to be said. But leaving and then not talking about the issue, or leaving and forgetting about it, is selfish, stupid, bad for the industry, and bad for the games. We're fixing it instead.
(This is ea_spouse.) The situation has improved, but not because of Bing. It can be attributed to a few things -- a lot of people, even at EALA, are praising Neil Young for it and he certainly has had his part -- but through a series of, cough, recent events, I have been hearing that things are much, much better at the Los Angeles studio at least. Tremors of Bad Things still persistently emanate from EA Tiberon. Not to so overtly plug, but there are some stories over at Gamewatch.org even pretty recently.
My husband's one encounter with Bing was poignant: his shoes were falling apart and he had used duct tape to hold them together. Granted this was pretty hokey, but they were already deep in crunch and everyone was exhausted. The shoe broke and he kicked it across the floor. Bing was in a cubicle doing some of his "creative direction"; Lan didn't realize it was Bing until much later. Bing looked at his shoe and said "You work here? Can't you afford new shoes?", very derisive. Lan said, "I've got the money, I haven't got the TIME."
Graph theory has some very interesting applications in controlling griefing. Different companies have used this before, and it's a system maintenance sort of thing... you have to take out griefer networks, not just individuals. But this can be done. Almost everything you do in an MMO is probably tracked -- the people you talk to, the people you trade with, the places you visit. It's all data and it's relatively trivial to run analysis on it that results in a visual network map of connected players. This is fairly similar to what the FBI does to track terrorist networks, only obviously the data is a lot harder to obtain.
Then, in the case of griefers, you can explore varying degrees of ugliness. You can warn them. You can ban them. You can cancel their accounts. And then you can contact their credit card company and report them for harassment and/or online fraud, which can REALLY suck. But the core point is that if you take out key nodes in a network of griefers, the pool settles out remarkably quickly.
Griefing is controllable with the right expert developing the right tools. All the MMO has to do is decide that they want to do something about it. But so long as they keep getting subscriptions, cough, certain large MMOs are not going to make that decision. But some of it has to do with the age of the MMO. Young MMOs will tend to want to play nice with griefers. It never works.
Moving into AP actually isn't that hard if you have the background, it analogs to moving into a programming or art position because you have the degree for it. It just IS possible to go up through QA still -- which in a way is kind of frightening considering that in a lot of places they don't even bother training QA for production formally. Someone with a related college degree would probably do much better, though it depends entirely on the person; some people learn really well through observation and can grok it coming up through the drudge ranks.
Yeah, if you look in the unmodded comments I posted a note lamenting that slashdot had eaten my paragraph breaks as the default posting mode was html formatted, and I didn't want to spam a second post.
QA certainly IS a track into the games industry, but depending on where you go it may not get you a development position. QA falls into two categories: publisher QA and developer QA. Both have their advantages and disadvantages.
Publisher QA tends to track into Production. This is like Hollywood production in that you are a facilitator between the publisher and the developer. You may or may not be an asshole, either seems to work (just so that I make my bias clear from the start). A good producer is invaluable and does have some power in tipping the balance between a game that is decent and one that is exceptional. A bad one can make a dev team's life a living hell. But it is a profession all on its own. Producers must be excellent communicators, have management skills, be diplomatic, understand scheduling, have enough of a grasp of the technical demands to know what to ask of their assigned team, and be able to navigate labyrinthine publisher politics. The turnover rate is high. It is very much a "people" position and its closest analog on the dev side is mangagerial.
Getting back to the article, QA definitely is a path toward a production job. But most people applying to QA hoping to get into the industry aren't looking to be producers, and probably haven't even thought about it. The track goes something like Temp Tester -> FT Tester -> Lead Tester -> Assistant Producer -> Producer, with each tier culling out increasing numbers of candidates. The other thing about publisher QA is that publishers will tend to just grab anyone off the street and throw them into a QA position. You get high school dropouts and PhDs alike working QA. Moving up to a full time position (QA almost invariably starts temp) is like making it through a firing squad; rough numbers from people I've talked to seem to show that about one in twenty will move up. But because so many people enter QA just as a side job -- with no intention of continuing in the games industry and often very little technical ability whatsoever -- those odds aren't that bad.
It should be noted, too, that occasionally publishers will loan out people with technical ability from the QA ranks to fill in scripting help and the like with their developer studios. This is a good opportunity for advancement but generally is a resume padder and not much else; the dev house ultimately will be doing its own recruiting and not necessarily pull from the publisher's QA (they may not even be able to, depending).
Development QA, for one thing, is much more difficult to find. Increasingly QA is done by the publisher and the publisher alone, because it's more efficient (economically). The publisher is also the one that ultimately is giving the approval on the milestone and final product, so they want to have their own in-house resources doing quality testing so that they can monitor them and ensure quality of the testing itself. A dev house with its own QA department, meaning people that ONLY do QA, is either very big or very unusual. A big developer will run a QA department very similar to the publisher's, and sometimes worse; QA at Electronic Arts are literally fenced off from the rest of the developers and are treated with zero trust, herded in and out and highly restricted on what they can bring into the building. This is because they are temps, and when you have to cycle so many people through, you quickly tap regional talent resources and have to start hiring people off the street, which many companies don't seem to mind because their QA practices mostly involve having people play the game over and over again and report where it breaks, a very primitive form of QA that still persists in the industry but is slowly being augmented by automation, and, in some rare and ahead-of-the-curve places, better actual production practices in managing QA testing teams. These usually involve keeping testers on full time, though, which companies do not like to do because they perceive the job to be 'unskilled' and therefore don't want to pay for things like health insurance and other ful
Re:Why should you.. or anyone care?: Slave Mentali
on
Pay vs. Happiness
·
· Score: 1
Hi -- off topic, assuming it will disappear anyway since this is an old post... I saw a couple of your comments in an older thread (would reply there, but can't) about how you're independently working on your own fantasy/sci-fi novel and was very interested. I run a writing group for independent writers, a network for critique, and a sort of guerilla marketing loop -- we help each other get publicity for our work by acting locally in a lot of different areas of the US. I'm taking a chance that you might have email notification turned on for replies to your comments (since there is no way to message you via your profile) -- drop me an email if you'd like to chat. gryphoness at gmail dot com.
There was a lot cut out of Howl's Moving Castle, but not by Disney or Miyazaki. It was based on the Diana Wynne Jones book, and by 'based' I mean they took the vague idea of part of what the book was about and spun it into an entirely new movie. There's nothing wrong with this in concept, but what you wound up with was, as you mention, some rather confusing moments in the movie. Several characters were cut out entirely, some had their stories changed, and others bear almost no resemblance whatsoever to their origin characters. In fairness, Howl's was a very complicated story -- one of Diana Wynne Jone's SIMPLER ones, I think, and so a good choice for a movie, but nothing of hers is truly simple or straightforward. It had about six different plots all braided together. For some reason, instead of pulling the essence out of these plots, Miyazaki elected to take part of one of them and then ADD new plot elements that, if they were there at all in the book, were so only in shadow or insinuation, not directly. He focused a LOT on the war, and after watching the movie I had a distinct nagging feeling that the current world political climate -- read the US's warmongering -- strongly influenced how that was expressed. It's hard to say, though -- air battles are one of the things he enjoys rendering in animation, so maybe the plot was adapted that way to begin with.
Slashdot Mirror
There was a lot of interest in this MMO project because of the positive karma associated with NASA -- there are a LOT of space program fans in the game industry. Unfortunately the great deal of interest and outpouring of support from the development community seems to have convinced NASA they don't need to pay for quality product.
There is no professional company who is going to deliver professional product without getting paid. What they are looking at now is the amateur market, unless someone with spare burn like Google is going to take interest. (Probably the most effective way this could be done at this point is through a Google-MMO team partnership.) AFAIK this does not include any major game companies, and in particular any major MMO companies. MMOs are still indie enough because of the business model (you're dealing directly with customers/players, you're not shipping through a publisher upon whom you depend for your milestone payments) that they have to care about their day-to-day survival. So the people who know the most about this space are not going to be able to get involved for free. By virtue of the system they are setting up NASA is looking for people who are not the best at what they do, which is very sad, because they could easily have had the best in the business. The people that I know who submitted replies to the RFI were very put off by NASA's "just kidding" gotcha with this project and want nothing further to do with it. There may be others who didn't, but there is not currently a good model for success here. If it had been initially presented this way, it might be different, but now they've alienated professional teams by bait and switch, which is more damaging than if they'd never suggested the RFI in the first place.
It would have been very feasible to make a strong core MMO for $3 mill, build a space engine with physics and interesting core gameplay and art. Not from zero, though. Anyone who can make money at this is going to be doing things that make money, executing on THEIR dreams at a professional level of investment and business. They were eager to work with NASA, but NASA is not providing enough add to make this worthwhile any longer, and that's quite sad.
What they also seem to not understand is that it takes a pro team to execute on something like this. Thinking that you can charity/indie it for nothing or use the engineering resources available to NASA and not include a professional game developer is how you get the edutainment crash.
Agreed that this is not a "final solution" measure when it comes to better process. But the advantage in addressing the overtime issue is when it comes to tracking productivity in general. Product does not equal time, but time is a trackable resource whereas frequently the product itself is inconsistent (lines of code do not equal time do not equal product, either, for instance).
When you track time, and particularly when companies are held accountable (ie paying) for time spent, what this does is give them incentive for committing to reasonable delivery dates and content. When the company has a penalty for overcommiting, when it makes a commitment *to the developer* to have reasonable scheduling, there is a catch in place to track and therefore analyze and evaluate the efficiency of the process. So it's not really about the money *alone*, though compensating people for the work they put in is reasonable and positive too.
The general problem is when a company will overcommit to what they can deliver in a certain timeframe, and when they can't make it, the developers are the ones to suck up the penalty, while the company (as a whole, as a unit) can frequently have no "memory" of this happening because there is no tracking system in place. Free Radical here is not saying they are going to plan to run heinous overtime -- in fact it's highly likely they wouldn't be able to afford to. What they are saying is that they will hold themselves accountable for maintaining a schedule, and will compensate if they fail to do so. Ultimately overtime is a management/business failure (either in terms of planning or hiring the people that can deliver on what they plan), so for it to be only on the shoulders of the individual developer is not reasonable. When crunch actually results in numbers on a sheet that go to the top of the company and suddenly becomes an issue of "whoa, this title was X over budget because of X overtime", things are more quantifiable and are addressed faster, as opposed to the slow erosion of company morale and high turnover that results from heavy OT situations without tracking or compensation.
Paying by the hour isn't the be-all end-all to this situation, but if it results in more conscientious scheduling, that scheduling will benefit everyone. The developers are still core salary, the majority of their paycheck is coming from a salaried rate, and the difference paid in overtime -- and when there is serious crunch that is actually going to cause the company overtime, it is not a case of some people getting the work done on time and leaving and others continuing without them, it's usually the team as a whole -- is not going to be significant enough, I think, to provide a motivating "penalty" for people who work faster than others. The majority of the cases where this is going to apply are going to be beyond the scope of a regular work schedule, and if someone is milking overtime pay without getting management permission for that overtime due to an extenuating circumstance, that's an individual problem that would likely be addressed one-on-one.
You'll have to explain what confused you before I can answer -- I don't know which "post" you're referring to or how it could be "fake", but neither of them were. To be absolutely clear, I was mocking your highly reductionistic short-sighted view of the situation.
There is no competent business model that relies on overtime. The fact that overtime becomes an issue is as a result of poor business practices. In a salaried work environment (which almost all software development environments are) "overtime" should not even be a concept because the purpose of salary is to pay for product and not for hours. When the business environment degrades to the point where you have to start counting in order to address a compensation issue, that is a failure. (Note that the "to address" is key there -- it is smart to count from the beginning purely for purposes of refining production process and billing clients.) There are countless studies that have shown that productivity decreases dramatically when you pass the 40 hr/week model. "Overtime" is occasionally necessary as triage, but should never be part of a "business model". If you plan for crunch, you are setting yourself up for a world of pain.
It's nice for you that you don't care about the people who make the goods that you consume, I suppose, but I find that short-sighted as well. It will and does cost you, in the long run.
Wow. It took you three years to find the essay and still all you can manage is knee jerk testosterone fairy tale rhetoric? You have the power to google: use it.
(This is "ea_spouse", by the way.)
No, neither of your conjectures are or were correct. This happens to the best in the industry, which is one of the reasons why you don't see a lot of the very established industry personalities talking about it. It isn't something any of us are proud of, but we are still in the process of fixing it. In this particular case there was a lot of history -- very common history -- having to do with financial stress from prior project collapse, EA bringing in a crop of people from that collapsed project (also common), and offering a contracted "signing bonus" in lieu of relocation assistance because in any place other than Los Angeles the commute would have been reasonable, but relocation assistance is based on miles traveled, not hours. So there was a contract for a period of time that could not be exited. And when people get in these situations, do they leave as soon as the contract is up? They sure as hell do. The ability to get another job is not the issue. It is that this situation is not acceptable regardless of whether people can exit it (which they do, constantly, and if you think this level of turnover is either efficient, healthy, or financially advantageous to the company you need to go back to school).
What the knee-jerk "me me me" responders to this issue don't realize, or refuse to realize, is that exiting the situation addresses the symptom but doesn't provide a cure. Frankly paying overtime does the same thing, but the critical difference is that once a company is actively tracking hours and paying overtime, it has the incentive to plan better and make it such that the overtime situations happen as infrequently as possible. The money is not even the issue. It is that it creates an incentive and a data-gathering state -- because a great number of game companies five years ago didn't even *track* how much time was being spent on a project -- that improves the overall process of making games, and therefore improves the games themselves, which is what we all want. And going home once in awhile is nice too.
Yes, it is obvious that when you work in a situation like that, you leave. In fact it is amazing to me that some people don't seem to realize that this is so obvious it doesn't need to be said. But leaving and then not talking about the issue, or leaving and forgetting about it, is selfish, stupid, bad for the industry, and bad for the games. We're fixing it instead.
Very interesting that Will was at SXSW and not at the GDC...
It doesn't actually snow in Minnesota, North Dakota, etc. The mosquitoes just freeze and fall out of the sky.
(This is ea_spouse.) The situation has improved, but not because of Bing. It can be attributed to a few things -- a lot of people, even at EALA, are praising Neil Young for it and he certainly has had his part -- but through a series of, cough, recent events, I have been hearing that things are much, much better at the Los Angeles studio at least. Tremors of Bad Things still persistently emanate from EA Tiberon. Not to so overtly plug, but there are some stories over at Gamewatch.org even pretty recently.
My husband's one encounter with Bing was poignant: his shoes were falling apart and he had used duct tape to hold them together. Granted this was pretty hokey, but they were already deep in crunch and everyone was exhausted. The shoe broke and he kicked it across the floor. Bing was in a cubicle doing some of his "creative direction"; Lan didn't realize it was Bing until much later. Bing looked at his shoe and said "You work here? Can't you afford new shoes?", very derisive. Lan said, "I've got the money, I haven't got the TIME."
And the rest is history...
Graph theory has some very interesting applications in controlling griefing. Different companies have used this before, and it's a system maintenance sort of thing... you have to take out griefer networks, not just individuals. But this can be done. Almost everything you do in an MMO is probably tracked -- the people you talk to, the people you trade with, the places you visit. It's all data and it's relatively trivial to run analysis on it that results in a visual network map of connected players. This is fairly similar to what the FBI does to track terrorist networks, only obviously the data is a lot harder to obtain.
Then, in the case of griefers, you can explore varying degrees of ugliness. You can warn them. You can ban them. You can cancel their accounts. And then you can contact their credit card company and report them for harassment and/or online fraud, which can REALLY suck. But the core point is that if you take out key nodes in a network of griefers, the pool settles out remarkably quickly.
Griefing is controllable with the right expert developing the right tools. All the MMO has to do is decide that they want to do something about it. But so long as they keep getting subscriptions, cough, certain large MMOs are not going to make that decision. But some of it has to do with the age of the MMO. Young MMOs will tend to want to play nice with griefers. It never works.
Moving into AP actually isn't that hard if you have the background, it analogs to moving into a programming or art position because you have the degree for it. It just IS possible to go up through QA still -- which in a way is kind of frightening considering that in a lot of places they don't even bother training QA for production formally. Someone with a related college degree would probably do much better, though it depends entirely on the person; some people learn really well through observation and can grok it coming up through the drudge ranks.
Yeah, if you look in the unmodded comments I posted a note lamenting that slashdot had eaten my paragraph breaks as the default posting mode was html formatted, and I didn't want to spam a second post.
QA certainly IS a track into the games industry, but depending on where you go it may not get you a development position. QA falls into two categories: publisher QA and developer QA. Both have their advantages and disadvantages. Publisher QA tends to track into Production. This is like Hollywood production in that you are a facilitator between the publisher and the developer. You may or may not be an asshole, either seems to work (just so that I make my bias clear from the start). A good producer is invaluable and does have some power in tipping the balance between a game that is decent and one that is exceptional. A bad one can make a dev team's life a living hell. But it is a profession all on its own. Producers must be excellent communicators, have management skills, be diplomatic, understand scheduling, have enough of a grasp of the technical demands to know what to ask of their assigned team, and be able to navigate labyrinthine publisher politics. The turnover rate is high. It is very much a "people" position and its closest analog on the dev side is mangagerial. Getting back to the article, QA definitely is a path toward a production job. But most people applying to QA hoping to get into the industry aren't looking to be producers, and probably haven't even thought about it. The track goes something like Temp Tester -> FT Tester -> Lead Tester -> Assistant Producer -> Producer, with each tier culling out increasing numbers of candidates. The other thing about publisher QA is that publishers will tend to just grab anyone off the street and throw them into a QA position. You get high school dropouts and PhDs alike working QA. Moving up to a full time position (QA almost invariably starts temp) is like making it through a firing squad; rough numbers from people I've talked to seem to show that about one in twenty will move up. But because so many people enter QA just as a side job -- with no intention of continuing in the games industry and often very little technical ability whatsoever -- those odds aren't that bad. It should be noted, too, that occasionally publishers will loan out people with technical ability from the QA ranks to fill in scripting help and the like with their developer studios. This is a good opportunity for advancement but generally is a resume padder and not much else; the dev house ultimately will be doing its own recruiting and not necessarily pull from the publisher's QA (they may not even be able to, depending). Development QA, for one thing, is much more difficult to find. Increasingly QA is done by the publisher and the publisher alone, because it's more efficient (economically). The publisher is also the one that ultimately is giving the approval on the milestone and final product, so they want to have their own in-house resources doing quality testing so that they can monitor them and ensure quality of the testing itself. A dev house with its own QA department, meaning people that ONLY do QA, is either very big or very unusual. A big developer will run a QA department very similar to the publisher's, and sometimes worse; QA at Electronic Arts are literally fenced off from the rest of the developers and are treated with zero trust, herded in and out and highly restricted on what they can bring into the building. This is because they are temps, and when you have to cycle so many people through, you quickly tap regional talent resources and have to start hiring people off the street, which many companies don't seem to mind because their QA practices mostly involve having people play the game over and over again and report where it breaks, a very primitive form of QA that still persists in the industry but is slowly being augmented by automation, and, in some rare and ahead-of-the-curve places, better actual production practices in managing QA testing teams. These usually involve keeping testers on full time, though, which companies do not like to do because they perceive the job to be 'unskilled' and therefore don't want to pay for things like health insurance and other ful
Hi -- off topic, assuming it will disappear anyway since this is an old post... I saw a couple of your comments in an older thread (would reply there, but can't) about how you're independently working on your own fantasy/sci-fi novel and was very interested. I run a writing group for independent writers, a network for critique, and a sort of guerilla marketing loop -- we help each other get publicity for our work by acting locally in a lot of different areas of the US. I'm taking a chance that you might have email notification turned on for replies to your comments (since there is no way to message you via your profile) -- drop me an email if you'd like to chat. gryphoness at gmail dot com.
There was a lot cut out of Howl's Moving Castle, but not by Disney or Miyazaki. It was based on the Diana Wynne Jones book, and by 'based' I mean they took the vague idea of part of what the book was about and spun it into an entirely new movie. There's nothing wrong with this in concept, but what you wound up with was, as you mention, some rather confusing moments in the movie. Several characters were cut out entirely, some had their stories changed, and others bear almost no resemblance whatsoever to their origin characters. In fairness, Howl's was a very complicated story -- one of Diana Wynne Jone's SIMPLER ones, I think, and so a good choice for a movie, but nothing of hers is truly simple or straightforward. It had about six different plots all braided together. For some reason, instead of pulling the essence out of these plots, Miyazaki elected to take part of one of them and then ADD new plot elements that, if they were there at all in the book, were so only in shadow or insinuation, not directly. He focused a LOT on the war, and after watching the movie I had a distinct nagging feeling that the current world political climate -- read the US's warmongering -- strongly influenced how that was expressed. It's hard to say, though -- air battles are one of the things he enjoys rendering in animation, so maybe the plot was adapted that way to begin with.