(This is the second of a three part series about the black art of doing tech support. The first part is here.)
Anyone who ever has to do tech support (or who is trying to get a broken program to function) must first internalize one key, vastly important fact:
You can take a flawlessly written program, install it on a new, factory-fresh, basically functional computer, run it, and find that it doesn't work.
When you understand why this is, tech support, giving and receiving, becomes ever so much easier.
Computers Are Mechanical Devices
Computers are so close to magic that it is easy to forget that they are machines. Incredibly, brain-breakingly complex machines, that record and recover millions of bits of information a second (in RAM or on your hard drive), etching down those details in the magnetic fields of microscopically small bits of matter. So much is done, so quickly, on such a small scale that quantum mechanics becomes relevant, that I'm amazed any computer ever manages to work at all, ever.
When data is recorded on the hard drive, errors can happen. There are guards in place (called checksums, for what it's worth) to help keep the errors under control, but there are still many, many ways that incomplete and incorrect chunks of data can be recorded. The longer you operate your computer, the more errors there will be.
Most of the time, when these errors occur, you never find out. They happen in bits of the operating system or in programs that you don't use or the error introduced is so minor you just ignore it. But sometimes the error happens in a graphics driver, or your saved game, or the bit of my RPG that determines whether your characters get experience or not, and suddenly there is a problem.
So What Does This Mean?
It means that even the best-written program will have a ton of problems out in the field that aren't the developer's fault. Problems that need to be fixed by rebooting the computer and relaunching the program (to fix any error in memory) or by reinstalling whatever part of the software (the game, the drivers, the operating system) that have become broken.
If the problem is in the game, your characters might stop doing damage, or you might lose the ability to enter new places, or the game just might start crashing like crazy. Corrupted file in the display drivers? The graphics might be drawn funny, or the screen might always be black, or the game just might start crashing like crazy. Corrupted file in the operating system? The game might stop being able to save, or the settings file (that contains the registration) might disappear, or the game just might start crashing like crazy.
I'm not just blowing smoke to distract from my own errors. These problems happen all the time.
Of course, when users report these problems, they will pretty much always assume that it is your fault and you are an idiot. I have gotten multitudes of bug reports along the lines of, "Whenever I try to start a new game, the program crashes. This is a terrible bug and you should fix it right away!" When I get these messages, what I want to respond (but don't) is, "If my game had a problem this serious, don't you think I would drop everything this instant to fix it? You think I want to sell games that are never usable by anyone? What turnip truck do you think I just rolled off of?"
That's what I don't say. What I do is send them my standard list of tech support steps, and, 99% of the time, problem solved.
My Rule For When I Start To Hunt For a Bug
It's a simple one.
I never even consider that a problem someone reports is a bug in my code until two people report the exact same problem.
Sometimes, if the report is vague enough, I wait for three people. It can be maddening to get reports of catastrophic problems and not act on them, but it's worse to waste your limited, precious time hunting for gremlins.
We Live In a World Of Frustrations
I know that, every time I release a new game, thousands of people will get the demo, run it, and it won't work because of the reasons outlined above. They delete the game, write me off as a bonehead, and never send me teh moneyz. This is hugely frustrating. Nobody wants to be thought an idiot, and everyone wants the aforementioned moneyz. It's sad, but it's part of the business of writing games for computers.
It's even worse when they then go online and write about what a bonehead you are. Recently, a site called Platform Nation reviewed our newest game, Avadon. The reviewer got stuck with a horrible glitch that teleported his character into nothingness. He proceeds to excoriate me for writing such a terribly buggy game. Please believe me when I say that nobody, and I mean nobody, besides the reviewer has ever reported this problem. Don't believe me? Our support and Avadon forums have never had a mention of it. But the reviewer still called the game "wrong or broken" and "unforgivable " and gave it 1/10.
(Interestingly, the review has disappeared from the main site, and the only remaining copy is on their forums. I can therefore neglect expressing any other opinions about the reviewer's level of professionalism.)
Of course, if this sort of horrible game-breaking behavior was a bug, I would do everything I could to fix it. But that's not how things work.
Game Development Isn't For Wimps
Many people will get a game that breaks, and most of them will simply disappear and never try your product again. But some of them, happily, will come to you for help. When they do, you should smile, take a deep breath, and do what you can to make them happy. When the problem is a weird one I've never heard of, I will first send them my magic troubleshooting checklist that solves all problems. I'll post that next week, and everything will be better for everyone forever and always.