Developer-Player Communication, Part I
Why are some studios open and eager to talk about their upcoming projects, and others notoriously close-mouthed about the same subject? Talking about what’s in the pipeline can have a beneficial on the community surrounding a studio and a particular game, which can be a useful thing to build up during the run-up to the game’s ship date. Not talking can tend to irk fans, who may not have a particularly clear picture of how the game development process works and may not find the developers’ explainations concerning their reticence particularly suitable. On the surface it looks like discussing the development process with fans has the clear advantage. So why is it so uncommon?
Not surprisingly, there’s often a fairly strong correlation between candor and size. Small companies tend to be less formal in their operation, and the sorts of communication we’re talking about here is generally considered somewhat informal in nature. Of course there are exceptions. Spiderweb Software is a three-man shop that produces little in the way of development-related updates beyond “we’re working on X,” “almost done X,” and “X is out, we’re moving on to Y.”
Bungie is one of my favorite examples; back when they were working on Marathon they were active on AOL and Usenet groups. During the development of Halo, Matt Soell would produce weekly developer updates filled with all manner of interesting tidbits (they continued this tradition after Halo as well, but over time their community interaction has lost the style that attracted me to it originally).
Some other developer logs I recall fondly are those from Ambrosia projects, particularly Escape Velocity: Nova and its Windows port, and the port of Aquaria.
If you follow a few of those links and browse around, you’ll get a feeling for the specific type of communication I’m talking about here: discussion about the actual day-to-day process of crafting the game, venting about bugs and nerdy programmer anecdotes included. I’m not talking about more generalized community interaction concerning non-development issues — while that’s certainly an important aspect of overall relationship between development studio and players, it’s not my area expertise and I won’t comment on it too extensively, lest I look the fool.
With that context established, let’s consider some of the more popular reasons you don’t see more, larger, development studios actively producing developer blogs.
Cost and Benefit — Is There an Audience?
Producing content for public consumption involves human effort; real bodies, in real chairs, doing real writing and editing. Furthermore, although perhaps less true for smaller studios, larger companies have a certain level of professionalism they would presumably like to maintain. Part of that maintainence is making sure anything that is written as Official Company Word employs proper grammar and punctuation, doesn’t leak important trade secrets, doesn’t slander another developer — basically, make sure things look like they were written by somebody who knows what they’re doing, instead of some programmer who fancies himself a writer but who can’t even spell “maintenance.”
That editing, fact-checking, content review, and so on all take time out of somebody’s work day, and when you look at the bottom line you have to wonder if the returns justify the cost — that’s anybody’s guess when you’re talking about actual developer log-style (that is, containing some measure of technical nitty-gritty) content. Not everybody finds technical content interesting; if I had to guess I’d think that those people are the clear minority (compare the original EV Nova log, for example, to the Windows port version — the former is by and large a running checklist of ’stuff we checked in to the repository’ while the latter has actual narrative content with a wider appeal). Of course, you can blunt the edges of the technical mumbo-jumbo to some degree, and include commentary on other, more widely-palatable issues. Once again, Soell’s Halo updates did this really well. In fact, transforming some of the technical details about that sweet database voodoo you implemented last Thursday that makes your asset pre-build stage run twice as fast into layman’s terms can be an exciting challenge for some, and artists and designers usually enjoy taking time off from real work to stage a sexy screenshot to show off some new feature that just got added to the build.
But again, you ramp up the effort you put into wrangling content for your developer updates, you ramp up cost, and draw resources away from actually making the game — the real, important goal. It can escalate to the point where your team is in a mini “E3 crunch” every few weeks. The benefits in community engagement you might get back in return for that aren’t always tangible or measurable, which makes for risk — in some cases, enough risk that company’s simply adopt a blanket “we’ll talk when we’re done, thanks,” policy and forget about it.
Management of Expectations
People become attached easily, and often to surprisingly minor things. Everybody is different, everybody finds enjoyment in different things in a game. Most of us have an armchair game designer floating around in our soggy little brains, too, which always complicates things. My point here is that it’s often very difficult to get rid of some aspect of gameplay, even a minor one, once you’ve mentioned it.
Remember Guild Halls in Diablo 2? The fourth race in Rise of Legends? The deep, adaptive, immersive AI in Black and White or Oblivion? All of these were talked about, or even hyped in some cases, pre-release but vanished with barely a trace by the time the games hit shelves. The fan backlash didn’t kill the games, but a good deal of players had chips on their shoulders for some time, and blamed the developers for what they saw as an injustice. The damage wasn’t done to the games’ sell-through numbers, but to the atmosphere of those games’ communities, and community improvement is ostensibly what the whole developer-player communication thing is about, no?
It’s a fair assumption that the majority of players are non-technical (that is, they aren’t software developers themselves). It can be difficult to convince these people that cutting a feature was justified in terms of development cost, or because it wasn’t turning out to be fun. In the former case, the players tend to lack the technical acumen to grasp a completely literal explaination of the rationale, and/or such an explaination may require more background about the development history of the related aspects of the project than the studio may be willing to reveal. In the latter case, the players will have their own versions of the cut feature in their mind, almost certainly disconnected from the reality of how the feature feels in the context of the rest of the game, and can sometimes have a hard time looking past what’s in their own heads.
Because of this, it’s common for studios to err on the side of releasing less information because it doesn’t create expectations among the fan base that may be unrealistic. There’s also some measure of surprise when the game ships with a bunch of cool features nobody knew about, which can be a plus.
Publisher Mandate
There are a lot of studios that are owned by a publisher, and most of the rest are developing games on some other publisher’s dime via contract. Those sorts of relationships generally afford the publisher a certain measure of control over the developer, control which can manifest itself as an enforced “don’t talk about Project X,” policy.
Publishers, being beasts of an altogether different nature, are generally concerned more with the business ramifications (such as the effect on stock prices) that talking about projects in development have. In the interests of controlling the release of information they may deem related to some corporate strategy (investing in new intellectual property, entering into negotions to secure a license to some existing intellectual property, diversifying platforms, et cetera) or trade secret, publishers might choose to have the developer filter all related informational releases through them first, or simply ban them outright.
I’ve never personally been in a situation where I’ve observed this happen, as far as I know (I’m generally not involved in the details of the relationship between the studio where I work and its publisher), and I’m glad. It’s an extremely heavy-handed tactic, in my opinion, and it’s unfortunate that it happens at all.
On Balance
There are opposing points to be made here — I should note that I’m primarily playing devil’s advocate with this article; while I understand where studios are coming from with the above arguments, I don’t neccessarily agree with them. Next time I’ll talk about exactly how I disagree, and what I think can be done to improve things.
