Amazon, Google and why you can't just invent a blockbusting games developer
Amazon, Google and why you can't just invent a blockbusting games developer
The failure of two online giants shows you can’t just pour in money and watch games pop out – a game studio culture takes time to develop
This article is from 2021.
Everyone knows you have to start with 2 or 3 guys working out of a garage to make great games.
This is the best summary I could come up with:
Last week, Bloomberg published an eviscerating exposé on the dysfunctional culture at Amazon Game Studios, the development teams formed by the online retail giant, which have so far failed to produce a single hit title for PC or consoles, despite recruiting a wealth of industry veterans.
One inconvenient factor that seems to have been overlooked in both these cases is that, like a movie production team, or a sitcom writers’ room, or an orchestra, or a repertory theatre company, a games studio is a culture.
It requires a combination of factors, including a shared vision, a work ethic, a supportive environment, a sense of identity and purpose, which emerge not out of funding, but out of creative relationships and trust.
Blizzard, the creator of the Warcraft and Starcraft titles has a sprawling campus in Irvine, California that feels like a university, with its beautiful wood-panelled library, its statues, its many faculty buildings.
Media Molecule in Guildford, creator of charming handicraft titles LittleBigPlanet and Tearaway, feels like the modern approximation of Oliver Postgate’s animation studio – all singalongs and science nights and life drawing workshops.
It is almost too cliched, too on the nose, the way Amazon and Google went at it with their expensive test tube studios, the way they seem to have wanted to leverage Triple A game development in order to promote their other services and technologies – as though holistic business integration was ever enough to motivate great art or even decent entertainment.
The original article contains 1,123 words, the summary contains 246 words. Saved 78%. I'm a bot and I'm open source!
What this article suggests to me is that the big companies went wrong mainly in recruiting, probably by offering good salaries and work life balance to people used to impressing generic authority figures.
The idea that non-game software doesn't involve creativity or spit balling or iteration is ridiculous. But from what I've seen it does involve a lot more waiting for consensus and thinking too far down the road, which are political activities aimed at being right (as measured by vice presidents) rather than productive activities aimed at getting something done or making something cool (as measured by your own name in credits of a completed work offered to the public).
I'm not sure why big company engineers don't just start coding while their bosses are dithering about, but they don't, and my pop psych guess is that they've selected for people who want to know what's going to be on the exam. As long as the product is never really done and almost never seen or applauded outside the company, this kind of makes sense.
As some big game studios seem to be moving to legacy products and rolling delivery to more and more captive audience, I wonder if the differences in culture will shrink. Maybe we will always depend on cash-strapped studios of slightly desperate iconoclasts for the big leaps.
As someone who spent years as a 'big company engineer', the reason I don't write code until the bosses have clear requirements is because I don't want to do it twice.
That and it isn't just me, there's 5 other teams who have to coordinate and they have other things on their roadmap that are more important than a project without a spec.
As another senior software developer, but at smaller companies, this was my answer as well.
If I start right away, the idea they had in their had but couldn't put on paper will emerge as "No, that's wrong" about a million times, trying to coax my idea into being their idea.
If I wait for their idea to be on paper, they're stuck for it and if I do what they said, even if it's awful, there's no consequence to me. If I do what I wanted, even if it's amazing, it'll be destroyed in front of me and they'll think I'm a screwup because I didn't do what they wanted.
If you're one of the people that control the company, you can afford complete creative freedom. If you aren't, everything you do will be crushed in front of you, and you'll just have to work harder to get back up to speed with what they really wanted.
And I don't even have the "5 other teams" problem, since I've been in small companies. That would make it 10x worse.
I get it, but it seems frustrating to me. Another commenter suggested that a difficulty in non-game development is there is not really a right answer except the consensus answer. Unlike a game, it's not something you can just feel on your own.
The idea that non-game software doesn’t involve creativity or spit balling or iteration is ridiculous. But from what I’ve seen it does involve a lot more waiting for consensus and thinking too far down the road, which are political activities aimed at being right (as measured by vice presidents) rather than productive activities aimed at getting something done or making something cool (as measured by your own name in credits of a completed work offered to the public).
I think the key difference is what the goal is. With non-game software, there's usually a goal of we want something that achieves X - let's create, spit-ball and iterate until we achieve that. X is a measurable outcome - it requires some creativity, spitballing and iteration, but it's easy to see if/when you've succeeded.
With games, things are a lot more subjective. The goal is create, spitball and iterate until you have something that people find enjoyable. You just keep going until you recognise that you've got something worthwhile. It's a "you'll know it when you see it" situation, rather than something you can track your progress towards. Sometimes you can follow a formula/template and iterate on another games' mechanics/systems and people will like it; sometimes you can do that and people will call it a soulless copycat instead. Sometimes games are technically good but just don't feel enjoyable; sometimes they're enjoyable despite any technical issues they might have.
Amazon and Google's issues stemmed from treating game development like any other software development.
It's a "you'll know it when you see it" situation, rather than something you can track your progress towards.
I think you're right, this is a big difference.