This already assumes that you've installed DoomTools. If you haven't, go here!
So, you want to make a Doom project? Do you want to make it so that you don't have to worry about needing to painstakingly throw together everything you made, also perhaps worrying that you may have included more than you needed to?
Well, you're in luck!
DoomMake is a project builder for Doom mods. It's a program that builds a file system scaffolding where you throw everything in the correct directories and your wonderful WAD file pops out! Whether you are making something by yourself or with others, DoomMake does the heavy lifting when it comes time to package up your work before you send it out into the world!
To create your project, type this at the command prompt:
doommake --new-project ...and the project folder will be created in the current directory. The directory must be empty or non-existant. You will probably also be asked a few questions to fill in a bunch of critical pieces, like the resultant WAD name and such.
Modify the README.md file in the project and describe it briefly, especially if you make this project public.
Look for the src/wadinfo.txt and the src/credits.txt files in the project. The Wad Info file is your text file that will be packaged with the project WAD. The credits are for maintaining author and extended credits. Both of these files will also end up in your resultant WAD file as WADINFO and CREDITS lumps, respectively.
Every project has a file called doommake.project.properties in the top project folder that contains project-specific settings. If you are maintaining this project in version control, this file is automatically included.
Every project also has a file called doommake.properties in the top project folder that contains build-specific settings for your local copy. If you are maintaining this project in version control, this file is NOT included (and it shouldn't be added, however you should outline which properties are important for other project contributors).
If you edit files like graphics/sprites in this project, you should open the src folder in the project in SLADE if you need to edit in bulk. Be aware that there could be some folders that auto-convert some resources and add them to other project folders.
After you created your project, you'll need to switch to the project's directory (make it the "current" directory), or else DoomMake will complain that it can't find the project's scripts.
To build the full project, type:
doommake...and everything will be compiled together into the project, and distributable archives will also be made.
To clean the build directory, type:
doommake clean...and the contents of the build and dist directory will be deleted.
The contents of your build folder (and perhaps the texture WAD folder) are more than likely going to be where you get the resources for your project when making maps. Using those folders in this way will keep your editing environment stable for when you or others make changes to your project. All you'll need to do is rebuild!
NOTE: DoomMake is usually smart enough to detect changes to the project and skip all unchanged pieces and steps, but in case something goes wrong, you can delete the build/lock.json file to force a rebuild of everything, or change/alter the hashes to force rebuilds.
Below is some more information about the selected project pieces.
Note that all of the following information is valid for project structures created out-of-the-box with DoomMake. If you change the scripts and structure, you're on your own!
The project's loose non-texture assets like graphics, sprites, music, and sound should be placed in the folders off of src/assets.
The folder src/assets/_global should contain anything that is to be added into the global WAD namespace as-is. Subfolders are searched and imported, but no markers are added per subfolder.
The folder src/assets/graphics should contain graphics that are added into the global WAD namespace as-is. No conversions are applied to these files on import. Subfolders are searched and imported, but no markers are added per subfolder.
The folder src/assets/music should contain music lumps that are added in the global WAD namespace as-is. No conversions are applied to these files on import. Subfolders are searched and imported, but no markers are added per subfolder.
The folder src/assets/sounds should contain sound lumps that are added in the global WAD namespace as-is. No conversions are applied to these files on import. Subfolders are searched and imported, but no markers are added per subfolder.
The folder src/assets/sprites should contain sprite graphics that are added into the WAD's sprite namespace (SS_START / SS_END) as-is. No conversions are applied to these files on import. Subfolders are searched and imported, but no markers are added per subfolder.
Files that need conversion before asset merge are placed in the src/convert folder's subfolders.
The folder src/convert/graphics should contain graphics that get converted from formats like PNG, GIF, BMP, or JPG and end up as LMPs in build/convert/graphics. If PNG files have offset information in them (grAb), it is preserved on conversion. Target files are overwritten.
The folder src/convert/sounds should contain sounds that get converted from formats like WAV or AIFF and end up as DMX-formatted sounds in build/convert/sounds. Stereo sounds are mixed to mono, but their sampling rate is preserved. If you need to convert from other formats, you need to have FFmpeg on your system PATH (or point to it some other way). Target files are overwritten.
The folder src/convert/sprites should contain sprite graphics that get converted from formats like PNG, GIF, BMP, or JPG and end up as LMPs in build/convert/sprites. If PNG files have offset information in them (grAb), it is preserved on conversion. Target files are overwritten.
The WadMerge script file scripts/merge-assets.txt govern how the src/assets folder's files are merged together. By default, this will create the build/assets.wad file.
When editing your project's maps, it is recommended to use this output WAD file as a resource.
The source file for compiling a DECOHack patch is in src/decohack/main.dh. By default, the patch is compiled and placed in the build folder as build/dehacked.deh. The patch's source data is merged together into one file as build/decohack.dh.
The WadMerge script file scripts/merge-release.txt affects how patches make their way into the final WAD file, imported as-is.
The DeHackEd file that gets copied to the build folder is copied from the src/patch folder. By default, the patch is copied from src/patch/dehacked.deh. You can change this in doommake.project.properties.
If you are committing this project to a code versioning system, .whacked files will be ignored by default, so you can edit and save the file in-directory.
The WadMerge script file scripts/merge-release.txt affects how the patch makes its way into the final WAD file, imported as-is.
Your source texture WADs to use for the project should be placed in the src/wads/textures folder.
When editing your project's maps, it is recommended to use these WAD files as resources, especially since the textures referenced by the maps will be exported on make.
Textures that are created and used by the project come from the src/textures folder. The files texture1.txt and/or texture2.txt are the source files that create the TEXTURE1 and TEXTURE2 lumps, and the PNAMES lump is assembled by the names of the patches in those files.
When the project is first created, these files contain only one texture and nothing else. If you want to pre-populate the texture1.txt and/or texture2.txt files with textures from the main IWAD as a base, delete those files, make sure the path to your IWAD in doommake.properties is valid and type the following:
doommake rebuildtexturesThe defswani.txt file in the src/textures folder will be read and converted into ANIMATED and SWITCHES lumps for animated and switch textures.
The folder src/textures/patches should contain the patch graphics that are added into the WAD's patch namespace (PP_START / PP_END) as-is. No conversions are applied to these files on import. Subfolders are searched and imported, with markers added per subfolder.
The folder src/textures/flats should contain the flat graphics that are added into the WAD's flat namespace (FF_START / FF_END) as-is. No conversions are applied to these files on import. Subfolders are searched and imported, with markers added per subfolder.
The folders src/textures/texture1 and src/textures/texture2 should contain the graphics that are added into the WAD's patch namespace (PP_START / PP_END) as-is, but they are also added to the TEXTUREx lump of their same name as single-patch textures. No conversions are applied to these files on import.
The file src/textures/animflats.wad is a little special - it should contain flat graphics that get added into the WAD's flat namespace (FF_START / FF_END) as-is, but in the order that they are in this WAD. This for flats that need to be in a specific order in order to make animations work properly. Be careful not to put the same flats in this WAD and the flats folder!
Files that need conversion before asset merge are placed in the src/convert folder's subfolders.
The folder src/convert/patches should contain graphics that get converted from formats like PNG, GIF, BMP, or JPG and end up as LMPs in build/convert/patches. If PNG files have offset information in them (grAb), it is preserved on conversion. Target files are overwritten.
The folder src/convert/flats should contain graphics that get converted from formats like PNG, GIF, BMP, or JPG and end up as LMPs in build/convert/flats. If PNG files have offset information in them (grAb), it is NOT preserved on conversion (flats do not have this info). Target files are overwritten.
The folders src/convert/texture1 and src/convert/texture2 should contain graphics that get converted from formats like PNG, GIF, BMP, or JPG and end up as LMPs in build/convert/texture1 and build/convert/texture2, respectively. If PNG files have offset information in them (grAb), it is preserved on conversion. Target files are overwritten.
The WadMerge script file scripts/merge-textures.txt affects how the texture data gets merged into the source texture WAD in the build folder (as build/textures.wad, by default).
When editing your project's maps, it is recommended to use this output WAD file as a resource.
The project's maps should be in individual WAD files and placed in src/maps. You can edit and save maps directly into this directory - .dbs and other backup and autosave files made by Doom Builder-family editors (.backup*, .autosave*) are ignored by version control by default, if you use it.
The WadMerge script file scripts/merge-maps.txt govern how the src/maps folder's files are merged together. By default, this will create the build/maps.wad file.
When the project WAD gets built, the non-stock textures used in all of the maps in src/maps that are found in the project textures get exported to build/maptex.wad by default. The contents of that output WAD are merged into the final WAD.
The WadMerge script file scripts/merge-release.txt affects how the output texture WAD makes its way into the final WAD file, imported as-is.
By including the Git template in your project, the files .gitattributes and .gitignore will be added to the project. These files will automatically be filled with information about the files that could possibly be added to your project, such as which files are guaranteed to be text or binary (in .gitattributes) and which files are going to be ignored by automatic addition (in .gitignore).
The .gitignore file will also exclude some IDE files and local configuration by default.
Preparing your first commit is going to be the easy part. If you have a remote repo (such as via Github or Bitbucket), you're going to want to create an empty repo first on your favorite service (make sure it contains NO FILES NOR BRANCHES - you'll push your project in full).
Either way, the first couple of steps are the same:
git initgit add -Agit commit -m "Initial commit."Pushing to your remote will be a little different for your target service, and they should provide directions for it.
By including the Hg (Mercurial) template in your project, the file .hgignore will be added to the project. This file will automatically be filled with information about the files that could possibly be added to your project, such as which files are going to be ignored by automatic addition.
The .hgignore file will also exclude some IDE files and local configuration by default.
Preparing your first commit is going to be the easy part. If you have a remote repo, you're going to want to create an empty repo first on your favorite service (make sure it contains NO FILES NOR BRANCHES - you'll push your project in full).
Either way, the first couple of steps are the same:
hg inithg addhg commit -m "Initial commit."Pushing to your remote will be a little different for your target service, and they should provide directions for it.
Running your project from DoomMake takes a tiny bit of configuring, but a lot of the setup should be finished from the questionnaire on project creation.
You can run the default port that you set up via the command:
doommake runThe properties in doommake.properties should explain each of the fields used for running a source port for testing. The doommake run command will attempt a build and then, depending on what it finds: adds the IWAD in the doommake.properties via the IWAD switch, the maps.wad, maptex.wad (or textures.wad if not found), and assets.wad via the file switch, and the DeHackEd file dehacked.deh using the DEH switch.
Certain ports may require you to use different switches - Chocolate Doom, for instance, may require you to use -merge for the file switch (see the doommake.run.switch.file project property). For most other ports, though, you can leave them unchanged.
Running a project is more useful when you aren't actively testing maps via a map editor. For tweaking patches and graphics, though, it will reduce your testing turnaround!
DoomMake can support more than one port for running in one project. All you need to do is create additional corresponding properties for a port name.
For example, if you want to run a port by typing:
doommake run chocoYou'll have to at least create a doommake.run.exe.choco property that points to the port EXE, plus other corresponding fields if you don't want to use the defaults (e.g. doommake.run.switch.file.choco, etc.).
That's it! Make some projects!