Computer software, and by extension, video games, are getting more complicated every day. It used to be that a game might be a few hundred thousand or maybe a million lines of code. Now, some of the third-party libraries we use in our games are approaching that size, if not already larger! Keeping that in mind, it’s quite impressive that modern games still run for the majority of users. But here’s a simple fact: Sooner or later, someone is going to be unable to play your game. What you do then determines whether or not they will remain your customer.
A few years back I was doing design work on an MMORPG. Really satisfying work – come up with characters & stories, try to construct gameplay around them, and then watch the rest of the team turn it into a living, breathing part of your game world that your players are going to interact with for months afterward.
So, at one point we decided to run a weekend promotion to promote our upcoming title. We temporarily enabled access to the content from our next game, and allowed people who didn’t own the game to create characters and play for the duration of the weekend. Great idea – get people in there at no cost, try and convince them your game is fun and worth playing. Works good for existing customers, too, because now they get excited about what’s coming down the pipe because you’ve let them play it for a couple days.
I was pretty excited about it, since it was the first promotion of its kind that we’d run since I had started working there – which meant I could finally show some of my friends what I was working on, and try and convince them it was worth playing. Most of them hadn’t even looked at the game since they had to pay for it first – and who can blame them, really?
Friday rolls around and I head home late and get some rest. The rest of the team does the same.
On Saturday morning, I send a message to a couple of my friends explaining how to download our client and try out the game. They’re both pretty enthusiastic about it and get started. A few minutes later, one of them says:
‘Why can’t I use any skills?’
What? What do you mean you can’t use any skills? Are there buttons on the bar at the bottom of the screen?
‘Yeah, but they have little lock icons over them. Nothing happens when I press them.’
Well, uh, s–t. That’s not supposed to happen. I emailed one of my coworkers to ask – uh, did anyone try creating a brand new account for the promotion to see if it worked? – and the answer is depressing: Nope. Luckily, it wasn’t a total loss – our existing customers were still able to participate in the event, because they already had working accounts. But for new, potential customers – the game didn’t work. They downloaded and installed our game, and it was mostly useless to them.
When you ship a title, you need to be prepared for it to break. What’s more, you need to know as soon as it breaks, and be prepared to take action to deal with the problem. Some issues simply can’t be solved, whether they’re caused by hardware problems or software glitches, and sometimes a bug that just affects one or two customers is not worth fixing. Regardless, though, you need to take action to keep your customers happy, whether that action is a patch, a refund, or a workaround. If you do nothing, your customers won’t be your customers much longer.
The worst possible scenario is that your game breaks and you don’t know about it. A modern game company can be quite hard to communicate with sometimes – when a person’s only choices for getting support are outsourced email support in India or ‘support forums’ full of angry trolls, they might just give up instead of trying to get help. Even worse, if they bought the game with a credit card, they might just issue a chargeback instead of trying to get the game fixed – which costs you more than it would have to issue a refund – all because they either couldn’t, or simply didn’t, get in touch with you about their issues.
As a developer, you want to do everything within your power to make sure that a customer with a broken game remains a customer. Here are some important steps you can take:
Provide a visible, straightforward channel for user feedback and support. An email address printed in the front of the manual, placed at the bottom of error dialogs, or on the front page of your website are a good start.
You can get extravagant by using things like forums, twitter, blogs, etc. to communicate with your customers – some of them will probably appreciate it – but it is tremendously important that whatever tool you provide for customer feedback be as simple and straightforward as possible, and that it be easy to find. Many game companies have switched to hugely complicated ‘automated support systems’ that require logins, registration, password management, support tickets, etc. While these systems make sense from the perspective of a studio, most gamers simply won’t bother and will issue a chargeback instead of trying to figure out why your automated support system’s registration page is sending them an HTTP 500. If you want to manage support tickets using an automated system, go for it, but you absoutely need to accept customer feedback via email or some equally accessible method.
Also, when considering the use of twitter, forums, or blogs, keep in mind that visible complaints and negative feedback cost you more than invisible ones. You should strive to encourage your customers to contact you privately before taking their issue public for the world to see. Ideally, you can resolve it in private before anyone else ever sees it, which limits the negative impact the issue has on your image as a developer.
Prompt responses to feedback are also important. Nobody expects you to solve a bug in 2 hours, but you should strive to send your customer an initial response to their feedback as quickly as possible, even if the response is ‘We’re taking a look at your issue, please be patient – here’s a link to the ticket in our support system’.
Provide news to your customers about ongoing issues with your game in an obvious and accessible location (your website’s homepage or the homepage for your title are good choices).
Running a website is, contrary to popular opinion, quite difficult. As a result, some developers tend to … forget to update their website, or simply don’t offer support information for customers in a visible place, relying on blogs, forums, or news sites to serve as their method for communicating with customers.
This is inadequate. It sucks, but you need to be putting regular updates out there for your customers in the first place they’re probably going to look – your website. If possible, you should put that news in the launcher for your game, if it has one. When you’re showing your customers an error message because the game failed to start, you should make sure to point them at your website, too, just to be sure that they get any information you have for them.
It costs you time and money to communicate with your customers, but it’s time well spent and money that will pay for itself by keeping those customers from leaving.
Design your game so that when it breaks, it breaks gracefully. Present clear, informative error messages that customers can pop into Google and send you via email.
So, let’s be honest. Software in general does not break gracefully. People are used to cryptic error messages by now. Regardless, you should strive to do better.
Every failure should present an error message that:
- Tells your customers what to do to resolve the problem (even if it is ‘contact customer support at support@mycompany.com’)
- Clearly identifies the failure. Providing an error number or error code is good, so is providing the location where the error occurred. However, if possible you should avoid presenting gigantic stack traces or error dumps to the customer – they’re overwhelming, not helpful. Get them back to you, the developer, some other way.
- Lists any user-actionable problems that contributed to the failure – ‘your microphone isn’t plugged in’ is actionable, while ‘your Direct3D driver returned D3DERR_INVALIDCALL’ is not.
Do whatever you can to find out about failures.
When your game fails, if possible, it should ‘phone home’ to notify you. At the very least, it should report the version number of your game, the error that occurred, and a stacktrace of where it occurred.
Sometimes it’s not possible to phone home – no internet connection, for example – and in that case, it’s okay to give up. If you’re concerned that failures happen a lot in this environment, consider storing the most recent failure message in your game’s AppData directory and reporting it the next time your game is launched with an internet connection. Better than nothing, right?
In many cases you may find it useful to report detailed information on the user’s system configuration, and the circumstances under which the failure occurred – remaining memory and disk space available, etc. This is a good idea, but if you do it, you must be absolutely certain that you do not report a single shred of your customer’s personal/private information along with the crash report. If you do, they will be completely justified in kicking up an annoying s–tstorm about it on the internet.
Some customers will complain about your game phoning home no matter what you do. As long as you only phone home when your game fails, you can safely ignore them. You’re doing your best to make sure the game works for everybody, and you’re not compromising their privacy. If they’re worried, they can unplug the ethernet cable.
Note that if your game requires internet access to work anyway, you should probably also consider reporting a successful start and exit of your game as well. This will help you track down situations where your automated crash reporting also fails to work correctly (these are more common than you might think).
Don’t compromise your game’s reliability for business reasons.
Now, to begin with – I’m not a fan of DRM, but I’m not going to try and convince you to abandon it here. If you’re already using DRM, you probably have a reason for doing so.
However, there is no excuse for allowing DRM – or any other addition to a game title – to compromise the reliability of your game. Any addition - DRM, an automatic updater, a ‘compatibility check’, etc – should never prevent customers who purchased your title from playing it.
Nobody’s perfect, of course – sometimes your game is going to break despite your best efforts, and it will be due to some secondary part of the game, like DRM. In these situations, the previous rules apply: Provide clear, informative error messages, and communicate with your customers.
When a game breaks because of a business decision, customers tend to be less willing to forgive. They just want to play your game; they don’t care about your revenue. Sorry. Therefore, while a good business decision is still a good business decision, you should always strive to make sure that you don’t make your game more likely to break.
If the addition of DRM reduces piracy by 2% but causes the game to break for 4% of your legitimate customers, you just kneecapped the effectiveness of that DRM package, which doesn’t benefit anyone.
