The Freedoom project aims to create a complete, free content first person shooter game, but Freedoom by itself is just the raw material for a game. It must be paired with a compatible Doom engine to be played.
There is a massive back catalog, spanning over two decades, containing thousands of Doom levels and other modifications (``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.
Freedoom is actually three games in one, consisting of two single-player oriented campaigns and one set of levels designed exclusively for multiplayer deathmatch:
Freedoom: Phase 1 |
Four chapters, nine levels each, totalling 36 levels. This game aims for compatibility with The Ultimate Doom, also known as plain Doom or Doom 1. |
Freedoom: Phase 2 |
32 levels in one long chapter, featuring extra monsters and a double-barrelled shotgun. This project aims for compatibility with Doom II and Final Doom. |
FreeDM |
A 32-level game designed for competitive deathmatch play. |
The engine uses a single file, such as freedoom2.wad, that contains all the game data such as graphics, sound effects, music, and so on. This file is often called an ``IWAD'' by those in the Doom and Freedoom communities. While the Doom engine source code is free, you would normally still need one of the proprietary data files from id Software to play Doom. Freedoom aims to create a free alternative: combined with the GPL-licensed Doom source code, this results in a completely free game.
For more information, see http://freedoom.github.io/.
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 Doom Wiki.
One in particular that is highly recommended by the Freedoom project is Odamex. This engine offers good support for both single-player and multiplayer games.
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.
If you wish to venture outside of Odamex, beware that Phase 1 and Phase 2 require a Boom-compatible engine, which is thankfully the majority of them, but without compatibility, some aspects of the game may not run properly. FreeDM, on the other hand, is intended to be playable by all variants of the Doom engine.
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 solve it:
-
Use the -iwad command line parameter. For example, to play Phase 2, you can enter -iwad freedoom2.wad either at a command line, or adding it to an application shortcut.
-
Use the DOOMWADPATH environment variable. Many engines support this variable to add directories and/or files to their search path. The exact syntax matches your operating system’s normal PATH environment variable.
-
Rename the game files. 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, tnt.wad, or plutonia.wad
-
freedm.wad can be renamed to doom2.wad, tnt.wad, or plutonia.wad
-
Additionally, 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 altogether.
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 GNU and Free Software Foundation websites.
Contributions to Freedoom are always welcome, however there are a few guidelines that should be followed:
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'' orfree 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 should be compatible with Boom 2.02: a Doom-derived engine which is a common ancestor for many engines today. Its extensions are even commonly reimplemented by engines which are not descended from Boom. This means that you may exceed the limits of the original Doom and use features introduced in Boom. 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 visplane overflows 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, both coöperative 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.
-
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 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 a DOS-compatible operating system is uncommon these days, you may need to use 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, 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.
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.
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 format commonly seen in distributed
version control systems, and adopted by high-profile projects such as
Linux and Git. The first line of a message needs to be a short
summary, preferably at a 72-character limit. The summary usually
begins with a short component name followed by a colon, this can be a
directory name (eg, musics:
), a resource name (eg, map17:
), or a
more generic component (eg, build system:
). The summary line must
not bleed into a second line, and should not be the start of a lengthy
explanation. If the commit needs further explanation (and they often
do), use extra paragraphs and write in plain English what the commit
is about. The commit 2014-08-24T22:42:37Z![email protected]
is a
good example.
Additionally, do not use commit hashes to refer to other commits. Use
other kinds of pointers, simple ones like `my previous commit'' might
suffice, or use action stamps, which
can improve the meaningfulness of commit identifiers if the repository
history is rewritten (this has happened at least twice!), or if the
repository is converted to another VCS (this happened once before).
At the time of writing (July 2015), core Git does not yet have a
mechanism to output this format, but you may use a
shell script and
place it in your `$PATH
to achieve some ease in generating them.
You should commit at each logical step. Do not bundle up many
unrelated changes into the same commit, and definitely do not write a
commit message like `changed some stuff.'' Best judgment should be
used for what constitutes a logical step. It may be just a single
file, or it may be a group of files representing a monster in the
game. If you are finding yourself needing to repair previous commits'
blunders in your private repository, try to take advantage of Git’s
ability to rewrite history , don’t use `git revert
, just remove (git
reset
), amend (git commit --amend
), or rebase (git rebase
) as
necessary. Leave all the interesting and important history bits,
leave out stupid mistakes like spell check errors if you catch them.