Legacy: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: Category:Legacy 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.

Distribution format

There are a few ways to distribute your mod:

• Plain compressed archive
• Installer
• UMod

Server Administrators prefer plain compressed archives, because often they don't have a graphical interface or installed copy of the game. Also archives are easier to be reviewed for it's contents.

Normal users/players prefer to use installers/umods so they can uninstall the game in the future.

So always release both a plain archive and an install/umod of your mod (zip and umod are the best choise).

Compressed archive

This is the easiest method. However, don't use exotic archive formats, stick with the normal ZIP format. Ofcourse RAR or 7z will produce smaller archives, but they are less common. With ZIP you know for sure that pretty much every user can extract them without needing to search for a tool to extract it.

You could create a self extracting volume (a.k.a SFX), but this is maybe the worst method. Because it's pretty much the same as a normal installer, except that it doesn't have an uninstall method. In other words, no SFX archives.

Installer

Installers are nice, you can guide people through the whole install and make sure everything is done correctly and they will be able to uninstall the mod in the future. However, installers are pretty much always system depended. This isn't very usefull for people on other Operating Systems.

If an installer isn't set up correctly, it might leave behind files during uninstall. So test your installer on a clean installation of the game to make sure it doesn't leave behind any files when it's uninstalled. (Making sure the uninstaller doesn't uninstall too many files doesn't need to be mentioned, I guess.)

There are quite some free installer generators available. Here's a short list of free installer generators:

• Inno Setup
• NSIS

UMod

Not the easiest thing to create, but Umod Wizard can make it much easier.

UMods are the best choice for an installer, it can be installed for every operating system and it can also be uninstalled (via the game's uninstaller/setup).

However, often users managed to screw up their game install. You might want to include directions on your download page how they could fix it (Or link to this page: UMOD/Problems)

Because UMods are not compressed they might become quite large. It's ok to simply zip the UMod and release that. It's best to hint the umod in the filename of the zip file: MyMod-version-umoz.zip

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:

1. 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.

1. 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.

1. 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).

1. 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.

1. 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.

1. Clean box test the umod file.

1. 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.

1. 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.

1. 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:

• Mychaeel/Modding Etiquette
• RegularX/Rants
• Piglet/Finishing Things