Andrew Chen has just written a post comparing the cultural differences between Web industry people and Games industry people. They’re all very interesting, and on the whole I’d say they’re on the money – definitely worth reading (and see if you can spot yourself in some of the either/or’s ;)). At the start of the post, I stopped reading and paused to list my own observed differences, so that I could then compare them to what Andrew had written. There was no overlap, so I thought I’d write them up here.
Cultural differences: game people vs web people
- concrete revenues vs “future monetizable” growth
- team-as-blob vs sliding scale of headcount
- obsessive search for fun vs time-wasting activities
- surprise and delight audience with something we liked and think they want vs randomly guess and test on live audience; iterate until done
- very high minimum quality bar vs dont worry, be crappy
- high, strict specialization vs almost no specialization
- money happens elsewhere, far down the chain vs show ME the money
concrete revenues vs “future monetizable” growth
Largely driven by the “money happens elsewhere” part, game people are obsessive about “what’s the actual revenue this will make (what’s my percentage of the revenue this will make)?”.
In particular, if you cannot *prove* the expected revenue (and in many cases not even that: instead you have to prove the *profit*), they won’t even carry on the conversation. This happens everywhere from small startups to massive publishers. I’ve seen meetings on “social networking” get shutdown by a senior executive simply saying “how much profit will this make at minimum, even if it’s not successful? Remember that these resources would instead bring in an extra $5million if we deployed them on [one of our existing MMOs]”, and refusing to carry on the meeting unless someone could prove that the opportunity cost to SN didn’t exceed its income.
surprise and delight audience with something we liked and think they want vs randomly guess and test on live audience; iterate until done
A team of game people sets out to make something fun. They like to get some input from experts on analysing and predicting the market (market researchers, marketing departments, retail executives, industry analysts, etc) – and then use that merely as “inspiration” and “guidelines” to making something awesome and new. They assume that “the customer doesn’t know what they want, but will recognize it when they see it, and fall in love” (which is largely true!), and so they go off and build something beautiful largely in isolation.
This beautiful thing then surprises and delights the consumer when it finally comes to market.
Web people do the first thing that comes to mind, care not whether it’s objectively good or bad, and test it in the market. Then they try again. And again. And again. And look for patterns in what is popular or not.
As a result, game people tend to think of web people as “skill-less” (partly true) and “puppets of the market” (largely true). Meanwhile, web people tend to think of game people as “perfectionist” (largely true) and “monolithic / unagile” (largely true) and “non market-lead” (partly true).
obsessive search for fun vs time-wasting activities
Game people don’t make stuff unless it’s fun. If it’s not fun, it’s a failure, and only a stereotypically bad EA Producer (or a second-rate clone) would OK the ongoing funding and/or production of a project that wasn’t fun any more.
Web people generally couldn’t care less. They generally think they want stuff to be fun, in a “well, it’s better if it’s fun, isn’t it?” kind of way – but they usually only really care that there is some activity going on, and that the users come back to do more of it. They are less judgemental about the type and motivation of activity going on. They will slave away to try to understand this activity, to extrapolate better ways of motivation people to do more of it, and to monetize people for doing it, but the activity could be selling used cars or real estate and they would not be greatly affected.
This one even shows up subtly in Andrew’s own writeup – he casually uses the word fun. To game developers, the word is Fun, and they would never write:
Now, I think that the productivity-inclined have their claim to the world, as does the fun/entertainment games people. But the intersection of this, in web media, is where the fun happens.
…because you don’t use the word “fun” casually like that where someone might hear it as “Fun”. You are sensitized to all uses of the F word :). Fun would never come from an intersection like that; that intersection could give rise to a number of side-effects and new content areas, and those content areas – with appropriate rulesets imposed – could merge, and react with some of the side-effects, to give rise, finally, to something “Fun”. Fun is not a simple concept.
very high minimum quality bar vs dont worry, be crappy
Game companies have QA departments that are larger in headcount than the entire development team, often by a substantial margin. They don’t ship stuff that is half-arsed, partially complete, partially working, etc. Hence, when they do, there is huge press and consumer attention around it. This is one of the thigns that the games industry has been doing more and more web like over the past 10 years – ever since they realised they could drop some launch-quality and end up with the same level of quality as standard by shipping a “patch” 1-3 months after launch (and probably getting an uptick in sales as a result, re-box the patched version as an “improved” version).
But, on the whole, games companies still consider quality the one unassailable pillar of the development triangle (“quality, short development time, cheap development cost – you can only have two at most”).
In fact, most game people turn “Quality” into 3 separate sub-pillars: core fun, longevity, and polish. And consider all three inalienable, but occasionally flirt with sacrificing one of those three instead of sacrificing either of the two other full pillars.
If it strikes you that the games industry is thereby trying to cheat and get “2 and 2/3 pillars out of 3” then … you’d be right. Understanding this can help explain a lot both about individual games and the industry in general over the past 15 years.
high, strict specialization vs almost no specialization
A game team is (typically) made up of distinct people doing:
- Production (project management)
You need at least one person devoted to each. For teams of size less than 5, it’s acceptable to have some people do two of those roles rather than just one, but it’s often considered “hard”
(by default – although in practice many teams flourish with people moonlighting/two-hatting these roles).
It is an onrunning joke that various non-design people in games companies have the unofficial job title of “Frustrated Designer” (most usually Producers and Programmers get labelled with this). i.e. someone who secretly wants to be a designer, but lacks the skill and experience – despite potentially many many years working in their person discipline, developing and launching games. Nowadays you also see people labelled as Frustrated Artist, and occasionally even Frustrated Programmer (although anyone brave enough to do that in the face of the programmers, who tend to be quite bullish about welcoming such people to try their hand at fixing a code bug (snigger, snigger, watch-him-fail) generally is quickly disabused of their frustration).
There’s good reason for this, too – the expected level of skill from anyone non-junior in a game team is sufficiently high that it can be very difficult for people to cross skills. It’s easy if they’re willing to drop to “junior” status (the level of incoming recent-graduate – very low-paid, and with very little creative or project input/control), but few are willing to take the massive drop in status and (usually) pay to do that.
money happens elsewhere, far down the chain vs show ME the money
Interestingly, perversely, this means that game people obssess about the money, despite never seeing it themselves, and worry about how their actions will affect the ability of later people in the value chain to make money, and how much the total pot will be.
Whereas the web people generally are much more blase about the money side, because they know it’s going to come almost directly to them, and they have a much more direct relationship with it (understand the ups and downs).
Game people’s approach to money is generally characterized by Fear, Uncertainty, and Doubt – plagued by rumour. Web people all know for themselves how much money can be made, and how, and don’t peddle in rumours.
Comments on Andrew’s observations
Andrew’s observations were all good, except for one thing which I think he misunderstood: “By withholding levels, powerups, weapons, trophies, etc., it creates motivation from the user to keep on playing. They say, “just… one… more… game…!!””.
…and then he makes a conclusion that makes sense given what he and wikipedia have said, but which is almost the precise opposite of the truth.
As a result of this treadmill, there is a constant pressure for players to stay engaged and retained as customers. But the flipside of this is that it’s not enough to build one product – instead you build 70 product variations, and call each one a level!
The truth is that content-gating was introduced and/or stuck around as a technique because the cost of creating content is exponentially higher than the cost of consuming it without gating. If you have decided to operate a content-centric game, you are doomed to be unable to run a service product based on it – no matter how many years you spend developing content before launch, your playerbase will soon catch up to your level designers etc and overtake them. Content-gating, levelling especially, forceably slow players down in their content consumption rates, even forcing them to re-play set pieces of content many many times (if you can get them to replay it enough, you can lower their rate of consumption to the point that a sufficiently large team of content-creators can keep ahead of them. Just).
Various other experiments have been tried over the years – most notably, User-Generated Content, but none have achieved the same level of efficiency (or yet been as well understood) as level-based content-gating.
12 replies on “Cultural differences: game developers vs web developers”
As to your final comment… what about games like Poker, Chess, etc. where the reuse of content comes from other players?
Or, procedural content in games like Rogue or Diablo
Or, scoring & ranking systems (how many times did you play Space Invaders back in the day?)
My bad :(.
Levelling and content gating came almost entirely out of MMORPGs, and Andrew’s comments focussed on the MMORPG usage of content gating. My explanation of where it came from – and what else has been tried – was restricted to the MMORG usage, although I didn’t say that explicitly.
But the key point here I think is that the things you cite are either NOT modern MMOs (they are not monetized beyond one retail sale, like D2 – and interestingly (incidentally) GuildWars, which is in many ways the modern remake of D2, by the key people who made it, has struggled to make “content comes from other players” work, even with its “instant PvP” and similar measures), or are from the web people rather than the games people (poker etc).
[…] Adam Martin (formerly of NCsoft) writes up his views here, from the perspective of a games […]
I’d add a couple more. These are from console/PC gaming side, so might not apply as much to MMO/web games.
Games vs. web:
– little/no direct relationship with the customer vs. obsessively monitoring customers, direct end customer support
– building what you love vs. building what other people love (and you might too)
– huge tech focus & preferably in-house vs. use anything that works, mash-up
– closed communication across companies vs. everybody twitters, blogs, rants, raves
– high staff retention for years (comes from the needed specialization) vs. moderate staff turnover
– little brother syndrome with movies vs. we are the new overlords of media
This article rings so true for me. I used to be a game designer and now I’m doing a (non-games) web product, and I’m always having to reign in my game designer tendencies. For me, I had to decide to avoid games altogether to avoid falling into this trap!
It’s difficult to merge the desire for creating quality experiences with an experimentation mindset. I think one way to put it, in the context of A/B testing, is that as a game developer you settle on a single version of every decision you make. On the web and with rapid iteration, you pick a few of the best versions of every decision, and then test them all out. Somewhere in between is of course the answer – be perfectionist and think deeply about the fundamental experience (‘knowing what the user wants’), while laying off the perfectionism and shifting to experimentation on some of the smaller decisions.
And I agree: Fun-bombs shouldn’t be thrown around lightly.
Jussi – interesting list. I can remember examples of each of those, but most I haven’t seen for a long time, probably because I’ve been in MMO companies.
The tech one is still prevalent even in MMO companies IME, and the “lack of communication” one is endemic at some MMO companies, present/absent based on dept at others, and absent at the rest.
Maybe this is a sign that the MMO companies really have made some substantial transitioning steps forward, which would be good. Would you say these are all still current at PC/console companies? I’ve seen a few at console companies recently, but only as an outsider, so it’s hard to say how indicative those glimpses were.
Adam, these are current as I transitioned from PC/console games just a couple of months ago. Of course, these are the viewpoints of a pureplay developer, and developer-publishers (as in MMOs) are quite different.
I believe the reason MMO companies have overcome many of these hurdles is that they have direct end-customer relationship. A traditional game developer (an independent studio) doesn’t have that level of contact or resources. Unless you are Bungie or Valve, or a big publisher-owned studio like Infinity Ward, your scarce resources will go directly into making the game.
Yeah, good point about the CRM. I like your:
“- little/no direct relationship with the customer vs. obsessively monitoring customers, direct end customer support”
Many years ago, when I was doing MMO server middleware, I had a diagram showing the value chain for MMOs, and how the decision of our major competitors (companies like ButterflyNet and Zona) to try to “own” the customer relationship meant that any developers using their services were jumping out of the frying pan and into the fire.
There simply isn’t any point in trying to run a “Service, not-a-Product” for end-consumers if you don’t own the direct end-consumer relationship! :). I was confident that Butterfly, Zona, et al were doomed from the start by their choice to steal the customer relationship – it could only doom their clients (the game developers) which in the end would leave them with NO clients.
Sorry to harp a bit, but you called this “Game Developers” not “MMO Developers”…
as picked up in the comments, MMO Developers are essentially a third category, separate from either PC/console game developers and Web developers.
I would argue that casual game developers are also a distinct category in that they do embrace the techniques I mentioned.
In the MMO world, certainly Eve has embraced PvP as a central part of its strategy and, I suspect, helped them keep their content generation costs under control.
Is there a continuum with “PC/console Game developers” at one end and Web developers at the other?
[…] And then Adam says in “Cultural differences: game developers vs web developers”: […]
[…] and funware developers is the basic motivations that drive them to do what they do. My opinion is stated quite well by Adam Martin. Game developers work from an assumption that "If it’s not fun, it’s a […]
[…] increasing the profitability and decreasing the development cost of any MMO, although probably no-one except the web-people will recognise it as such (and even some of them won’t get it): How do you improve the customer support for an […]