= Freedoom

Freedoom is a project to create a complete Doom engine-based game
which is free software, in addition to maintaining compatibility with
Doom modifications (``mods'') that have been released by the
continually-active community since 1993.

Freedoom aims to create three ``IWAD'' files for the engine, each of
these is an independent sub-project representing different aims towards
game design and compatibility with Doom mods:

[horizontal]
*Freedoom: Phase 1*:: A four-chapter game, nine levels each, totalling
36 levels. This project aims for compatibility with The Ultimate Doom
(also known as plain Doom or Doom 1).
*Freedoom: Phase 2*:: A 32-level chapter featuring extra monsters and
a double-barrelled shotgun. This project aims for compatibility with
Doom II.
*FreeDM*:: 32 levels designed for competitive deathmatch play.

An ``IWAD'' file is used by the Doom engine, which contains all the
game data such as graphics, sound effects, music, and so on. While the
Doom engine source code is free, you would normally still need one of
the proprietary IWAD files from id Software in order to play
Doom. Freedoom aims to create a free alternative; combined with the
GPL-licensed Doom source code, results in a completely free
Doom-based game.

For more information, see http://freedoom.github.io/.

== How to play

Hopefully, your engine of choice should already be capable of running
Freedoom without extra configuration. This may not be the case,
however, if the engine does not recognize any of the filenames for
Freedoom, and might require manual intervention to make it so. One of
the following options should do the trick:

  * Use the +-iwad+ command line parameter. For example, to play Phase
    2, you can enter +-iwad freedoom2.wad+ either from a command
    prompt/terminal, or adding it to an application shortcut.
  * Use the +DOOMWADPATH+ environment variable. Many engines support
    this variable to add directories and/or IWADs to their search
    path. The exact syntax matches your operating system's normal
    +PATH+ environment variable.
  * Rename the game IWADs. This may be a bit crude, but you can rename
    the files to match those of Doom's. This is often the easiest
    quick-fix, although it is normally desirable to use one of the
    above methods if possible.

    ** +freedoom1.wad+ can be renamed to +doom.wad+
    ** +freedoom2.wad+ can be renamed to +doom2.wad+
    ** +freedm.wad+ can be renamed to +doom2.wad+

== What ``free software'' means

When we speak of free software, we refer to the software movement in
which your freedoms to use, copy, modify, and study it are ensured.  For
example, you may freely use Freedoom for any purpose you see fit, you
may redistribute it to anyone without needing to ask for permission, you
may modify it (provided you keep the license intact, see `COPYING`), and
you may study it -- for example, to see how a Doom IWAD is built.  To
facilitate this, you can get the full source code (here, in the form of
a DeuTex tree) for Freedoom.

You may read more about free software at the http://www.gnu.org/[GNU]
and http://www.fsf.org/[Free Software Foundation] websites.

== Contributing to Freedoom

Contributions to Freedoom are always welcome, however there are a few
guidelines that should be followed:

=== Intellectual property

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 plenty of WADs out there 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:

  * Everything you submit must be 100% your own work.  You must not base
    upon resources from Doom or any other game.  You may not even rip
    textures from WADs you have downloaded (if you find a WAD with
    textures in which look useful, let us know -- that way, we can
    contact the author).
  * Do not simply copy the original resources.  Where possible, try to
    make an effort to make the new versions look visibly different from
    the originals.
  * Be especially careful of ``free texture'' (or ``free sound'' or
    ``free graphic'') 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 on GNU/Linux CDs
    (which are sold -- ``a commercial use'').
  * The main exception is that you may of course reuse anything in the
    Freedoom source tree.  In fact, this is encouraged, as reusing
    material will give the WAD a more consistent feel.

=== Levels

Levels for Phase 1 and Phase 2 should be compatible with Boom 2.02: a
Doom-derived engine which is a common ancester for many engines
today. Its extensions are even commonly reimplemented by engines which
are not decended from Boom. This means that you may exceed the limits
of vanilla Doom and use features introduced in Boom. However, do not
use features that are not supported by Boom 2.02 and compatible
engines. Levels should be in Doom's original format, not in
``Hexen''-format.

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
VPOs and other such problems in the vanilla engine. This ensures the
maximum compatibility with all Doom-derived engines, including those
that do not descend from nor support Boom features.

It is sensible to also heed the following guidelines:

  * Make sure that skill levels are implemented, and that all
    multiplayer start points are present.
  * 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 source
    ports, 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.
  * Boom removes almost all of the limits on rendering; however, 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 in
    http://www.teamtnt.com/boompubl/boom2.htm[Boom] towards the end of
    your level creation process, before submission. Incompatibilities
    will usually be discovered before a release, but it will help to
    be sure yourself.  Since using DOS-compatible operating systems is
    uncommon these days, you may need to use
    http://www.dosbox.com/[DOSBox] or similar virtual machine software
    to run Boom.
  * 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 itself, in addition to the
    hassle of merely running it.
    http://www.chocolate-doom.org/[Chocolate Doom] is a free software,
    highly-portable, and strictly-vanilla-compatible engine without
    any extra features for levels, suitable for testing FreeDM.

=== Graphics

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

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.

=== Documentation

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

  * We use http://asciidoc.org/[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).

=== Submitting your work

TODO: Figure out the best method of doing this.  This mainly requires
time to see what works best.

If you use git, make sure your commit messages start with a single
line, under 72 characters, which provides an adequate summary of your
changes. You should prefix this line with the component you are commit
(for example, ``map17: fixed unbeatable map''). This should be
followed by a blank line and more explanation if it's needed (for
example, explaining what part of the map was broken). The commit
`2013-12-20T16:06:55Z!rjy@users.sourceforge.net` shows a good example
of a well-structured commit message.

You should commit often; each important change should get its own
commit, but minor changes need not.  Take advantage of git's ability to
rewrite history, don't use `git revert` on your private copy of the
repository, just remove (`git reset`) or amend (`git commit --amend`)
the faulty commit as necessary.  Leave all the interesting and important
history bits, leave out stupid mistakes like spell check errors.