Vault submissions

[clouded]

Here's a few vaults. They are in Sil's syntax but anyone is free to modify and use how they see fit.

http://sprunge.us/AIdB

Also, here is a rough design for a new throne room. I've left my notes in. I tested it a bit (with melee and with stealth), but not extremely thoroughly. Feedback on this would be good, if it's wanted.

http://sprunge.us/TFMH

By the way, I have to gripe about the vault system. Almost no randomisation without duplication, fiddly indexing (having to have stuff in order), needing to specify the size of stuff (you've no idea how many times I messed this up). Make this better for pyrel please!

[Magnate]

Originally Posted by clouded

By the way, I have to gripe about the vault system. Almost no randomisation without duplication, fiddly indexing (having to have stuff in order), needing to specify the size of stuff (you've no idea how many times I messed this up). Make this better for pyrel please!

We will, Oscar, we will ...

[HallucinationMushroom]

I like the names of some of them especially, like circular thing. These look great!
I will try your throne room when I get the chance.

[Nick]

As far as pyrel is concerned, I would also want to upgrade the V vault system to be as flexible as Sil and it's cousins (O, NPP, FA). Being able to specify specific monster and object types in a vault is kind of a no-brainer.

[half]

Originally Posted by clouded

Here's a few vaults. They are in Sil's syntax but anyone is free to modify and use how they see fit.

Thanks clouded. Some of those will definitely be put into Sil in a future version. (Though I'm unlikely to see any dev time until April).

[half]

Originally Posted by Nick

As far as pyrel is concerned, I would also want to upgrade the V vault system to be as flexible as Sil and it's cousins (O, NPP, FA). Being able to specify specific monster and object types in a vault is kind of a no-brainer.

Also, one could have a look at Crawl's vault files. They are *very* extensible, allowing you to use symbols on the map and then have a key at the end that says what each symbol represents if they are non-standard ones.

[Derakon]

My assumption for Pyrel is that there will be a template system like there is for the other data files. The standard template (that all current vaults would inherit from) will define all the usual symbols for Angband vaults, but you could have different templates if you wanted to. Symbol definitions could include being decided by Procs, which among other things would allow for:

* One-off special tile definitions (a vault that contains Bill, Bert, and Tom)
* Having vault walls be made out of different materials depending on context (e.g. trees for wilderness vaults, stone for dungeon vaults)
* Entirely procedurally-generated vaults (make the vault just a big mass of "call this maze-generating Proc")
* Unique scripted behavior (pressure plates linked to movable walls, etc.)

[clouded]

Originally Posted by Derakon

My assumption for Pyrel is that there will be a template system like there is for the other data files. The standard template (that all current vaults would inherit from) will define all the usual symbols for Angband vaults, but you could have different templates if you wanted to. Symbol definitions could include being decided by Procs, which among other things would allow for:

* One-off special tile definitions (a vault that contains Bill, Bert, and Tom)
* Having vault walls be made out of different materials depending on context (e.g. trees for wilderness vaults, stone for dungeon vaults)
* Entirely procedurally-generated vaults (make the vault just a big mass of "call this maze-generating Proc")
* Unique scripted behavior (pressure plates linked to movable walls, etc.)

Sounds like that could allow for a lot. But perhaps it could help to give you an idea of what would be important to me, as a vault designer? I very much agree with half that crawl has a robust and easy to use vault system, which I'm extremely familiar with, so I'd like to illustrate what I'm talking about by using its syntax.


* Substituting glyphs, either per each instance of a glyph or across all instances of a glyph. Examples:

# make each individual ? either a random monster (0) or floor (.)
SUBST: ? = 0.

# make all & across the map either a random monster or floor
SUBST: & : 0. 

# make ! a random monster (0) 3/4 of the time or an OOD (9) 1/4 of the time
# the :30 after the 0 here is the weight, the default weight is 10
SUBST: ! = 0:30 9
# or
# 0 with a weight of 6, 9 with a weight of 2
SUBST: ! = 0:6 9:2
# or
SUBST: ! = 0009 

# make ~ either water or lava, with further modifications on each
# water would become a mix of shallow (W) and deep (w) water
# lava would become a mix of lava (l) and floor 
SUBST: ~ : wl, w = wW, l = l.

* More involved substituting, specifying exact numbers

# make % have 1 random instance of a door (+) and all other instances be rock walls (x)
NSUBST: % = 1:+ / *:x

# or make % have 1 door and 1 floor, amongst walls
NSUBST: % = 1:+ / 1:. / *:x

# or make % have 4 doors amongst walls that are either rock (x) or stone (c)
NSUBST: % = 4:+ / *=xc

* Shuffling the placement of glyphs

# shuffle the placement of rock walls (x), stone walls (c) and metal walls (v) 
# so rock could become stone and stone could become rock, metal remaining metal
# or rock remains rock and stone and metal switch
# or any of the other possibilities
SHUFFLE: xcv

# shuffle the placement of groups of glyphs
# either x and c will remain as x and c, or x will become v and c will become .
SHUFFLE: xc / v.

That's the core of crawl's terrain and monster randomisation, there's of course much more you can do, but this is the bare minimum. Here's a contrived (and bad) example map putting what I mentioned together:

NAME:    example_thing
DEPTH:   D:3-4
KMONS:   1 = kobold
# hobgoblins twice as common as goblins
KMONS:   2 = goblin / hobgoblin w:20
KMONS:   3 = ogre
# '3' can either be inside the towers or outside them,
# move the the gold with them
SHUFFLE: 3$ / ab
# set 'a' and 'b' as floor
SUBST:   ab = .
# shuffle the placement of '3' and '0'
SHUFFLE: 30
# '3' has one ogre, and the rest kobolds
NSUBST:  3 = 1:3 / *:1
# '0' can be a mix of kobolds and goblins/hobgoblins
# or have either all kobolds or all goblins/hobgoblins
SUBST:   0 = 09, 0 = 12, 9 : 12
# place the door to the centre room on one of the faces
NSUBST:  X = 1:+ / *:x 
# make the doors into the towers either on the outside or inside
SHUFFLE: zyu
SUBST:   z = +, y = x, u = x  
# make the walls either rock or stone
SHUFFLE: xc
# make the moat either deep water, lava or trees
# give water a higher weight and lava a lower one
SUBST:   w : w:15 l:5 t
MAP
...................
.wwwwwwww.wwwwwwww.
.wxxxx.......xxxxw.
.wx3.z.ab.ba.z.3xw.
.wx$.xxxx+xxxx.$xw.
.wxyxu.......uxyxw.
.w..x..xXXXx..x..w.
.w..x..X000X..x..w.
....+..X000X..+....
.w..x..X000X..x..w.
.w..x..xXXXx..x..w.
.wxyxu.......uxyxw.
.wx$.xxxx+xxxx.$xw.
.wx3.z.ab.ba.z.3xw.
.wxxxx.......xxxxw.
.wwwwwwww.wwwwwwww.
...................
ENDMAP

See here if you want to read further into crawl's vault syntax. There's also an awful lot you can do with lua (see some of the sprint maps and portal vaults for some really crazy stuff).

[Derakon]

That's pretty impressive. Pyrel will almost certainly use JSON for the vault definition files, since it uses JSON everywhere else; the syntax thus won't be as compact as it is in Crawl, but generally speaking, I find that verbose is preferable over terse. After all, most of the time in designing a vault is not spent on typing; it's spent on designing. As long as the syntax isn't so verbose that it makes it hard to get an at-a-glance understanding of the structure we should be fine.

If I had to imagine how things would look in Pyrel, I'd guess it'd be something like this:

{
    "name": "kobold camp", "templates": "standard vault template",
    "allocatorRules": [{"commonness": 20, "minDepth": 3, "maxDepth": 4}],
    "glyphs": {
        "creatures": {
            "1": "kobold",
            "2": {"weightedNames": {"goblin": 1, "hobgoblin": 2}},
            "3": {"countedNames": {"ogre": 1, "kobold": NULL}},
            "0": {"selectGroup": [["1"], ["1", "2", "3"], ["2", "3"]]}
        },
        "terrain": {
            "X": {"countedNames": {"+": 1, "x": NULL}}
        }
    }
    "genProcs": [
        {"name": "shuffle", "from": "3$", "to": "ab"},
        {"name": "replace", "from", "ab", "to", ".."},
        {"name": "shuffle", "inPlace": "30"},
        {"name": "shuffle", "inPlace", "zyu"},
        {"name": "shuffle", "inPlace", "xc"},
        {"name": "replace", "from": "zyu", "to": "+xx"},
        {"name": "weightedReplaceAll", "from": "w", "weights": {"w": 15, "t": 10, "l": 5}}
    ]
    "map": "
...................
.wwwwwwww.wwwwwwww.
.wxxxx.......xxxxw.
.wx3.z.ab.ba.z.3xw.
.wx$.xxxx+xxxx.$xw.
.wxyxu.......uxyxw.
.w..x..xXXXx..x..w.
.w..x..X000X..x..w.
....+..X000X..+....
.w..x..X000X..x..w.
.w..x..xXXXx..x..w.
.wxyxu.......uxyxw.
.wx$.xxxx+xxxx.$xw.
.wx3.z.ab.ba.z.3xw.
.wxxxx.......xxxxw.
.wwwwwwww.wwwwwwww.
..................."
}

JSON does have the big disadvantage that there's no convenient way to have comment lines -- they aren't valid JSON. We could potentially preprocess our data files to filter out comment lines, but then it becomes difficult to give a good error message to the user if there's a syntax problem in the file (since the json library would be operating on an input string, rather than a file; it could tell us the faulty record number but not the line number).

[Scatha]

Thanks clouded, these are high quality and there's a lot of content there! I enjoyed just reading through them and would love to see some in the game.

The only one I definitely don't like is the door vault -- and then only for Sil. It's very cute mechanically so would be perfect in some games, but the flavour is just a bit too strange.