freedoom/README.adoc

= Freedoom

_Freedoom_ is a complete, free content first person shooter game,
based on the _Doom_ engine.

_Freedoom_ is not a program - rather, it consists of the levels,
artwork, sound effects and music that make up the game. To play
_Freedoom_, <<How-to-play,it must be paired with an engine>> that
can play it.

_Freedoom_ is actually three games in one, consisting of two
single-player oriented campaigns and one set of levels designed
exclusively for multiplayer deathmatch:

[horizontal]
*Freedoom: Phase 1*:: Four episodes, nine levels each, totalling 36
levels.  This game aims for compatibility with _The Ultimate Doom_
mods, also known as plain _Doom_ or _Doom 1_.
*Freedoom: Phase 2*:: 32 levels in one long episode, featuring extra
monsters and a double-barrelled shotgun.  This project aims for
compatibility with _Doom II_ mods.
*FreeDM*:: A 32-level game designed for competitive deathmatch play.

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

== How to play

Since _Freedoom_ is only the game data, you will still need to
download an engine separately.  These are also often termed “source
ports” by the community.  There are an overwhelming number of choices
available, a lengthy list of which is available on the
https://doomwiki.org/wiki/Source_port[Doom Wiki].

One particularly recommended by the _Freedoom_ project is
https://zdoom.org/[GZDoom].  This engine offers good support for
single-player, multi-player, and the majority of mods created for both
_Doom_ and _Freedoom_.

On Windows, you should place _Freedoom_’s data files (those ending
with +.wad+) alongside the engine (eg, +odamex.exe+).  On Unix-like
systems, these data files should go in either +/usr/share/games/doom+
or your home directory.  If _Freedoom_ comes packaged as part of your
operating system distribution, it should already be installed into the
proper location.

For Unix-like operating systems, such as GNU/Linux or a BSD variant,
_Freedoom_ may be packaged and installed with programs named
+freedoom1+, +freedoom2+, and +freedm+ that automatically run an engine
for proper play. Desktop files may also be installed so that you can
start the game using a graphical interface and avoid the command line
a ltogether.

== Manual

Freedoom has a complete PDF format manual that describes how to play the
game, including an introductory tutorial and some tactical tips. It also
has information on the monsters and power-ups you'll encounter during
play. The manual is available in multiple languages and can be
downloaded https://freedoom.github.io/manual.html[on the website].
Printed, physical manuals are also available for purchase.

== Compatibility

A secondary goal of Freedoom is _compatibility_ with modifications
("mods") for the original Doom.  There is a massive
https://doomwiki.org/wiki/Idgames_archive[back catalog], spanning over
three decades, containing thousands of _Doom_ levels and other
mods made by fans of the game. _Freedoom_ aims to be compatible with
these and allows most to be played without the need to use non-free
software.

== What “free” means

When we speak of free content or software, we refer to the movement in
which your freedoms to use, copy, modify, and study a work is not
infringed.  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
an “IWAD” is built.  To facilitate this, you can get the full source
code for _Freedoom_, in this case, in the form of a DeuTex tree.

You may read more about free software at the https://www.gnu.org/[GNU]
and https://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 careful when basing on existing graphics or sounds.  Most
_Doom_ projects are 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.
  * Freedoom's name often leads some people to think that the project's
    goal is to make a "free clone of Doom". This is not the case! While
    compatibility with Doom is a goal, we are our building our own game.
    Please make an effort to ensure your work is original and distinct,
    and not just a copy of anything from Doom.
  * 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

All levels for _Freedoom_ must be vanilla-compatible, requiring an
expanded-limits or limit-removing engine is not permissible.  This
means you may not exceed the limits of the original _Doom_ engine, and
do not depend on additional mapping features.  Levels should be in
_Doom_’s original format, not in “Hexen”-format.

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.
  * Test your levels in https://www.chocolate-doom.org/[Chocolate
    Doom] to make sure that vanilla compatibility is maintained.  This
    is an engine with strict adherence to vanilla Doom limits and
    bugs, and working in it assures that levels can be played with any
    _Doom_ engine.
  * Use a Doom editor to check for errors. In
    http://eureka-editor.sourceforge.net/[Eureka] it's possible to
    check for errors with the Check / All menu, or by pressing `F9`.
  * If possible run `make test` and fix any errors found. Note that
    some of the errors can be fixed by `make fix`.

=== Graphics

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

=== Documentation

_Freedoom_ always needs help with 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

The most common, and a fairly simple method, to submit your work is by
posting it on the
https://www.doomworld.com/forum/17-freedoom/[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
https://github.com/freedoom/freedoom/issues[issue tracker], which may
also be peer-reviewed and provide a feedback cycle.

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 https://www.dropbox.com/[Dropbox] and
https://mega.co.nz/[Mega], as well as others, are common and should be
simple to use.

==== Crediting information

_Freedoom_ is made up of submissions from many people all over the
globe.  All of them, and you, deserve credit!  Please do not forget to
provide your name and email when submitting resources.

==== Using Git

You can also commit on a clone of the _Freedoom_ repository, although
this is a technical task and it is okay to let other _Freedoom_
maintainers to do it instead: that is our normal mode of operation.
However, pull requests are much appreciated and you may submit them in
any manner you wish, with GitHub’s direct pull requests being the
simplest, but by far not the only means.

Freedoom uses the commit message style commonly seen in distributed
version control systems, adopted by projects such as Linux and Git.
For an explanation of this style, see
https://chris.beams.io/posts/git-commit/[How to Write a Git Commit
Message].

If you create a git commit for someone else it is helpful to set the
author of the commit so that they get credit. Ask them what name/alias
and email they would like to use. For example:
[source,bash]
-----------------
git commit --author "Bob Smith <bob@example.com>" ...
-----------------
If they prefer not to give an email then the email can be omitted, so
just "Bob Smith" in the above example.