What's an effective and somewhat easy to build system to allow customer to submit bug reports after deployment?

Question

I'll be deploying a C++/DirectX/Windows game at the end of January to my customer and I'd like to setup an easy way for them to submit bug reports. Should I setup a website for this? Should I build it into the user interface of the game? Should I just have them send me an email? At a very high level, what are some ideas for an effective, and somewhat easy to implement, system I can build to allow customers to submit bug reports that describe the bug, the conditions under which it occurred, and possibly any log files I'd like them to attach?

I should add I also use Trac to manage bugs.

Thanks in advance!

Answer 1

Setting up an account on uservoice.com is nice. Or exposing a public bugzilla server. Both offer comments and tracking and are very transparent to your customers. They also provide means of voting if you want your users to help decide what is important to fix.

I think email can be overwhelming and allows issues to slip through the cracks.

Answer 2

All three are good:

1) Crash reports: can gather info about the crash and prompt the user to enter their email address and / or a description.

2) A website for tech support such as a web form: which could submit an email.

3) Built in tech support: Simple form to send email.

For all of these it is useful to have a bug tracking system. A simple example could be a mailing list that bug reports are submit to for tech support to respond to. It is relatively straightforward to implement a simple emailing form within PHP.

Answer 3

I prefer a website bug tracking system like Mantis or Bugzilla if you want to host it yourself, or something like FogBugz if you want to outsource it.

An online bug tracking system;

• makes sure that no bugs get lost,
• allows you to prioritize the bugs
• allows you to assign bugs to a developer to fix
• allows your customers to submit and track the progress of bugs
• some even allow your customers to vote on the bugs

You do not want to build it in to your software IMHO because you should be spending time fixing bugs and developing features, not writing bug tracking software.

If you want to use email, many bug tracking systems will integrate with an email account to that bugs can be submitted by sending email to that account.

Answer 4

I would recommend something like bugtracker its open, written in C# and web based I have been using it for about a year and have made several of my own modifications to it

Answer 5

If you're about to deploy a game do yourself a favor:

Pay a professional testing team that tries to find out what combinations of graphic-cards + driver-revisions don't work. Once you have the results you can look at them and try to work around some of the more obvious bugs. You will never be able to write a non-trivial DirectX application that works with all kinds of hardware and beta-drivers simply because there are drivers and broken hardware in the wild that have bugs that can't be worked around.

I've been in the game-biz for around 10 years and I've learned it the hard way. It pays of to refuse dealing with customers who complained about graphic problems if they run a cheapo asia graphic card clone with dubious drivers.

It's best if you have a "works on "insert the most popular 10 graphic cards with latest drivers" positive list. That will cover 90% of the audience so the potential customer loss is neglible compared to the extra efford.

Heck My last game was known to don't work on a Matrox G400 or 3Dlabs Permedia card. That didn't stopped some guys from complain that the game won't work on their 10 year old obsolete hardware. Do I care about the 10 guys who try to run a game on this hardware? No, I don't, but for some reasons these are also exactly the guys who make a big thing out of the fact that the game does not work.

Answer 6

Take a look at FogBugz. It's more than the "usual" bug-tracking system in that it has nicely integrated customer-facing email and forums (with good support for attachments & screenhots), while letting you (privately) manage the cases raised. The hosted service is free for one or two users. FogCreek eat their own dogmeat too. If I was releasing a small proprietary project it'd be my first choice for a "one stop shop" for managing this sort of stuff. There is at least one Trac-Fogbugz plugin; haven't tried that myself though.

Answer 7

+1 for fogbugz, if you are looking to buy a bug tracker anyway. (You don't have one? You should!)

An in-game component IMO is useful only if you automatically gather additional information - such as file version, installation paths, crash reports, log files etc. It is a lot of work, has to deal with the "no internet connection" scenario, and rolling out an update will not reach everyone even if you have the infrastructure for an automatic update.

A web site with a simple way to submit feedback - email link or contact form - is the easiest to set up, cheapest and quickest to update. Make sure your spam filters are up to date! Linking the web site e.g. from the start menu will get users started.

The next step could be a forum specifically for bug reports and similar feedback. I know some companies with hundreds and thousands of feedback-active users, doing this very successfully for a long time.

A freely accessible forum might also become a building ground for a community. Building a community and running a forum is a lot of work, and not easy.

A public bug tracker might look more profesisonal, but may be over the top. If you are planning a large-scale beta test (> ca. 100 users), and updates/new versions over years, then maybe it adds value.

I find bugzilla not very end user friendly (at least not out of the box, I am sure you can customize it if you want to bother). Also, as mentioned, Fogbugz allows public submissions and has a built-in spam filter for these. However, AFAIK it does not allow the submitter to track the state of his bug (I don't know for sure, we are using FB, but not the public submissions).

---

So as plan of action I'd recommend:

Start with a link to a web site and a simple feedback form or e-mail.

When you start to get many duplicates, you can post there a simple list of bugs you are working on. if this isn't enough anymore, set up a forum or a public bug tracker interface - whatever is less work for you in the long run.

When you find that bugs are hard to reproduce and you always have to gather more information from the client, first see if generic tools (like msinfo32) are enough. If not, roll your own reporting component.