We know people hate legalese, but this is important. This applies to everything which is submitted.

You must be incredibly careful when basing on existing graphics or sounds. Most Doom projects are incredibly lax on reusing intellectual property—​there are many mods which contain modified Doom sprites, for example. However, due to the nature of this project, we do not have the same liberty to rip as we please.

The general rules go as follows:

• You must have permission for everything you submit. If you make your own resources, do not base on resources from Doom or any other restricted work. If you take work from other places, please make sure that the work is freely-licensed or that you obtain permission to include it in the Freedoom project. They may not place additional restrictions compared to the normal Freedoom license.

• Do not try to emulate Doom resources exactly. Where possible, put effort to make new versions look visibly different from Doom. This is a tough call, because our compatibility with Doom mods limits how far we can deviate, but it is feasible.

• Be especially careful of “free textures” (or “free sounds” or “free graphics”) sites. Although these would appear at first to be okay to use, many are free for “non-commercial use only.” One of the things we want to be able to do is put this in GNU/Linux distributions (which can be sold or developed commercially).

Levels for Phase 1 and Phase 2 must be compatible with any limit removing engine. This means that you may exceed the limits of the original Doom, but do not depend on any additional mapping features. Levels should be in Doom's original format, not in “Hexen”-format.

It is a goal that future versions of Freedoom will be entirely vanilla-compatible, not even allowing expanded limits. Keeping this in mind while mapping may make it easier for your level to be preserved. Levels requiring large amounts of modification to fit into vanilla limits may be discarded entirely in favor of a less complex map.

Levels for FreeDM must strictly be vanilla-compatible, that is, they must run in the original doom2.exe engine for DOS and not cause any visplane overflows and other such problems in the vanilla engine. This ensures the maximum compatibility with all Doom-derived engines.

It is sensible to also heed the following guidelines:

• Make sure that skill levels are implemented, and that all multiplayer start points, both cooperative and deathmatch, are present.

• Try to make levels appropriately difficult for their position within the progression of the game. Also bear in mind that not all players may be as skilled a player as you.

• Do not use tricks that exploit Doom's software renderer; some engines, especially those that use hardware accelerated rendering, may not render it properly. Examples of tricks to avoid include those used to simulate 3D bridges and “deep water” effects.

• While unrestricted by limits, do not make excessively complicated scenes. It is desirable that Freedoom levels should be playable on low-powered hardware, such as phones and old computers.

• For Phase 1 and Phase 2, try to test your levels in Crispy Doom, which is an engine that is limit removing but does not introduce mapping features to accidentally exploit.

• For FreeDM, while you can test in the original doom2.exe engine with DOS or an emulator, this original engine is not free software and not legally obtainable without Doom, in addition to the hassle of merely running it. Chocolate Doom is a free software, highly-portable, and strictly vanilla-compatible engine without any extra features for levels, suitable for testing FreeDM.

Graphics should generally have the same color and size as the original Doom graphics, as to remain compatible with mods. Otherwise, levels may end up looking like a nightmare in design. They may be thematically different as long as it doesn’t clash.

Doom uses a fictional corporation abbreviated as “UAC:” this is trademarked by id Software and cannot be used in Freedoom. Instead, use the initials “AGM” for Freedoom.

Freedoom always needs help with documentation, so please send your patches, but keep in mind:

• We use AsciiDoc for writing the documentation. AsciiDoc is a simple plaintext-based format which is simple to read and write in its source form, and can generate nice HTML documents out of them.

• Headers are formated in a wiki-style format, this makes it easier for Vim (perhaps other editors, too) to automatically re-format text.

• Text is kept at 72 characters wide. In Vim, you can set the editor to automatically insert line breaks as you’re typing by performing set textwidth=72. Special exceptions to the width rule might be allowed when necessary (for example, inserting long URLs).

The most common, and a fairly simple method, to submit your work is by posting it on the Freedoom forum on Doomworld Forums. This allows a great number of people to review the contribution and provide feedback, although the registration process is known to be cumbersome.

An alternative to using the forum, is to post your submission on the issue tracker, which may also be peer-reviewed and provide a feedback cycle.

Lastly, it is possible to get work submitted by joining the official #freedoom IRC channel, although this poses the greatest risk of being lost and forgotten.

Unfortunately, the Freedoom project cannot provide hosting space in the form of a web page nor FTP, however there are many free file hosts to use when you need a location to upload files. Sites and services such as Dropbox and Mega, as well as others, are common and should be simple to use.