The flow of information between developers and players — and in general the entire interaction between those two groups — is an aspect of the game development process that tends to be an afterthought. In some cases, the concept is entirely ignored. In my last post I hilighted three reasons why this may be the case, along with some justifications. At the end of the post I admitted to playing devil’s advocate and that I didn’t really agree with the majority of those justifications, in general. Today’s post expands upon what exactly I find troublesome about those three points.
Cost and Benefit — Is There an Audience?
The gist of this point was that given that the majority of players are not versed in the specific technical domains that are involved in the process of developing a game, the size of the audience for “techy” updates is potentially rather small. Perhaps the audience is so small, in fact, that it’s not worth the productivity hit required to get the information out of the programmer’s brain and in to a tangible, presentable form.
The thing is, technical information does not have to be presented in its natural state. I’m not talking about posting your Perforce check-in logs on a website, here. I’m talking about communicating the progress of the technical aspect of the game, in consumer-friendly form. This isn’t impossible — it’s not neccessarily easy, though. It involves employing communications skills that are not neccessarily all that common among programmers. In particular, it calls for the ability to distill a technical factoid or event into bite-size chunks that can be digested by somebody with much less technical know-how. Usually this requires a fair command of metaphor and other literary or educational devices — which makes sense, because teaching is essentially what’s going on here. You will likely observe that team members who have had experience (successfully) teaching classes, speaking at conferences, and so on will likely be better people to solicit for input to a devblog.
The fact that what you’re essentially doing here is teaching your players a little about the technical magic behind the curtains is important. This is a good thing. The player base, as a whole, tends to get their impression of the inner workings of game development from the gaming media. But let us not kid ourselves here — the gaming press really doesn’t have a clue what’s going on, either. Is it really better for us to be letting them set the stage for what our industry is like? I think not.
Talking to the players about appropriately distilled technical progress helps improve their overall understanding of the industry. If you do it right, and maintain a spin on the presentation that focuses on the cool things the tech may enable players to see when the game ships, you can cultivate a much more trusting and pleasant relationship with your eventual playerbase — and you get a bit of a marketing push out of it, as well. Despite the fact that you’re releasing information to a wide audience, players will still get a kick out of the fact that you’re sharing “insider secrets” with them. However, this brings us to another issue.
Management of Expectations
If you recall, I described expectation management as the desire to limit discussion about things that might be in the game because of the possibility that those things might be cut and that players would thusly feel ‘cheated’ of features. Of the three excuses I discussed last time, I think that this one is the most prevalent in the real world. I only mention it second because I think that a significant root cause is the aforementioned lack of real understanding on the part of the players.
Features get cut for lots of reasons, but almost all of those reasons boil down to a cost/benefit ratio that is not in the developer’s favor, or because they sounded cool on paper but when implemented turned out bland or tedious. This is generally a good thing for the overall health of the product — but it isn’t always seen that way by the players. Doing more to educate and inform players about the state of the game as it develops would help alleviate the misconceptions that they commonly have about whether a feature was cut for compelling technical or fun-factor reasons.
I think the advantages weigh in more heavily here: talking about some aspects of gameplay can stimulate discussion among the fans and make them feel more like they’re a part of the process, even if things only end up turning out the way they want through pure coincidence.
I think that it can be harmful to keep information privatized. Certainly some information should be, but that sort of stuff tends to be the exception rather than the rule, I think. Tranparency and openness on a topic is an investment of the time and brainpower you devote to that topic, in this modern age. We’ve taken steps in the right direction with GDC and other trade shows (and to some degree, with the abolition of the farce that was the old E3), but we can do better.
If players become better educated about what making games is really about, maybe they won’t feel quite as put-out when the game shapes up to be different upon release from what it was during the early days. What’s the worst that could really happen anyway? We’d be in the same position we are now, which isn’t exactly a huge risk to be taking.
Publisher Mandate
Publishers are generally the controlling entity in the development process: they supply the money to the developer, persuant to the developer meeting certain milestones and following certain rules. So it’s entirely concievable that a publisher might want to curtail any unnecessary discussion of any ongoing projects.
On this point, I’m not sure what to say — “find a better publisher,” isn’t exactly a real-world option. Fortunately, I’m not entirely convinced this is an excuse that one hears all that often — I’ve heard far more stories about publishers signing off on the release of blatantly poor-quality information (screenshots with clear animation or art asset bugs, for example) than I have stories about publishers issuing gag orders on contractually obligated studios.
The End
In the end, it’s obviously going to be impossible to make everybody happy, and no matter how much, or how well, you communicate with your players there will always be those players who disagree with your choices no matter how rational or necessary those choices were from your perspective. To the player, if it sounded cool and you didn’t do it, that’s usually bad.
But being more outgoing and chatty has advantages for both parties involved; our historical tendency to keep our lips sealed has not been to our advantage. I’m glad to see a trend towards honest rapport between developers and players emerging, and I hope it continues.