ETPC

video games

  • he/him/they/them

video games | anarcho-communism | depression | blm | acab | trans rights are human rights | he/him/they/them | like 30 or 40 | movies | Senior Social Media Lead/QA for Mighty Foot Productions | runs @dnf2001rp


austinkelmore
@austinkelmore

I often see people talk about the effects of games being delayed with the stress, crunch, and time pressures - but I don't think many people understand why delays happen. So I'm going to explain that, and to do that, we need to go back to the 1890s manufacturing days and then to a 1950s Japanese car company.

Back in the 1880s and 1890s, Frederick Taylor came up with Scientific Management (aka Taylorism) for use in manufacturing steel, which he defined as "knowing exactly what you want men to do, and then seeing that they do it in the best and cheapest way". One of the largest business costs are wages, so if manufacturing steps can be aligned right after each other with minimal time between them, owners can have workers make more product in less time which equates to more profit.

This boost in productivity that Taylor helped bring about came at the expense of downtime for workers. Taken to its logical conclusion, all downtime for workers is removed and they become a cog in the machine of manufacturing and you can see this with how Amazon treats its workers in their distribution centers. Workers end up paying for this with their bodies. No downtime can mean more mistakes and serious injury or death on the job, but it does mean more profit for capitalists, so there's that upside!

Fast forward a number of years and after WW2, Toyota popularized another business practice called Kaizen, aka Continuous Improvement. The theory is that workers can continuously improve their efficiency or fix problems so they can produce more. With Kaizen, Toyota also implemented something they called the Andon cord. Workers could pull it on the manufacturing line to immediately halt all production to address issues. This causes delays and costs money to fix the issues, but for a manufacturing line that builds the same thing over and over, these micro-optimizations can help produce things quite a bit faster in the long term.


Game Development

So finally coming back to game development, you can see some of this history in how we make games. We often use scrum, which consists of defining work which is tracked in Gantt charts to see if we can hit a particular release date, and then we prioritize and optimize schedules to cram all the work in that amount of time. We then make micro-optimizations to the schedule over time to try to improve reliability of the date.

There's a huge flaw in the way we plan for work, though. We're not a manufacturing business, we're a creative and research business. So optimizing schedules doesn't matter nearly as much as whether major decisions for the game are changed late in the process. For games, major delays happen for a couple of reasons, but the biggest one I've seen is that leadership changes their mind for large areas of the game mid-development. This may be for good reasons or less good reasons, but the impact that has is tremendous.

If you think of the previous micro-optimizations that were being made - for each of those made, the game becomes more set in its path and less able to pivot. This is good when you know what you're building on a factory line, but makes the cost of changes even more pronounced in games when it happens late into development.

When everything is completely scheduled out in timelines in a waterfall type method to hit a date (which is effectively what Gantt charts are), any large change in direction invalidates that schedule. And very often, the ship date hasn't changed, only the work has. The other thing an optimized schedule does not allow for is a buffer for unknown things to happen (ie: the research). We don't have a manufacturing process for games, each one is bespoke. So when unexpected stuff comes up, and that happens all the time, it again breaks the schedule.

If engineering takes longer on a feature than expected, that can impact art, which could impact design and QA, etc. When delays happen, management often crucially fails at this point. They try to "unblock" people. Why is that an issue you might ask? Because the people blocked may not be the bottleneck for the whole project. If engineering is the bottleneck because they have the most work for the game (and they usually are), then giving them MORE work to unblock art or design actually delays the game rather than making it quicker. It's better to have art or design do literally nothing or start cutting areas or features, otherwise unblocking them could delay the schedule further by adding work for the bottleneck discipline.

Management wants everyone working all the time to minimize labor costs, but they often do this only in disciplines because it's easier to estimate than looking at the whole team. If they wanted to do it even better, they'd evaluate which discipline is the bottleneck and optimize around that. This, however, is also fraught with issues because there's still so much unknown in shipping games. You can never remove the risk of something coming up.

TL;DR - management in the games industry took ideas and theories from manufacturing and misapplied them to a creative and research industry and didn't add the fail safes that manufacturing has. You can't fill a schedule out months in advance and expect to hit the date and yet that's what every team I've been on has done.

THAT is why games are always late, over budget, and so hard on workers to make.


You must log in to comment.

in reply to @austinkelmore's post:

Interesting. I am taking a class on software engineering, and the manual spends a lot of time signing the praises of the Agile method over the Waterfall method. It really seems to think that the Agile method is the best things that has ever been invented. Do you think implementation of the method in the game industry would help prevent delays? If not, what do you reccommend?

every games company I've worked at has attempted one interpretation or another of the agile methodology; however, it rarely (if ever) addresses the issues brought up in the chost here. often management does not follow the core conceit of agile correctly; rather than measuring progress in terms of how much complete and useful stuff exists, they become fixated on abstractions like "story points". story points go from being a handwave-y way of roughly estimating effort, time, and risk on tasks and instead become a kind of progress bar. "if we get 180 story points done every sprint, we're on track! let's keep that velocity up!" this mantra haunts me. it forces people to make many short-term gains and sacrifices long-term work, since larger chunks rarely fit in a sprint, and thus don't show on the producer's nice pretty burndown graphs.

I recently watched an essay by videographer Zoe Bee called In Defense of Innefficiency. In it, she mentions Goodhart's law, which stipulate: "When a measure becomes a target, it ceases to be a good measure." I think a lot of producers need to keep that in mind. Not that I know anything, I have never worked full time in my life. Thanks for your comment!

It's kind of a fundamental problem of the problem domain - agile works well for continuous delivery like business software, but not for a game which has to have a single release date that's also tied into marketing and all of that.

However, even in software (for example, I work on internal tooling at a bank that is used for back office work like account management and loan servicing) the work can still be very hard to plan, and development always manages to go more slowly than you expect even when you try to account for that.

This also explains why large companies like Franchises, sequels, and the general risk-adverse homogeneity you see in triple-A gaming: more of the product (and production process) is known in advance, allowing a development process which more closely resembles a factory line.

Yes, exactly! The example for this I always like to point at is Assassin's Creed.

The first one had a TON of risk to it being one of the first games with the open world style of climbing that we now see everywhere and you can see it how it didn't all quite fit together because they ran out of time and eventually had to just ship it. It was good, but not amazing.

The second game built on top of the first one, they limited the risk for new features, and it was phenomenal. They took everything they learned from the first game and focused on connecting it up together and it was so well done.

Then they were able to progressively make more and more Assassin's Creeds as they learned how to build the game faster and faster and mitigated more and more risk.

I've been reading a bit about and researching the Spiral Model of development. It sounds promising.

The one gotcha about it is that it doesn't really take into account budget and timelines for releases necessary to hit certain windows.

It's a hard problem!