LOGIN 2009: Middleware Roundup

Moderator: Joe Ludwig (JL)
Patricio Jutard (PJ), Three Melons
Chris Dyl (CD), Turbine
Rick Lambright (RL), Gazillion
Mitch Ferguson (MF), Carbine


A lot of nice little anecdotes about MMO middleware experiences – but it would have been nicer to have had a lot more detail on them (not easy to do in panel format).

The panellists briefly touched upon several few sacred cows – such as “Is it absolutely essential to have the full source code to exernally-licensed middleware?” (which I’m glad to hear being questioned – with server middleware especially the developers are hopelessly underqualified to understand huge chunks of source, even at a debugging level (e.g. the many cases where the devs simply cant practically debug distributed-system source)). There are good reasons for having source (and the other sacred cows) but more questioning and more critical thinking from developers about what they *really* need and especially what they’re going to *do* with it would be good for everyone, I think.

Any mistakes understandings and misattributions etc my own fault. My personal comments in [square brackets]


If you were going to make a new engine/MMO today, what middleware would you use?

PJ: we focussed on web based games when we started. We decided to use Unity, no royalty sharing made it a very attractive pricing model.

CD: hypothetically … I’d make substantial use of middleware, although we didn’t really at Turbine because it wasn’t there when we started.

RL: we look at what’s going to be unique about the game design we’re starting, and then look for middleware that matches well with the uniqueness of the individual game, whatever gets us a good chunk of the way towards that.

MF: we’ve decided each time to just do it ourselves.

How do you deal with the risk of using middleware code that’s never been used in a shipped MMO, that you’re the first major user of / the other major users haven’t shipped yet?

PJ: make sure you have the source code (although we couldn’t afford the more-expensive source-code license for Unity), make sure you have good support and responsiveness from vendor Tech Support.

CD: make sure the vendor is committed to the vertical business space, that your success is part of their core product strategy

JL: being first shipping user can get you a big price discount from the vendor

RL: with BigWorld we don’t have all the source. You have a limited number of engineers who’ll be skilled enough to do anything meaningful with that source anyway, and they could quit, leaving you in trouble. We have a commitment that if something exceptional comes up then we have the *possibility* of the vendor giving us source access temporarily, with their engineers physically present at all times, but we hope not to need that.

MF: any middleware that includes game design / game-logic elements is highest risk. I’ve had low-risk pieces of middleware fail, but that’s quite easy to workaround because it’s got relatively little effect on the overall project. I don’t want to name vendors in particular examples, because it’s not necesssarily their fault.

JL: we used SpeedTree for a couple of years, but eventually didn’t ship with it, because it couldn’t integrate with our art pipeline. Not a bug in that, just unfortunate accident of how it works and how we worked.

CD: we had the same problem with ST.

CD: the two scariest middlewares we used at Turbine were having Physics, and Kynapse for path-planning. Do we de-stabilise our live servers by integrating this cutting edge middleware new version in? As an MMO operator you really want to be able to keep an old version in situ for a long time – maybe a lot longer than the middleware vendor actually wants you to have it there.

[ADAM: that’s an extremely interesting problem…]

We had a big problem with a middleware engine where the provider just went out of business. We got some support from our publisher there to work through it, but what do you do about that?

CD: source code escrow is a good thing, for the absolute disaster scenario. But it’s really no different from other catastrophic business risks. Make sure you have one (more than one) person who’s been over the source in detail with the vendor at least once, so understands it well enough to pick up if they vanish, etc.

RL: escrow is mandatory, including all the required libraries, correct verisons etc.

[ADAM: nb: same speaker who doesnt have full source for some aspects of BigWorld]

JL: we didn’t escrow Alchemy, too naive to realise we should, but we got someone to send it to us as they were going out of business. Just getting it to build was a huge problem, we found.

[ADAM: our industry is still cursed by the fact that almost no-one has a great build system in place :) ]

MF: with Renderware we had source for the main thing, but there were dev tools that we had no source for, and so we couldn’t fix bugs in the tools, it was a nightmare. Very fine Modularity of your middleware – which doesn’t really exist yet – would be a real saver in this area. A hyper-modular middlware, I think that would make the risk much lower. Then if the company did go out of business, you could replace those building-blocks one at a time. I think that modularity is very important, or as close as you can get.

[ADAM: ha. I fought hard at the tech level to keep exactly that as one of the top 3 features of our server middleware back in 2002, but unfortunately back then (my naivety in assuming developers understood more than they did) no game developer had anywhere near enough understanding of the problems to realise how valuable that was. Ultimately, it was a waste of money for us as a company, because no customer understood it enough to place the value on it that would pay for how much it was costing us to achieve and maintain it. I’m not convinced that’s changed enough to make it profitable enough for MMO providers – even if developers now see the theoretical value, I don’t think they are able to really afford it]

Audience: Given how heavy the sales process is … is there a role for open source (OSS) in this?

MF: I think OSS is actually necessary for our industry to remain profitable, to reduce the cost of development. If I say bad things about middleware it’s not because I want it to fail (I really want it to succeed, I think it’s critical for us), but because I’m so disappointed with the current state of it.

RL: how many games have Python in them? Well, that’s an example of OSS that’s now heavily in use. We have an enormous amount of OSS we use inside the backend systems / servers.

What are the packages are you using for service side?

CD: we use a 3rd party billing system, that I wouldn’t actually recommend. We chose it many years ago, and it isn’t really right for what we do now.

(audience): there’s big advnatages to using external billing provider, e.g. benefit of having someone else as the merchant of record, isn’t there.

[ADAM: personally, I think that’s short-sighted, because in many ways the last thing in the world you want to have happen, as a service provider, is be disengaged from the customer’s wallet. Never let someone else come between “you” and “your customer’s money”; they can handle it, facilitate it, but not take over the CRM]

What about internal middleware? A lot of companies form Core Technology teams, creating a culture of making MW for internal use, re-use in other titles, etc

CD: D&D and LoTRO have the exact same codebase on the platform level because of our internal middleware. We ported the LoTRO DirectX 10 layer as a full working initial Dx10 directly into D&D, without changing it.

RL: the question comes down to whether you have a very specific target for what you’re doing. If you try to make one engine for all your games, and/or all your studios (if you’re multi-studio) then that’s a route to huge difficulties and disasters. At the same time I’ve seen companies that have huge in-house expertise in their internal wide-use engine and are able to churn out new games easily. But I think it’s a really really difficult problem to solve that way.

CD: we can have a full game prototype from zero to running in 3 months because we have all this internal re-usable code. For a relatively low investment we can build a small portion of a world to try out new game concepts.

[ADAM: I’m guessing the caveats there are simple that the content-cretion costs are of course still directly proportional to how much you want to show – hence “build a SMALL portion” etc]

MF: It was painful sometimes when the company was going down that they weren’t helping on the games themselves directly, but when Perpetual folded, the core tech group, the reusable code, was the one part that they managed to sell off. Clearly it has a lot of value, even if it’s painful getting there.

PJ: I think it makes sense to have one team on gameplay and building things, and one focussed on technology, because it’s different expertise for the staff to have.

What about MMO Middleware on consoles? Will midleware bring MMOs to consoles finally?

CD: it’s absolutely helped the transition, you’ll see stuff very soon where it’s facilitated console MMOs.

RL: stuff that’s provided to you multi-platform is a huge win from using middleware.

Questions from Audience

Q: sounds from what you’ve said here today like the state of the middleware industry today is fragile and embryonic?

MF: I agree. I think it’s a difficult industry. Business model is tough, it’s sales heavy, hard to get your cash in when people go under –

JL: – that’s what happened with Intrinsic, they had agreements with lots of companies paying a small amount each month towards the license fee, and when a few of those went out of business, the sudden cashflow damage killed Intrinsic

Q: what are your experiences with the multi-platform engines?

RJ: we tried most/all of the flash stuff. We’ve found Unity to provide the most-productive pipeline, fast and easy to prototype with, works nicely with our dev methodology (scrum).

RL: the more MMO development you do, the more you realise it’s all about the tools. The content-creation tools etc become more important, ultimately, than the engine itself.

CD: the cost of developing an MMO is never the technology, four or five times that cost is the cost of the content-generation. So the more efficient your tools are, the quicker you can get final game-content being made, that’s key.

Q: (from MF) does middleware “help” or “hurt” innovation?

MF: I feel it could hurt quite a lot. e.g. Some years ago, I could not find any middleware that would support instances, so we couldn’t use it.

CD: agreed. I think something monolothic like BigWorld could be particularly limiting, but the piecemeal approach of lots of little parts, increased productivity, actually I think helps innovation because it helps on your dev-resource costs a lot.

Q: are any of your perspectives on middleware non-technology centric, it’s been very tech-centric so far? I’ve seen a lot of recurring frustration with middleware. What kind of heuristics do you use to establish whether middleware is the right choice?

RL: you should never take a fully-staffed team and then dump in middleware on them. The two should be built hand-in-hand; middleware changes your hiring needs, and vice versa.

CD: Tech is always both an enabler and a limiter.

Q: as a vendor looking-in … we see particular teams (art vs code vs design) a lot more vocal than others, and the decision to use/not-use it gets skewed.

RL: the purchase decision is often lead by the lead client engineer, server stuff gets ignored, which is clearly wrong.


iPhone OS updated; developers let down by Apple (a little)

What’s in it?

Nobody knows – Apple didn’t bother with release notes for this 1.75GB monster. Allegedly, there aren’t even release notes inside the download itself.

What apps will it break?

Nobody knows – Apple didn’t allow developers to test it before they put it live.

What does Apple have to say about it?

I don’t know – the official developer site has zero coverage other than the download link itself and a short note to say it is “mandatory” and that it might break your phone if wrongly installed.

More to come once I’ve got it working…


Thunderbird Beta (Firefox-related email client) finally available

If you’re still muddling along with Outlook, or suffering under the curse of some hopeless rubbish like Apple’s OS X Mail, salvation may well be on the horizon… ThunderBird version 3 is now in beta (and looks like it will be the first version of TB that will be usable as a general email client; IME the previous releases never really worked properly). Try it out!


Arrange a meeting in multiple timezones

Lots of people are using Yahoo’s Upcoming more and more these days, going by the invites I get (many have switched from using Facebook to using Upcoming recently). But it completely sucks for arranging anything in a foreign country, or where people will be attending from foreign locations. Common examples:

  • Any meeting, event, or party at an international conference; many attendees will be flying in a day or so beforehand
  • Conference calls with people in more than one timezone; conference calls tend to be with multi-timezone, otherwise you’d just have a face-to-face meeting

I’ve tried lots of things, and although Outlook 2003 and beyond have some moderately handy tools for this (you can view “2 timezones simultaneously”, although IIRC *only* 2, sigh), 99% of the time I need something web-based that anyone/everyone can use. And today I found this piece of awesomeness:

…which produces things like this:

(I would insert an image here, but unfortunately – despite the claims of the Debian maintainer of WordPress – Debian WordPress still can’t do file uploads, and WordPress’s authors haven’t fixed their extremely poor approach to file uploads. Sigh)


Thunderbird 3.0: stick with Alpha2

Mozilla just released Alpha3 of Thunderbird version 3; my advice: don’t bother.


Virtual Worlds Forum Europe 2008: “Show Us the Money”

(Monetization options for Virtual Worlds)

VWFE 2008 (Virtual Worlds Forum Europe) got cancelled because the venue was taken away by the Police, so the organizers arranged an emergency Unconference for today instead. I decided – with only five minutes of prep (this is an Unconference…) – to do a session on “ways to monetize virtual worlds”.

I ran this session, so I took very few notes, sorry.

So … if you weren’t at the session, you probably missed most of the good bits :P.

dev-process games industry recruiting startup advice Uncategorized

What’s the future for Game Development Studios?

(this is part 2 of Publishers are from Mars, Developers are from Venus)

Last time I said that “good Developers are very similar to Valley Technology Startups”, which suggests one obvious way things could develop:

Publishers to become Venture Capitalists; Developers to become commodities

In this model, the Publishers spend their time “speculating” in Dev studios: instead of buying a studio in order to own the output of that studio, you buy it with the intent of later selling the studio itself at a profit.

This is a good model; as I first heard from Jack Lang, at one of the Cambridge Enterprise Conferences many years ago:

“The best way to get rich is by buying and selling things. Preferably companies”

IIRC it’s a quote that’s been around for a long time, but I can’t remember where the original quote came from, unfortunately.

(of course, this observation is why Publishers are box-shifters in the first place: simply buying and selling things is an easy, fast, stable, sustainable way of making a very large amount of money. It’s not particularly creative, perhaps, but it’s a very efficient way of generating profit, and lets you leverage your resources/cashflow way above the profit you would generate simply from manufacturing your own goods and selling them)

The real beauty of this is that – as Jack’s quote illustrates – a Publisher and a VC have very similar fundamental business models: they buy stuff that they have no intention of using themselves primarily to sell those things at a profit to other people. In both cases, the less time the company can hold onto the products, while getting the same price differential between purchase and sale, the better. What is a VC? A VC is just a higher-value version of a box-shifter. So, for a Publisher to diversify into being a VC may not be so difficult…

As someone who’s been through the mill of raising finance for startups before, I’d also like to add that “funding game development” is commonly thought of as having no equal in risk and unpredictability – save “providing venture capital for a new startup”. The hardest part of being a VC – the insanely high risks involved – is bread and butter for Publishers, who routinely spend tens of millions of dollars on stuff they don’t understand, cannot effectively control, and cannot reliably predict!

Studios would find that:

  1. Publishers would look after them more – you don’t want to harm something you’re planning to sell
  2. Funding and marketing decisions would be driven more by what was in the interests of the studio rather than the Publisher’s marketing dept or cashflow
  3. Publishers would stop being stupid about trying to “reduce costs” of development purely for the sake of it
  4. Publishers would be a LOT more interested in supporting and creating external partnerships for the studio, especially where those partnerships involved competing publishers or their subsidiaries (because that would make it easier in the future to sell the studio to that competing publisher), which would help reduce development costs (a little) and increase productivity / quality of working environment (probably a lot more – publishers usually consider this too little justification for allowing such things)
  5. If the publisher got cold feet about publishing a certain game and it was far advanced, they would push for POSTPONING it rather than RUSHING it – they’d rather sell the studio BEFORE it publishes the game, and “price-in” the potential of the game than sell AFTER the game had launched and flopped
  6. The publisher would push harder for maintaining quality standards of the games output by the studio – they have literally invested in the brand of the studio, a brand they are planning to build up in value as much as possible, before selling

Publishers would find that:

  1. Development costs would no longer mar their balance sheets and make their financial performance look bad; the offset of being able to mark the studio as a sellable asset with a quantifiable value in excess of the money being poured into it would make it all smell sweeter to shareholders
  2. There would be less friction with studios, leading to better communication, less frustration, and probably better overall quality of product – and hence, more profits
  3. Studios could safely be given more leeway to make strategic business decisions that were “right for them”, offering the possibility of mega-wins for the publisher whenever those paid-off (e.g. the decision by early FPS developers to not only allow but encourage modding was enough to terrify publishers even today, and yet a massive win in sales and profits), but also to not have to take responsibility – and blame – when they failed; this would all be priced into the “value” of the studio as a separate, tradeable, entity
  4. If a studio made some bad strategic decisions that led to commercial failures, that might actually INCREASE its tradeable value, if the market perceived that the studio had “learnt” significantly from the mistakes; potentially, such increased value could completely offset the actual financial losses incurred from the mistake

A practical example

I’m just pulling this out of thin air, trying to think of a studio that many years ago was worth something, got acquired, went internal, and now is probably worthless. When EA bought Westwood Studios, one of the things they paid for was the brand; how much value did they really extract from that brand? How much value does it have *today*? Today, it’s probably next to none – customers don’t care, and other games industry companies all know that the real meat of Westwood Studios (the staff, the equipment, the processes) was disbanded shortly after being bought by EA. Could they have made more money by promoting and protecting the WS as an owned-but-independent studio? If they’d taken that route, and even if they had made less money than they have with the route they chose, would it be more than made up for by the fact that they might be able to sell WS right now for, say, a couple of hundred million dollars – if only it still existed as more than a name?

And why not?

But this isn’t the way Publishers work right now, so … where does this plan all go wrong? Why hasn’t it happened already? What might prevent people from trying this?

1. Cojones

At the moment, the funding decisions that Publishers make are so distantly removed from the actual point of capitalizing on them that it’s quite easy for the people making the funding decisions to blame many other departments and personnel within their organization should the investment go poorly. Indeed, this plausibly deniability, this easy abrogation of responsibility by the decision makers – and the great distance between them and the people actually implementing the game – are root causes of a lot of the practical problems in the Publisher/Developer relationship whenever they do “external” publishing (i.e. publish a game made by an independent / external studio, as opposed to a wholly-owned internal studio).

A lot of the benefits for the New Way cited above stem from removing that indirection; that means a bunch of people making hundred-million-dollar decisions would be exposed to rather more scrutiny and responsibility than they hold right now. I’ve heard people (usually the ones who don’t really understand VC’s, have acted naively or foolishly with them, and come away poor and bitter) describe VC’s as “arrogant”, “bullies”, and “too demanding”; while I don’t agree with that, just think how you’d act if you were the named individual responsible for a handful of $10million investment decisions, and how that might come across sometimes. Could the individual people working for Publishers accomodate such a change? If they were content with that level of personal exposure to risk, would they be working in the games industry, or would they already be working in the higher-paid VC industry?

2. The Art of the Sale

Another issue is that the success of selling a studio depends on, well … your ability to sell!

Publishers do not, generally, have any experience of selling companies. A publisher might spin-out or sell off one division every decade, at most – and many of those are instigated by the division itself (management buy-outs), or are fire-sales (find a buyer at any cost, no matter how low). They don’t have staff who are experience in doing this, they don’t have any contacts suitable for doing it, and they don’t (generally) maintain the level of immersion in the marketplace of studio buyers to be able to setup great deals when selling on a studio. Look at how much time the individual staff at VC’s spend purely “networking”, both looking for things to invest in (new purchases), but also looking for, befriending, understanding, and keeping up to date with the needs and desires of potential buyers (people who might acquire some of their portfolio).

3. Organizational Change

Lastly, have a look at the typical VC organization – a handful of Partners (maybe half a dozen people who make investment decisions), a handful of Entrepreneurs in Residence (EIR – maybe one or two domain-experts who make recommendations and help in due diligence). This is enough to manage billions of dollars of investments.

Now look at the typical Publisher organization – 50 people in each of marketing, customer service, and sales, perhaps 15 handling external develoment (finding and making development/publishing deals), and another 10-50 people in internal support roles. This is enough to own 1-3 development studios.

This isn’t to say that Publishers would need to downsize. Rather, it’s to point out that if the external development side started doing sales of studios for as much as $100million a time, their revenues and profits would suddenly massively eclipse (20 to 1, perhaps even 200 to 1) the whole of the rest of the organization, despite being outnumbered more than ten to one. Sooner or later, the “rest of the organization” would become politically weak and subservient to the massively profitable “trading in ownership of development studios part”.

The VPs of the current departments may well find that the total pie they’re sharing in becomes much bigger, and much more than makes-up-for the fact that their slice has got smaller, but will they accept their slice going from being a “Vice President” sized slice to a “Operations Manager” sized slice?

A few little Notes…

1. When I wrote Publishers are from Mars, Developers are from Venus, I had *no idea* that NCsoft had just decided to shutdown its European development studio, and make a swathe of redundancies in European publishing. Sheer coincidence, and sad for a lot of people involved, but very interesting nonetheless.

NB: if you work for a publisher or developer and are interested in picking up any of the good NCsoft Europe staff, especially development, QA, localization, and customer support – and you have jobs in or within commuting distance of Brighton – let me know. Lots of people are suddenly looking for stuff to do next…

2. I said that “Developers exist to make a loss, every day”, and some people questioned that.

Yes, I really mean this: the more they spend, the greater the potential profit, and they should be maximizing their potential profit. Obviously, there is a point of diminishing returns, but generally speaking whenever you have an R&D lab, you want to pump as much money into it as you can possibly spare. Generally, R&D labs are rather good at soaking up almost infinite amounts of money.

Compare the revenues and the expenditures of, say, GTA IV with those of Bookworm Adventures. The latter may have been much much more profitable in percentage terms, but the former made a bigger amount of money overall. Often, the sheer amount of money you make is more important than your profit percentage.

3. I decided to write these blog posts after a comment I made to Steven Davis about the problems of publishers owning development studios, which he replied to with “Actually, the publishers should fund these things like a movie studio or VC. Let them be independent, get them off the books, and use your money to control distribution or via publishing rights.”

I’d been thinking along similar lines, but I also realised I saw some big problems with the approach, so I thought it would be interesting to explore in more detail. But if he hadn’t made the comment, I probably wouldn’t have got around to it :).

dev-process games industry recruiting startup advice Uncategorized

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 – 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


Java Web Start / JNLP maker

A few years ago I wrote a web-service that would automatically create JNLP files, making it much easier to deploy java applications. They’re just XML files, but they have some very odd syntactical quirks and can be a pain in the ass to get working correctly. This post has an early alpha version that works as a downloadable application you can run from your desktop.


Funorb first impressions

(the new casual games portal from Jagex, the people behind Runescape)

– good game/website integration, very smooth
– very basic game design – most games seem to ahve never been playtested, or designed by very novice game-designers. Most simply aren’t fun, and need just a few basic tweaks.
– control systems mostly awful, bouncing and snapping and with unnecessary lag.
– No ability to see your achievements! Achievements rock, but they don’t seem to understand the main point of them – showing them off.
– artwork and sound are extremely polished.

– a very highly-polished (graphics, sound) attempt to clone Pogo, but without fully understanding how and why it works so well, and ultimately coming tragically short. Go play Kongregate instead – its much more of a mixed bag, but the overall experience is much, much more satisfying.

(Notes from several weeks ago, accidentally clicked save instead of publish at the time)

computer games conferences databases GDC 2008 massively multiplayer Uncategorized

GDC08: SQL Considered Harmful


Speaker: Shannon Posniewski, Cryptic

I was expecting something shockingly naive and/or stupid from the title of the session. The first thing the speaker said was that the title was completely wrong, so I ran with that. With that out of the way, the talk was fine, although small things kept coming out during the talk that were hard to believe or worrying claims.

So it was going OK, until … right at the end, just before the Q&A, and partly during the Q&A, the speaker dropped some serious shockers:


Re-install complete; blog should be OK

Someone brute-forced their way into the server last week, my fault for not disabling all logins to the server.

Normally, this isn’t a problem, as the default firewall setup I always use prevents any remote logins except from known-good hosts. However, this server was accidentally provided with partially missing firewall code by the hosting company, and so I couldn’t run my firewall without first upgrading the kernel. And I’d been “too busy to get around to” doing that…


Server got hacked; has now been wiped

Sorry, the entire blog is temporarily offline whilst I re-install the server. Will be restoring from backup imminently.



First Post

oh, the excitement.

oh, the drama!

Another First Post from Adam…