Save game


Revision as of 06:08, 4 February 2022 by Xymph (talk | contribs) (Doom: fix anchor)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

A save game in the Doom engine takes a snapshot of the current game state and saves it to one or more files, allowing the player to resume precisely at the point the save was performed. These files are not usually portable across multiple versions, source ports, or CPU architectures (such as between PowerPC and x86), with few exceptions.


In the vanilla Doom games, save games are a single file per save, named doomsavN.dsg, where N is a numeral of 0-5 depending on the position of the in-game save menu.

Doom has a few engine bugs that prevent save games from working completely as expected. A common manifestation occurs in MAP24: The Chasm (Doom II), where unsuspecting players saving on the narrow ledges would find their save games useless after reloading.


In Heretic, save games are a single file per save, like Doom, and named hticsavN.hsg, where N is a numeral of 0-5 depending on the position of the in-game save menu.


Hexen uses multiple hubs and allows players to freely go back to previously-played levels, and as such, its save format uses multiple files per slot, to save the state of each level as well as the player data. To keep the engine directory clear, vanilla Hexen stores all its files in the hexndata subdirectory, or C:\HEXNDATA when using the -cdrom parameter.

The files hexN.hxs, where N is a numeral from 0-7, contain player data, including the save name, inventory, health, mana, character class, difficulty, and the current level. Files 0-5 directly correspond to the in-game menu's six save slots. 6 is used as a base slot, for the game to stage all save files and copy them to one of the 0-5 slots upon saving, while deleting all the files before a save of any slot first, ensuring that save games should not create invalid game states by storing the state of later levels from prior playthroughs. 7 is used as a “reborn” slot, automatically saved every time a level is loaded and is used to respawn a player to the original state the level was entered, whenever death occurs.

Files hexNYY.hxs, where N represents the save slot and YY represents the internal level number, save the state of all the map objects and ACS scripts in the levels, to be reloaded when a player revisits the maps.


Strife uses multiple files per save, to facilitate loading and saving the state of several levels, since the player can return to any level during progression of the game. Each save slot is therefore stored in its own directory, named strfsavN.ssg, where N is a numeral of 0-6, the first six (0-5) representing the six slots of the in-game menu, and the seventh (6) is used as a temporary area while playing the game. Whenver a game is loaded, or started anew, the strfsav6.ssg directory is overwritten with data for the present play through, saving after each level change, and is copied to one of the other directories when an explicit save is requested.

In each directory are several files for many purposes:

  • Plain-number files (1, 2, ..., 38) represent the level number and saves the state of all map objects in that level.
  • current represents the current level of the save.
  • here is a copy of the current level, plus the player information (inventory, health, armor). This file does not appear in the strfsav6.ssg directory.
  • mis_obj is a copy of the mission objective text.
  • name is the name of the player or save slot.

Strife: Veteran Edition uses the same save directory structure, although the save files themselves are incompatible with vanilla Strife. It adds one additional file to this directory:

  • mis_loc is a special text file describing mission objectives to be highlighted on the automap.

Like other games, Strife has a few engine bugs that affect save games:

Source port compatibility[edit]

Most source ports expand upon the save game format, adding new features and fixing bugs of the original, disregarding compatibility with the vanilla engines. One notable exception is Chocolate Doom, which maintains cross-compatibility with saving and loading vanilla-format save games, even on differing CPU architectures.