I considered this, but there are still issues. Stairs would have to be on both the upper and lower designer's levels to fit. If a teleporter was above or below, the stairs would have to be replaced with teleporters. If you consider 4 cases of tele above, tele below; stairs above, tele below; tele above, stairs below, and stairs above stairs below:Ancylus wrote:As I noted, I would prefer stairs because I think going down them feels more like progress than stepping into a teleporter. If the only issue with them is the limits on the starting and ending points, and you're willing to use teleporters anyway, you could just port the party from the first room to the actual start of the level and from exit to the last room (and vice versa). All you'd need to do is reserve room for the stairwell at the right location, and 3x5 tiles should suffice for that.
All that said, if stairs are deemed too troublesome, I think I can live with using teleporters.
- Only the T/T case has the pros of teleporters, cons of stairs.
- Only the S/S case has the pros of stairs, cons of teleporters.
- Both T/S and S/T cases have the cons of both.
Specifically the "corner cases" arise when:Ancylus wrote:I'm very glad contributors won't need to manually name every single pillar and torch holder. The question is, how well does your system work with names used in connectors and scripts? At the very least I'm pretty sure it can't replace names parsed together from multiple components within the scripts. If/when it can't replace everything, there has to be a way to leave some names as they are: replace only names with conflicts, don't replace names beginning with designer's name, or something else along those lines. Or only use it for levels where it works fine and require complete manual naming for the rest.
- Strings look like ID's, but are not. I think this case is rare, and easily avoided with a find-all and skim-through before a find-replace. Backups before and after would be a must, so it shouldn't be a problem.
- As you said, names parsed from multiple components when the underscore and number are not adjacent in the script, which is likely for counting variables parsed into strings and concatenated. This is the toughest case and may need some private message exchanges with the original author to resolve. But I figured it's better to make it simple for the majority, than a bit more work for the passionate.
It'd be best to add a note about this issue so people would know to avoid it.
You caught me red-handed with something I overlooked here! So the puzzle tier would have to be based on itemization level. Perhaps the tier would be based on something like the median SL out of weapons provided on that level? I think that would be more accurate than basing it on armor provided, or items in general. And then XP limits would apply based on that tier.Ancylus wrote:I was actually planning on giving some experience as reward for solving the puzzles. The amount is of course easily adjustable to whatever suits the dungeon. Even without quest XP, puzzle levels really need to be assigned a place in the dungeon before their final versions are submitted so that itemization can be tuned to fit.
I do want to make a point that XP limits are only upper-bound. You could easily have 7 submissions in the same tier as long as there is still room for XP.
So, do you think median weapon SL is the best way to rate a "typical dungeon level" by item content? I may have to add something like this to my Custom Dungeon Analyzer...