Checking In: An Open Discussion about Developer Transparency
Dee
Member Posts: 10,447
This post isn't going to show you any great spoilers about what's in the next patch or the next game or the next five games (and that number is totally arbitrary, it doesn't mean we're planning to make a Baldur's Gate VII: Advent [Bhaal]Children). Those of you who have been following Trent's twitter feed have seen snippets of what's going on--multiplayer matching being tested, Android not going as smoothly as we hoped, the art assets being lost (though that one's from over a year ago)--and hopefully that alone should tell you that we want to tell you more, even if we don't have the time to post proper newsletters or announcements on the forum.
Unfortunately, we don't have as much time for newsletters or announcements as we'd like. Posts you see from the developers (that's anybody with a blue background in their posts) are made in the thirty seconds of downtime between code projects. Fixing bugs, implementing features, scripting content, all of that is what we're focusing on right now. And that's great news, because it means that when a patch or a new game is released you know that the developers have put in the time and care to make sure it's worthwhile. The next patch is going to be enormous, and we're doing everything we can to make sure that it's done right.
So what is this post for? Well, we've been noticing a number of people asking for greater transparency, and that's something we'd like to explore. The trick is knowing where to draw the line; what information to release, how to release it, what hints or rumors will spiral out of control, and when is that a good thing. So I put it to you, fellow gamers: How should a developer keep the community informed about a project's status, without making unreasonable promises and without levering expectations to the point where they can't be managed safely?
I'm not going to promise that any suggestion or suggestions made in this thread will be used as-posted, but I think it will be an interesting discussion. I imagine there will be a lot of disagreement about not only what information to release, but also how to release it and where. And that's all good feedback. What I'm looking for is ideas, and a discussion of those ideas. I'll be facilitating the best I can, as time allows.
Some talking points to get us started, and to keep in mind as we go forward:
#1: When does a developer reveal too much about a project (be it a bug, a feature, or an entire game)? How can developers avoid saturating the community with information while still keeping people informed?
#2: What is the best way to disburse information about a project (be it a bug, a feature, or an entire game)? What are some possible pitfalls of doing it that way, and how might those pitfalls be avoided?
I think that will be enough to get things started. Tell me what you think!
Unfortunately, we don't have as much time for newsletters or announcements as we'd like. Posts you see from the developers (that's anybody with a blue background in their posts) are made in the thirty seconds of downtime between code projects. Fixing bugs, implementing features, scripting content, all of that is what we're focusing on right now. And that's great news, because it means that when a patch or a new game is released you know that the developers have put in the time and care to make sure it's worthwhile. The next patch is going to be enormous, and we're doing everything we can to make sure that it's done right.
So what is this post for? Well, we've been noticing a number of people asking for greater transparency, and that's something we'd like to explore. The trick is knowing where to draw the line; what information to release, how to release it, what hints or rumors will spiral out of control, and when is that a good thing. So I put it to you, fellow gamers: How should a developer keep the community informed about a project's status, without making unreasonable promises and without levering expectations to the point where they can't be managed safely?
I'm not going to promise that any suggestion or suggestions made in this thread will be used as-posted, but I think it will be an interesting discussion. I imagine there will be a lot of disagreement about not only what information to release, but also how to release it and where. And that's all good feedback. What I'm looking for is ideas, and a discussion of those ideas. I'll be facilitating the best I can, as time allows.
Some talking points to get us started, and to keep in mind as we go forward:
#1: When does a developer reveal too much about a project (be it a bug, a feature, or an entire game)? How can developers avoid saturating the community with information while still keeping people informed?
#2: What is the best way to disburse information about a project (be it a bug, a feature, or an entire game)? What are some possible pitfalls of doing it that way, and how might those pitfalls be avoided?
I think that will be enough to get things started. Tell me what you think!
Post edited by Dee on
34
Comments
1. Honestly I think that what you guy have done so far is fine. The only thing I really care about is that bugs are being worked on so there is no need to send in anymore posts.
2. Distribute things on the forums instead of Twitter. Not everyone has a Twitter account after all. Logging on for this website is very easy and much less restrictive than Facebook or Twitter where you have to give you Email address and confirmation and be wary of privacy settings. A lot of people are used to getting tweets on how the team is doing on Twitter though.
Basically it would be nice to know that you still support the product and show that it hasn't been abandoned. Its really easy for companies to forget about their old games when they have other things to worry about and I hope you guys and girls don't do that.
In my world, we usually have to make estimates of deliverables with incomplete information, its the nature of the business. You can never know for sure what obtacles might be faced in a change. You base future performance on past performance, but the accuracy is never perfect.
Making that clear to your business owners, creating a process for communicating risks and changes, these help make it possible to provide an early estimate, miss it, and not lose your job.
I really think that open and honest communication can work. I know we customers aren't really business owners, but you seem to have interest in keeping the lines of communication open. Id like to think that what works for business owners can also work for customers.
If you let us know what you know -- what you are planning, when you are planning it for, and what the risks you face in getting there are, and also keep letting us know when you hit an unexpected problem, I feel like we can handle that. That lets us have, when push comes to shove, meaningful dicussussions about how important a problematic feature really is, but should alleviate blame for missing a promised date. We won't see them as promised dates, as we will be along for the ride, understanding why it is what it is.
Outside of spoilers, which could be reasonably warned about, I don't think there is such a thing as too much information, at least from the customer's perspective. I think its the over-management of information that can create the perception of a problem.
I encourage you to have the fans in mind.
Although I also respect that you are a business which needs to profit from your endeavors.
To address your open questions:
1) Beamdog is very far from reaching this boundary condition, and I don't think it's an issue to worry about presently. Being concerned about over saturating us with info is akin to a struggling small company worried about too much business. That may sound harsh, but judging from past history it just isn't an issue.
2) This is a multi-part answer.
In general, an icon next to a thread to indicate "developer posts". If we click on that icon, we are taken directly to the first dev post in that thread. Additionally, a link to "recent developer posts" in the left-hand list in the *New Discussions* section which shows us chronologically the THREADS that have developer comments, on which if we click takes us to the FIRST developer comment in that thread.
Pro: we can easily see where the conversations involving the team are occurring (transparency) and easily find them and arrive at the developer posts (ease of access to information).
Con: takes time to properly configure the board software.
Regarding bugs: Currently, there is a bug tracker. I am not a beta tester, and as such do not know what is reported and what isn't unless some kind soul pops up to tell me "Already reported!" or I get a dev/mod post saying "Thanks, will make note..". Personally, I feel like quickly identifying issues with patches and what not would go a lot faster with an opt-in beta program (similar to beta servers in MMOs) or making the tracker public, but I don't think that's realistic at this point. So, to address people's frustration about bugs and their status, I propose the following.
After a new patch is released, a new pinned thread is made in the bugs (or system specific support) forum. This thread should contain and index of CONFIRMED bugs, with a link to the original post that contains the bug description and developer response. If a community hotfix is available, another link directly under the bug's index that provides access to it with the normal *use at own risk* boilerplate. It's important a new thread is created per-patch (and the old one un-pinned and allowed to settle), and serves multiple functions by allowing the community to quickly see what bugs are reported and, crucially, recognized. Invariably, some bug reports share common ground with feature requests and judgement will have to exercised in the curating of such a list.
Pros: We know what you know, centralized location for hotfixes, reduced redundancy in the bugs / support forums and the community feeling more like you *care*.
Cons: up-front time to establish this, but something like this has benefits that percolate due to centralized access of fixes and reduced double-triple-whatever posting of bugs. If handled by bugs/support mods on a per-issue basis, from the start of a patch cycle, time investment is spread out.
Finally a monthly-ish update from the team (call it a newsletter). Give us a taste of something, toss us a bone, link to the bugs/hotfixes thread and maybe call out some particularly tasty thread wherein a dev shares something.
These kind of community building things are like long term investing. In the short term, the payout isn't always obvious, but longer term it can make a huge difference. *Reputation matters*. The hard part is being consistent and developing an engagement strategy that makes sense and accomplishes something.
I hope this helps.
I actually have been happy with the bits and pieces released about the games so far. The only concern I have is whether to start playing regular BG2/ToB with my characters from BG:EE/Black Pits now...or hold out until BG2:EE comes out, especially with after hearing about all those millions of new text added. Gah! The stress of indecision!
I believe that if you can adress the community as a whole, by mainly using the forums it would be a better solution than using things like Twitter, Facebook, etc. Not only is it a lot harder for us to check what's been said earlier on, but i would hazard to guess that most of us aren't even on twitter.
Don't have to exclude said tools, but if you can post it on twitter you might as well post it on the forum.
(This is where your paying customers are and is the natural go-to for future customers!)
As for what you can and can not say, just keep it simple and honest.
Trent could have his own Dev tracker thread where only he (or his lvl 900 Henchmen) could post. Lock it so that only Devs can post in it. This keeps it free of clutter and gives us a very easy and manageable way to keep chronologic track of you guys.
In this thread you could post things that are confirmed for next patch, and things you -hope- to be able to add. For example:
"Good afternoon adventurers of the sword coast!
We have some news for you and this is what we're working on.
For next Patch (ETA July) we have the following confirmed.
3 New Kits (Gray Guard, Red Dragon Disciple and Troubadur)
4 New Quests added to Friendly Arm Inn.
2 New Party-joinable NPC's with their own storyline.
Fixed numerous bugs
Bla bla bla
We also have some stuff we are currently working on, but can not at this point confirm wether or not they will make it into the patch or the game at all.
Full on cross-platform multiplayer support.
Sarevok drops pink pair of pantaloons (We all know he's a bit fruity under that hard shell)
And some other stuff we want to keep secret!"
That's one way to go about it.. doesn't even have to be that detailed, but if you have stuff that is confirmed for next patch you might as well let us know. I don't think anyone will have a stroke if you let us in on the confirmed bits.. just make sure to properly mark the stuff that is unconfirmed but hope to add.
When I was in a guild in World of Warcraft about two years ago, the guild leader would post a monthly newsletter on our forum on what future events were going to happen soon and where he hopes the guild goes in the long-term. It was very informative and quelled a lot of the rumors that guildmates would create. I bring this up because it didn't give any spoilers or exact details on what he has done or wants to do, just a general run of the mill standing on where we are on the inside of the guild for those that don't have time to ask 30 people to get an accurate answer. Or unsure of what was lying ahead for the guild.
The bug bounties that have been stickied is a wonderful idea too. It engages customers to help shape their purchase into what they've always wanted. It helps devs work on content instead of bugs AND the customers get a prize for achieving said task. It's a win-win situation and more ideas similar to this is an A+ in any business.
I know I'm in the minority here, but I don't have a Twitter or Facebook account. So if it's not announced on the forums by a dev/moderator or linked by a member then I don't know of it's existence. I understand that Twitter and Facebook reaches a much broader audience faster and easier, but copying and pasting it onto the newsletter idea doesn't take very long and reaches those that don't know of developers by name. New people to Baldur's Gate:EE will just Google it and find this site. Not a developers Twitter account (Not sure on that last part with Google, will have to test it first).
Lastly, you guys already do a fantastic job with this project and I hope with future ones as well. I'm very pleased to hear that you guys are wanting to be more open with your customers without being too revealing. We don't have to know ETA's, features, or bugs. Just knowing you exist and are paying attention to us is all I'm asking for. Thanks for letting me give my input and good luck.
1) I think a developer reveals too much when there is lots and lots of information available about the game and it hasn't been released yet, at all costs do not talk about things you haven't implemented/started because how would you know its definitely going to be done?. I tend to take this as a bad sign, the best delivery of information is what Bethesda did for Skyrim. Show very little information but when it is shown make sure it really captures what the game will contain. sometimes its good to leave a little mystery.
2) Forums should come first not twitter but that does not mean twitter shouldn't be used. I think I would set day whether it be every 2 weeks or a month when information should be released and talked about, so you know their is one day at the end of the month to log down what everyone has done for the game. Make it a habit and hey presto.
Use it as way to refresh and think about what is being done. If there is a meeting to discuss something have someone bring a laptop and write some stuff down in a draft for the Forum.
I don't know if this applies to the gaming industry, but If there are any deadlines I need to create, I think of a reasonable deadline then add a month or week depending on the task, that week/month is my margin of error, if I finish early customers/clients are impressed (that usually happens) however if my reasonable deadline fails, I have a week/month to finish outliers without upsetting people by extending deadline. < This has been very valuable to me.
Because of that, a bit more transparency relating to ongoing technical work would be a good thing - we know which bugs have been reported, but not which bugs are being actively worked on for the next patch. Is the Shadowdancer class being retooled for v2015, or has that been delayed in favor of more critical bugs? What about Tethtoril's quest? Are there any other bugs, minor or major, that might be worth mentioning? (You may face criticism for prioritizing one bug over another, but let's be realistic here: this game has been patched a grand total of eight times since November, after a delayed launch. Some criticism is due, that's just part of the business.)
Now, content is another matter entirely. Baeloth's introduction into the campaign was a perfect example of how to do it properly: he wasn't listed in the patch logs, but devs started dropping hints that there was something new east of the Friendly Arm Inn, and if you were level 5 you might want to go looking for a certain tower. That was enough information to get people interested. By contrast, this "Adventure Y" nonsense has been zigzagging between "removed due to time constraints", "we may be working on it", "it's going to happen eventually" and "what's Adventure Y?" I don't think a formal announcement is necessary unless you actually have something to show, but again, this is a very old and very familiar game: the community can probably handle a bit more information than that.
Expectations are a double edged sword; It will hurt you when you can't meet them and disappoint your customer, on the other hand if you meet them you're golden.
1) You need a clear way to communicate with your customers. You currently use twitter(trent) and the forums. Twitter is nice for letting people know what is going on in the now, it sucks for archival purposes. When you make an announcement do so on the forums, and place a link in a tweet to the announcement. Also place a link on the website.
2) Be up front and honest; an announcement by the developers telling us about the difficulties they face, because they are working on a very old piece of software, that has many faults to begin with would have helped a lot.
You can't know beforehand what you will come across while implementing something new, because you don't know what every line of code does.
I had a situation once where i had to migrate an old database with over 3000 publications, images, files, etc to a new system. I thought i could do this in a week and told the customer this. It was a very poorly designed database and it really came back to bite me in the ass.
In this case i sat down with the customer, showed him the problems i ran into, and that i had simply burned through the hours. It worked, but unfortunately more stuff needed to be migrated. It really helped that i was up front and honest with him, because he went to his management and got more funds.
It still sucks, though. You have to disappoint someone. It's like ripping of a band-aid, only it's ducttape ...
3) Be more clear on promises and limit scope. The first website i made for a customer i had said it would work in internet exploder. Everything was fine until the customer started testing with Internet exploder 6 ... Bring the pain.
The lesson here was that i should have been more clear that it would work in IE7 and up.
The lesson for beamdog should be we are working on an ipad version. We are currently only supporting ipad 2 and up. A lot of people were disappointed that on release day, it didn't work on ipad 1.
I believe it was quite late in the development cycle that you learned ipad 1 would be problematic. Be up front and honest about it and tell people sooner. Even now i would have added a disclaimer to the game in the store saying that, while the game will work on the ipad 1, the experience will not be optimal.
1. Announcements of announcements may be much derided but they are actually pretty useful.
If you announce that on 18th of may you will release a development post with information on the next patch for example, then the community gets the benefits of knowing that something is happening behind the scenes, as well as a deadline for how long they have to wait. But it doesn't tie down the developers too much. So for example, if you had originally planned to announce release improved multiplayer functionality on this date, but instead found it needed a bit more work, then you aren't in the difficult situation of having already announced it to the community, and can instead use the announcement to list the changes that *will* be making it into the next patch
2. Teasers are actually fine, despite what the forums might say. The whole adventure Y thing, or the special bonus for preorders raised a lot of discussion, excitement and speculation. As soon as something makes the official announced feature list, it is fairly locked in, but just have one of the team member hint at something on twitter is hardly a promise.
3. Having a set date where the game is regularly patched, or at least announced to be patched is a good idea I think. If this date is likely to be missed (which I'm sure will happen from time to time) then you have the opportunity of postponing the patch, but if so, then give a second date where the postponed patch will now be released.
4. If there are bugs which you know are going to be tackled and fixed as a matter of urgency in the next patch, then it's a good idea to announce that you are working on those particular issues at the same time you announce the date for the next patch.
For example, it would be a good idea to point out that you are working on a fix to the quest for firebeads scroll in candlekeep. Sure, on of the development team might go into the thread complaining about this and say "we are aware of this problem" but it's better if this sort of information is stored in one centralised location.
It would have been better to release all the information on Dorn one week. Then say check back next week for more.
Next week, release information on Neera, etc
Same for major patches. When the new kits were release, you could have released information about one kit each week leading up to the patch in order to maintain excitement.
keep it short, keep us informed. thanks.
On the other hand, I abhor WID (believe me, I grew up on the 3DRealms forums where that term was used...frequently). I would love some semblance of a schedule with the large, bold caveat that dates are subject to change. Constantly refining that date is difficult, but, to use the analogy from another post, I'd rather go to the beach to find the weatherman was wrong than have no forecast at all.
The one thing I'd stress above all else is that the devs are probably a lot more active on the forums than many realize. For every thread I post in, I read at least ten.
I don't know how much people in the forum use twitter, I don't, so how many others don't know the info you release through it?
For new content you can keep the info restricted, I like surprises
The downside to that is that when you close a thread on this forum it shows "Closed" underneath it, which might give the impression that we don't invite discussion, which we do. [EDIT: I see that @Southpaw already suggested this a few posts up. I'd be interested to hear what people think of the idea.]
This discussion is going great, folks; keep the ideas flowing!
At the same time you don't have to answer anymore to the question "ETA for the next patch", before wednesday will be "maybe this week", after will be "maybe next week"
That aside I think you guys started your communication/marketing on these games really, really well. That original BGEE announcement made me find I out I had way more BG fan friends than I ever knew. People I had no idea were interested in these games were excited about it, and actually I originally found about BGEE through them. And the announcement seemed to be noticed all over the major internet gaming communities as well. However by the time BGEE was actually released most of them had completely forgotten about it. You basically had that original announcement and after that almost nothing, or that's how it felt at least.
It has been even worse with BG2EE, I bet that the vast majority of the people who might be interested in it don't even know it's being made.
http://www.kickstarter.com/projects/599092525/the-order-of-the-stick-reprint-drive/posts
Here's the description by Rich Burlew on how it works:
http://www.kickstarter.com/projects/599092525/the-order-of-the-stick-reprint-drive/posts/180096
If I could, I'd like to direct some of the energy to identifying what sorts of information people think would be important to include in these hypothetical updates. One of the pitfalls I see here is that when you're fixing bugs, there's not always a whole lot of "juicy" information about what you're working on as a team, which for consumers doesn't make for a very interesting read.
You could just put an infodump of the week's progress, but my feeling is that if something is going to be released in an official capacity it ought to at least be worth reading. What are people's thoughts on that? Do you just want to see a progress bar or list of bugs that are being addressed, or would you rather see something like a blog talking about more general ideas? Or something else entirely? A flash game where you do nothing but walk to the right?
This is a great time to talk to us and each other about what it is you like to see when you see a post from a developer. This doesn't have to be limited to Overhaul's current projects, either; I'd like to expand the discussion to what you'd like to see from developers in general. What works, what doesn't, when does it start to feel disingenuous, etc.
Bugs fixed, not necessarily bugs that never hit an open build, but it would be nice when a bug reported in the forums is fixed to report it. It shows the devs are listening.
New features being worked on
Anything else interesting that may be going on in the background... really many people in the forum want to know where the Hyperchicken came from
A simple progress bar / percent number doesn't "say" enough and could be diffcult to manage if today say 80% done (out of 5 bugs) and the day after 40% done (out fo 10 bugs found in the meantime)..