Releasing A Mod

After Making Mods, comes releasing your work to the public. But are you sure you're ready? Too many projects suffer because the final product is lacking fairly basic touches. Here's what experienced mod-makers from the Unreal Wiki think you should watch for, in particular Mychaeel and RegularX...

Pre-release

Chances are you've told people what you're working on. It's hard to keep it under wraps, and besides, part of a good publicity campaign is getting people's interest in anticipation of the product. But what should you tell them?

good screenshots.
Give only enough information to describe roughly what the mod does, then fill in anything else as required by the questions asked.
It can be fun to only hint at some features, encouraging people to keep checking back for more info, and then eventually to download the mod to see what the hell you were talking about.

Project States

These terms are often misused or misunderstood – due largely to the fact that even professional developers have differing definitions of them sometimes.

Alpha: Non-feature complete, for internal testing only. The term "Alpha" is usually applied to the first build (and subsequent builds prior to Beta) that has the game's core functionality working – if not perfectly, at least recognizably.
Beta: Feature complete. The transition from Alpha to Beta is reached when the project is developed to the point where it closely resembles the upcoming Gold version. Developers often use the terms "Private" and "Public" Beta to describe the state of the project. Private Betas remain in-house, while Public Betas are often made available to select members of a community to assist in bug-hunting and game balancing feedback. In (increasing common) circumstances, projects are put up for general download in a Public Beta state – these are often referred to (incorrectly) as Demos.
Gold: The final version, ready for duplication, of a project.
Demo: A stripped version of a project, to give an interested party a taste of what the full version has to offer. Four levels of an FPS or one town of an RPG might constitute a Demo. There is no functional difference between the Demo version and the retail version.

User-friendliness

Remember that hardly anyone reads readmes, so everything should be as simple and intuitive as possible, otherwise you will end up answering a thousand e-mails with "it explains feature x in the readme".

Use standard controls where possible and don't add any more new keybinds than are absolutely necessary.

Ian Pilipski: Try not to install your files to the same directories as the original game. Keep your files in a sub-directory. This will make it easier for the end-user to remove or identify which files are part of your mod. You can do this in UT2003 by providing your own <modname>.ini file (preferred and only method you should use as HSDanClark points out below). Just add your mod paths to the [Core.System] heading. The example below could be for a mod named "RaceMod".

[Core.System]
Paths=..\RaceMod\System\*.u
Paths=..\RaceMod\Textures\*.utx
Paths=..\RaceMod\Sounds\*.uax
Paths=..\RaceMod\......(you get the point)

HSDanClark: Never, ever, ever, write your own UT2003.ini file and distribute it with a mod. The last thing you need is for something to go wrong and the user is now left with an unplayable game. The best method is to write an ini file for your game such as MyGame.ini, then use a custom shortcut to launch UT2003 with that file in the command line – e.g. Shortcut to MyGame, with -ini=MyGame.ini in the command line. There's a Wiki page explaining that, and as soon as I find it I'll reference it here.

GRAF1K: Link Me

Tarquin: Is it Game Ini File you want?

HSDanClark: Not exactly... perhaps it wasn't a Wiki page where I found the info; I can't seem to find a relevant page that describes what I was talking about. I found a page a while back that explained how to use custom <Game>.ini, <Game>User.ini and USERLOGO=MyLogo.gif (among others) to change how the game starts up. I'll poke around on the net and see if I can find it again. If I can't, I'll write up a Wiki page for it.

Release CheckList

(this is a rough draft, and I'm certainly no saint when it comes to releasing files... rgx )

When you have adequetely tested your mod, map or mutator and decide it's high time for the mass public to see it, there's a few steps you can try to insure not annoying people or having to issue out a patch:

Before getting to this point, maintain a file list of all the assets your project would be installing. It's easy to forget that one texture file (in fact, and I've done this, texture files seem to be the first things coder-types seem to forget) that you haven't updated in the last few weeks/months/etc.
Write your README and INSTALL docs. For UT2003, they're usually the same text file. ASCII is the most common and readable across platforms, but making an HTML version can look somewhat snazzy and is almost as cross-platform. README's are something of ironic device - they're absolutely essential, but most people won't read them. Regardless, you should include (at least) author information, project overview and description, installation instructions (usually for both the UMOD and ZIP version), any known bugs, and then also any thanks or footnotes. Adding in the filelist isn't necessary, but not always a bad idea. Links to websites, email addresses or other places to hunt down more info is also pretty common.
Make a foldered zip file. Easiest method I have found to do this is to create a brand new folder named something like "mymodzip". Consider that folder the new root of your soon to be archive. In there, make copies of the directories within the UT2003 folder containing only the files for your mod. So, make a System folder into the mymodzip and copy, for instance, the .u and .int files in there. Or for a map, you would make a Maps, Textures, and maybe Sounds for instance. You can then use your archive tool (like WinZip) to just archive the whole mymodzip folder. When someone extracts it to their UT2003 folder, all the subfolders should match up. Put your README in there as well of course (I usually put into the system folder named PROJECT-README.txt or the like ... just naming it "README" can get it overwritten).
Do a clean box test. Find someone who either has never installed your project or can insure they can wipe out all old files. This is also where your file list will come in handy. Here's a tricky part though: make sure to check with your team and double check that the list includes any dependencies. For example - I released the XPakI. A few weeks later, I released the XPakII and found that some people could install and run it fine, and others couldn't. The problem? I had left some references into XPakII about the first one, meaning only people who had XPakI installed could play it. If your project includes any dependencies to things outside of your project (for instance, the Epic Bonus Pack) - this has to be plastered all over your download page, README file, etc.
Make the umod file. Check the Umod Wizard page for more. Now, at this point I've made it sound like both the ZIP and UMOD versions are necessary. This is what I would consider best practice for nearly any project - but each team should examine both versions and make up their own mind. Some teams even use other archive and self-install programs. Here's the deal: ZIP files are great for people who either are installing onto a machine that doesn't actually have a full UT2003 (like a server) or people who are tired of fighting with Windows when it comes to the umod extension. UMOD files are great for people who don't have any problems with the installer and like the double-click ease and uninstall options of it.
Clean box test the umod file.
OK, now you have your archives with their README files. If you want to be cautious, put it up on an FTP somewhere and have a few other people try it out. Not everyone has access to servers though, so FilePlanet, FileShack or the like might be your thing. You might want to shoot emails around to places like BeyondUnreal and PlanetUnreal to get the word out.
Post release, try to track feedback carefully. I can't speak much about maps - but for mutators and mods, I can say that it's not uncommon for a still unforseen problem to arise. Hopefully you've done enough testing that it's a limited problem, or perhaps is some bizarro combination of mutators that causing it or something.
If you are of legal age in the country you reside and fall to this particular habit, it's common to have a beer.

Page under construction

Tarquin: I've made this page because we have several pages on the wiki with personal advice on this topic. I would like to produce something general. Remember to use Document Mode rather than Thread Mode please!

RegularX: Should we add links to Umod Wizard? Maybe some tips on how to generate a zip with the correct folders in it? Maybe of a checklist of things to step through before a release?

Chip: I for one would value this highly, RegularX, as there seems to be no real "standard" for (or even consensus on) the most acceptable distribution method, so specific recommendations from those with experience would be helpful.

RegularX: Once I get block of time I'll try to toss a rough down.

It would be nice if the following ranters could donate some of their thoughts to this page: