Persistent level

From NetHackWiki
Jump to navigation Jump to search

The term "persistent level" often appears when contrasting roguelike games. A dungeon level is persistent if the player may return to the level after leaving it. The game must store the map and contents of any level that the player might revisit in the future.

NetHack has persistent levels, up until just before you enter the Elemental Planes. When you leave a level, NetHack writes the level to a temporary file on disk (in the playground). These temporarily files also provide the basis to recover a crashed game. When you save your game, NetHack stores the levels in your save file.

Persistent levels were an innovation in NetHack's predecessor, Hack. Actually, Jay Fenlason included the ability to write a dungeon level to disk and read it later in the original design of Hack.

  • Because of the peculiar restraints on our system, I make mklev (create a level) a separate procedure execd by hack when needed. The source for mklev is (Naturaly) mklev.c. You may want to put mklev back into hack. Good luck.

The mklev program writes a new level to disk, and the hack program reads it. To implement persistent levels, after the player leaves each level, hack must write the modified level to disk again. When reading the level again, hack contains code to regenerate monsters, as if time passes while the player is away (thus Hack implements a "mostly persistent" dungeon.)

You may view the implementation in (Andries Brouwer's) Hack 1.0 source code. The code to read a level is in hack.lev.c; hack and mklev share the code in savelev.h to save a level. Hack 1.0.2 merges the mklev code into hack. The modern implementation for NetHack 3.4.3 is more complex, and lives in two source files restore.c and save.c.

The first roguelike game, Rogue, coped without persistent levels because it never generated staircases back to previous levels. In Rogue, there are only down staircases, until after you acquire the Amulet of Yendor, when there are only up staircases to a different branch of the dungeon.

Rogue did have a save feature, which did embed the current dungeon level in the save file. Actually, Rogue implemented the save feature by crudely dumping everything in memory from version to sbrk(0), with no regard to which part of memory contains the current dungeon level. (Carefully read the save.c file of Rogue 3.6 for details.) So there was no way to write the current dungeon level to its own temporary file. Now that the Roguelike Restoration Project has reformed the save feature, one might be able to hack a Rogue variant that supports persistent levels.