Erin Hoffman's Inside JobInside Job: Revisiting Quality of LifeErin Hoffman's Inside Job - RSS 2.0
This week's Inside Job will strategically deviate from the normal rhythm of these columns to address feedback from a recent revisitation on quality of life presented by Paul Hyman over at Gamasutra.
Because quality of life issues impact all developers across the broad and deep industry space, it is crucial to consider a maximum sample size of opinions and passions when making statements that potentially alter our collective expectations. I offer below a collection of comments posted to Gamasutra by individual developers as an important touchstone delineating current concerns in industry quality of life.
Production Methods Still a Concern
Production methods are certainly at the top of most developers' lists when it comes to addressing quality of life. It's important, however, to normalize the overall perspective and also account for the basic nature of analytical professionals - or, as a friend of mine recently put it, realizing that part of being a game developer is intrinsically about questioning authority.
"The problem is the industry is geared up for the young 20 something who has less responsibilities and more freedom to work longer hours. They usually embrace this type of thinking and management takes advantage of it. 30-Somethings and those with families have a more difficult time committing to those standards, and rightly so.
I think SCRUM and other management type of business models need to be addressed by management in the games industry. Also realistic scheduling, not what you think your publisher wants to hear. Until this is resolved the problem will persist."
The measures being taken by the IGDA Leadership Forum are some of the most important things currently being done to address quality of life, but we need to be careful not to chase silver bullets; empirical data, wherever possible, should be carefully gathered to quantify and analyze progress made. Buzz words can make you feel warm and fuzzy, but the devil is in the details, and in the end result. It's also important for all concerned to keep an open mind about what works, and the fact that different methods will work in different ways depending on the team in question. I generally hear about as much suspicion and resentment toward the 'cult' of Scrum as I hear enthusiastic support for it, which ultimately doesn't help anyone.
"What bugs me is that the essential problem and its resulting bottleneck(engineering crunch, and subsequently design crunch later down the line, which I'm now seeing some of) was never resolved, just "troubleshooted." Everyone who could make an early decision to save our time by drawing up a new plan - the lead designer, the producer, the engineering team - put it off and let it become a crisis. Hence we've restarted on doing simplistic puzzles more than once and are way off track for our original ship date.
While I respect everyone at the company, it gives me a poor impression of the industry to see some really basic failures of planning."
A new element came up in the aggregate of the comments provided by the recent quality of life quick-and-dirty barometer provided by Paul Human's article - a distinct sense of chaos surrounding the role of design on a project:
"[A] lot of the crazy indecisiveness from designers could be solved by not designing from on high. Distribution of power is key to making a good game. Let the people in the trenches who are aware of the most pressing issues, and have the least amount of leads meetings to attend make the low level decisions. If you're worried about inexperience ruining a project, get some sub-leads who have some experience to oversee. You almost always get better ideas from a diverse group anyway. The worst thing we can have is everyone waiting on a single person to make a decision. This throws production schedules into chaos."
What's interesting about these comments is the unfocused but clear blame being placed on the role of the designer as project architect. This has always been a role closely integrated with production and the leadership of a team; smaller projects traditionally have the designer filling the producer role, with an executive producer from the studio or publisher level overseeing top-level goals. With the strong trend toward organized leadership from a production level, it now appears that designers are coming under fire for not having this same training.
"Almost every day I see the lead designer, the guy who has years of industry experience on me, waffle and handwave away things that he should come to decisions on immediately or very soon. A few days later it gets dragged out into a meeting taking twice the time it should have, because that's when he finally makes the decision, and with no written document it becomes a terrible back-and-forth "oh, I did not think of that" process. And so we lose more time."
While frustration toward designers is nothing new in the industry, this level of focused criticism of the designer-as-producer role is an interesting variant that will likely become more important as time goes on. As game production increasingly becomes a force in the shipping of a game, the overlap between producer and designer will become increasingly strained. Methods of negotiating where creativity ends and product delivery begins will represent a new and more poignant challenge that ultimately impacts quality of life from the top of a project downward.