Publishers are from Mars, Developers are from Venus

Over the last few years, there has been a big shift in power and success away from independent studios, and towards in-house, publisher-owned studios. This has been driven by several things, sound economic reasons, competitive reasons, and because the strong independent studios had done a good job at creating a slew of new IPs (which publishers were eager to snap up, as always).

In my experience relatively few people in the games industry realise this, but all these things are cyclical (it’s a lot more obvious in non-niche industries, like the IT industry, where you have many more companies, and the billion-dollar companies can’t be counted on one hand). So, what’s next? What’s going to happen over the next 3-5 years?

Some (recent) history

My last job was working for a large publisher (NCsoft – http://ncsoft.com) where we were setting up a new internal development studio from scratch. When I arrived I there was only one other person (plus my manager). We were doing a lot of other things at the same time – external development, pitching new internal projects, etc – but over the course of the first year I spent a lot of time looking at what we had to do to get a studio up and running, starting from scratch.

Interesting and fun. But also … surprisingly difficult. I’ve been one of the first employees at a couple of startups, and founded some, so I’m accustomed to starting up teams and departments, and a lot of the problems we encountered with this studio were just variations on familiar themes. But then there were also some new ones, side-effects of being inside a huge, well-established, publisher – one whose head-office was on the other side of the world, where the vast majority of the staff didn’t share any languages with the vast majority of the publishing office in our country, and our staff.

To summarize: the things that should have been completed fast were incredibly slow, and the things that should have been easy often turned out to be extremely hard. My definition of “should have” here is based on “whatever plays to the strengths of large corporates”.

As that became clear, one option would have been to throw up our hands and say: “this company is crap! No other similar company works this way!”. Instead, I dug deeper, and tried to understand how it was that we seemed to be seeing a lot of the opposite of what I expected. Sure, a lot of it could be explained by some over the top internal politics, and some by issues with individuals, but … this is a billion-dollar public company, and it’s foolish to think that management could be so weak and disorganized that a few internal battles and a few individuals could cause major aims of the organization to fail. No, there were underlying problems that were natural side-effects of the way the company worked. IMHO, these same issues are almost certainly causing problems for other internal development studios already, and will probably be major contributory causes of the move away from internal studios (when that day comes).

Publishers exist to make profit, every day; Developers exist to make a loss, every day

I could stop there. In that one sentence is encapsulated a problem so powerful and subtle that it’s more than capable of causing all the secondary problems – the ones people actually notice – that lead to publisher/developer acrimony when the two are together in the same company.

A traditional publisher is a box-shifter that pays a hefty license fee for exclusive rights to import a popular, trendy product from a foreign country. The things they need to be good at are:

  • Identifying the Next Big Thing, and signing an exclusive deal before anyone else gets it
  • Efficiently importing that thing and distributing it out to mass-market consumers (this is where most of the opportunity for profit exists)
  • Persuade as many people as possible to buy the product, as quickly as possible, for as high a price as possible (this is where ALL their revenue comes from)

Why did I mark the SECOND point as the point for profit? Because profit is extracted through the differential between the costs generated in that bullet point, and the price point that the publisher – arbitrarily – places on the product as sold to retailers (who then, typically in retail (forget the games industry – this is normal for all industries!) double the price again before selling to consumers).

The price point can be … anything you want. The volume you sell comes from the third bullet – but you have NO control over how much you sell. You *try* to sell as much as you can, but you cannot wake up tomorrow and *decide* to double sales. However … in contrast, you can wake up tomorrow and *decide* to halve costs. Or double them. So you focus on that middle bullet point: Efficiency (while making sure you assign a healthy slab of money to a sales + marketing department, and set them “targets” to try and meet).

A traditional developer is an R&D (research and development) laboratory. They try to be as scientific as possible, whilst spending every day working with masses of unknowns (and several unknowables – what is “fun” anyway?). After working for an indefinite period of time (no way of telling how long it will take) they’re trying to create (or discover) something that has never been created before, and which satisfies various criteria – many of which cannot be measured until after the project is complete.

They absorb money like a dry sponge in a puddle, with very little to show for it. The things they need to be good at are:

  • Securing as large a pile of resources as they can, and spending it to the fullest
  • Trying crazy stuff that they can’t explain, and waiting to see what will happen
  • Sticking as close to the cutting edge as possible, and always investing in long-term improvements

Why do they have to secure a large pile of resources?

Because their success is limited only by two things: their resource, and their skill. That translates into three concrete things:

  • How good is their equipment? (”equipment” means EVERY TOOL they use to do their work – including lots of indirect things that you may not think of as “tools”)
  • How much reagants and raw materials do they have? (everything consumable … including “time” … that could contribute towards doing MORE experiments)
  • How good are their staff?

Those three things are, in turn, only limited by “money” and “the quality of the people they hire”.

Publishers hate this. No, that’s not strong enough; Publishers REVILE, DESPISE, RESENT and LOATHE Developers for always, ever, and only going after those two things. And … they don’t understand it.

Frankly, as a box-shifter, with “efficiency” your only concern, WHO GIVES A F*** HOW “GOOD” YOUR PEOPLE ARE?

But that’s not the worst. No, the worst is this: as a box-shifter, the only thing you can directly control is your costs. Everything in your business, from the structure, to the choice of staff, to the processes, is designed to reduce costs. And what does every R&D laboratory obsessively try to do? Yep – raise costs!

If you ask a Publisher to create, fund, nurture, and partner with a Developer, you are asking the staff to encourage, to aid and abet, the one thing that you are already telling them every day to hunt down and destroy. Capiche? Does anyone see a problem here?

Developers in the Wild: R&D for profit

Well, this is clearly insane – how could a Developer ever make a profit? The answer can be found most easily by looking to the one place in the world where R&D laboratories make more money than anywhere else: Silicon Valley.

In the Valley, the Technology guys have become Entrepreneurs (or found an Entrepreneur to work with), and they’ve gone out there and applied their intelligence to a new problem: “Given this thing I’ve created, which is novel and cool and awesome, how could I use it to drive a product that people would pay for, and which (because of my NEW tech) I can sell cheaper than what is available, or (because of my NEW tech) does something people have been trying to pay for but been unable to find a working solution for?”

Despite appearances otherwise, good Developers are very similar to Valley Technology Startups: it’s all about the monetization, the capitalization – what bridge are you going to build between “what you’ve created” and “someone who has money and a problem”, and HOW are you going to build that bridge?

“Sell the exclusive publishing rights” is one bridge. It can be built many ways.

“Create an infrastructure that lets us deliver this product to the public, and take money from them” is another bridge, with just as many potential schematics.

But then there are others too, many others. Just because those two are the ones that the game-playing public tends to talk about (and are the two that Publishers are most familiar with) doesn’t – by any stretch of the imagination – mean those are the only ones that exist. Ask Blitz (an independent developer) about their Advergames for Burger King (definitely not-a-game-publisher). But, in general, just like in the Valley, the “other” bridges are tricky to invent, and tend to make someone rich just once or twice once invented and done for the first time. There are always new bridges to invent, and if the Technology person’s main role is to invent new tech, the Entrepreneur’s main role is to invent new bridges. So don’t be surprised if you find it hard to think of some.

What happens when a Publisher catches a Developer, puts it in a cage, and ships it back home? Or, more specifically, what do they do to the people that are thinking up innovative new bridges for monetizing the Developer’s assets, and trying to implement them? I’ll give you a clue: if everyone you know believes the world is flat, and has never walked more than a few hundred miles, and one day you meet a person who claims to have walked around the circumference of the planet, would do you do?

Yep. These people tend to be first in the firing line when nerves start to fray and the tensions between Developer and Publisher flare up. They’re an easy target – they make no sense to the Publisher, and their very existence is an affront to their core business model, to their box-shifter mentality (it suggests that the box-shifter is doing a simpler business, something run by simpler, less imaginative, more stupid, people).

UPDATE: I’ve just written a followup looking at one of the possible future directions coming out of this

6 Replies to “Publishers are from Mars, Developers are from Venus”

  1. it’s all about the monetization, the capitalization – what bridge are you going to build between

    With many Silicon Valley startups it’s about capitalization and ATTENTION, at least in the early stage. There are tons of well known entrepreneurs out there that push new startups to value traction over profit, and what they mean by that is page-views. As a result, most of the startups never turn a profit and are “monetizing by VC.” If they’re lucky, they’ll be purchased by some big company that CAN monetize users, pay off all the investors, and keep everybody happy.

    That’s not all that different from how development studios work. They tend to lose money (or at best break even) until they are eventually bought by their publisher.

  2. Oh, awesome – I hadn’t noticed that implied assumption I’d made, but your point leads perfectly into what I wanted to say next :). I only stopped because I thought I’d waffled on for too long already :).

  3. I’m not sure that developers exist in order to make a loss (wheras I do think publishers exist to make money); but I’ll give you that they cannot help but make a loss through their primary activity (writing code).

    I think one of the key things that needs fixing with the “traditional” model you describe is getting to profitability ASAP. Often, with large games titles (or any other large product), the development process is a massive time/money sink that must be recouped from launch onwards. Usually, this requires investment upfront for the new company – eg, in the form of VC – or else nothing could be made.

    But what if your first goal was to bootstrap the business, rather than the product? That might be more doable with an MMO or subscription service than a “traditional” game. If the service is profitable earlier on, it becomes easier to justify developer time on adding new features, because the money to pay said developers is already there.

    Somebody asked me in my Develop talk how, if you were building a really expensive MMO, you could justify spending more time developing features post-launch, and all I could really say is “launch sooner, launch with less, spend less on release 1.0, and work out the minimum you need to make people pay”.

    In the Valley, as well as the web start-up scene in the rest of the world, the VC-less startup is becoming more and more common. When you’re running off a fraction of the costs – maybe some savings, maybe an individual investor – you have to get the business model up and running as fast as the product, if not faster, and that seat-of-the-pants approach seems to work pretty well for those willing to risk it.

    I’m always amazed at the surprise at this conclusion: that making stuff profitable makes you money. It’s the Nintendo equation: everyone wonders why Nintendo does so well out of products it doesn’t drop the price much on, and products it doesn’t ship as many of as competitors, and it always comes down to the fact that Nintendo doesn’t ship loss-making products. This is Business 101, surely?

    I think your point about building “new bridges” is a very good one; there are other models than “make loss, recoup loss” and they need investigating. (Right now, “build to flip” is also looking ever more questionable as a model for web/tech startups; I wonder if that will change will cross over to the games industry soon).

  4. That’s an interesting perspective, Adam. I haven’t been a Developer (capital D) but I have been in startups before. You’re right – it feels “exactly” the same. You focus on your burn rate and you make sure your team is the best you can recruit.

Comments are closed.