The Tavern

What files are used to generate the dungeon terrain and place vaults? I'm digging through the source code now and there are hundreds of files.

I'd like to port some of the dungeon generation code to JavaScript. The idea is to create a microservice that would take input the parameters and return a JSON map containing the dungeon terrain that can be used in a platform independent way for various open source projects. It shouldn't be THAT hard to do this, considering it would mostly just be copying, pasting, and syntax changes.

What I've found so far:

dungeon.cc

Sweet summer child.

dungeon.cc does drive dungeon generation, but it is assisted by the dungeon Lua (DLua) Lua interpreter instance (each crawl process runs two Lua interpreters!), which calls various functions defined in dat/dlua; by the vaults descriptor files in dat/des and its subfolders; and the level compiler which compiles those des files and is defined in lex/yacc in levcomp.ypp and levcomp.lpp.

This apparatus will not port so easily to JavaScript.

There are also the dgn-*.cc files which define special whole-level layouts.

To be honest, it would probably be simpler to create a new system rather than porting crawl's code. Crawl could (in theory) use your new tool to generate new layout types.

Crawl's vault language ("des") is pretty accessible and consequently the project has good knowledge and practice around vault design. But the number of people who understand level layout code/design is much smaller. Defining some sort of data interchange format and even replacing the code could be very cool.

What others have said...dcss has incredibly diverse and complicated procedural generation that is spread across c++ and lua code, it would be easier to start from scratch, or conceivably have a backend running crawlcode rather than porting it.

Here's a rough overview:

• Dungeon generation is basically managed in dungeon.cc and maps.cc, with mapdef.cc doing a lot of supporting work. The main function in dungeon.cc is "builder" and the call to this is kicked off in files.cc:_make_level. Roughly it goes: (i) pick a level layout and some vaults, (ii) run those levels/vaults and try to get a coherent level that is connected, has the right number of stairs etc, (iii) if that works, place non-vault monsters/items. (If it doesn't work, veto and start again.)
• Vault parsing is handled via lex/yacc as mentioned above; this parser basically generates lua code, and most procedural generation is heavy on the lua side.
• Monster and item placement are done almost entirely under level generation, so if you want to accurately replicate levelgen you'll need to handle those as well. See e.g. makeitem.cc and mon-place.cc (and so on).
• Level and vault design are under dat/des. A lot of the level-scale procedural generation is managed under dat/des/builder, especially layout.des. Some of this stuff is pretty mad science-y.
• Lua support code for procedural generation is in dat/dlua, see especially dat/dlua/dungeon.lua and dat/dlua/layout/*.
• Much of this procedural generation code calls back to c++ code, via l-dgn*.cc files. From there it often calls into one of the dgn-*.cc files that chequers mentioned. Some of these are branch-specific.
• Abyss does a lot of extra complicated stuff, see abyss.cc.
• There's regular use of other code that you might not expect; for instance various connectivity checks use the pathfinding code in travel.cc and these have subtle but significant effects on overall levelgen.
• There can be extra layers of moving back and forth between lua and c++. For example, "serial" vaults typically trigger further vault placement in a lua "post-place hook".