Making Mods/Supporting Your Mod

Supporting Your Mod

Once all of the euphoria of finally finishing something and getting it released has died away, the long dark teatime of the soul begins. In the months and years that follow the release of your mod to the general public the sounds of the popping corks will be scant comfort as you scream for the nth time, "Didn’t they read the README? Haven’t they checked the FAQ?".

Work doesn’t always stop when the mod is released

Once you have released your mod you might think that you could move onto something else, but that’s not always the case. If the mod is a very simple mutator then you might get lucky. However, for a mod of any complexity you will almost receive a fair few e-mails requesting help, new features, and bug reports.

For a complex mod it’s not difficult to spend more time supporting it than you did writing it. You may have only spent 6 months writing the mod, but the game the mod is for may last for many years. IF you skimped on the bug fixing and testing then this is the point at which it bites.

Create an FAQ

One of the best things you can do in reducing the number of support e-mails (or at least speeding up the processing of them) is by maintaining an FAQ. Whenever you get a question not on the FAQ add the question along with a detailed answer. Make sure the FAQ is referenced in the read me, and the release notes. Publish the FAQ on the Internet on you "mod site" if you have one. Keep a copy of the FAQ on your desktop so you can simply drag and drop it into an e-mail as you answer the same question for the 15th time.

Always place a version number or last updated date on the FAQ.

Future versions

One of the things you will need to be clear about is whether or not there is on-going development for the mod. You can avoid a lot of future feature requests simply by making it clear that there will never be another version of the mod. However, if you do intend to continue to extend the mod then add some sections to the bottom of the FAQ. These sections should that list all of the features that have been requested so far in the following categories – rejected, scheduled, and under consideration. This should reduce the number of duplicate requests, but probably won’t.

Releasing bug fixes

Any subsequent release of your mod should be handled with care. The release should received as much, if not more, testing that the initial release did – you don’t want to release something that is as broken (or worse) than the current live version.

Never rush out a bug fix release unless there is a huge gaping critical error in your mod (presumably caused because you made a last minute code change before doing the final build). No matter how much people shout for a new release wait until there is a sensible amount of fixes in the code before doing the release.

Unless you change the name of your mod package, having many versions floating around the Internet will increase the chance of "package mismatch" errors occurring.

Always be polite

The customer is always right, even when they’ve ignored the README and FAQ, and are utterly stupid as well.

Even if you do feel like flaming them into small charcoal crisps, stamping on the pieces, and then sending the few remaining crumbs into the centre of a volcano don't do it. Instead, take a deep breath, and reply with the FAQ (updated if necessary). It will save your blood pressure, and make your mod look well supported. This in turn should improve the reputation of your mod which means more people will download and play it.