Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Freedoom is an effort to make an entirely free software game based on the Doom engine.
Python C Makefile Shell
branch: master

README.adoc

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:

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 GNU and 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 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 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 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 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. 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 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 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 in the scrollback history 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.

Using Git

You can also use commit directly off of a clone of the Freedoom repository, although this tends to be a highly technical task and it is okay to allow other Freedoom maintainers to do it instead: that is our normal mode of operation! Pull requests may come from anywhere, you need not use GitHub if you wish not to, however GitHub usually makes this sort of thing very simple.

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 should never bleed into a second line, and should never 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!fraggle@gmail.com is a good example.

Additionally, use either simple pointers to other commits, such as “my previous commit”, or use action stamps, which can improve the meaningfulness of commit identifiers if the repository is rewritten at an early point in, or if the repository is ever converted to another DVCS. At the time of writing (November 2014), 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 doing them.

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.

Something went wrong with that request. Please try again.