Remote dungeons type selection with fallbacks#2682
Conversation
Currently, for a dungeon required for a quest, a quest writer can either pick a dungeon type, or just any random dungeon. If a dungeon type is specified but no dungeon of that type can be found, the engine picks a random dungeon instead. That fallback means sometimes the quest writer intentions are not followed, including some very bad cases in my opinion (reward map for a rare dungeon type that can be replaced by a map for a random dungeon). So this PR removes the automatic fallback to "any dungeon". On the other hand, it introduces the possibility to provide more than one target dungeon type, as a list: Place _someplace_ remote dungeonA,dungeonB,..,dungeonC The engine will pick in priority dungeons of type dungeonA, then dungeonB, etc, enlarging the pool of dungeons to select from until it reaches the new setting DungeonsPoolSizeTarget (default 3), or no more fallback types have been specified. Of course, "dungeon" can be specified as a last fallback type to get the equivalent of current Daggerfall Unity for some place. DungeonsPoolSizeTarget=0 will totally disable the fallback mechanism DungeonsPoolSizeTarget=999 (or large values in general) will take all fallback dungeons into consideration no matter what, if player prefers randomization over quests consistency. I also edited existing quests to benefit from this feature, but did not spend a lot of time carefully picking the best set of dungeon types for each one, so there's more likely room for improvement.
petchema
added
enhancement
|
I admit I'm not confident in this change. While I appreciate that default quests were adjusted to have more explicit fallbacks, I'm most concerned by mods. While you're right that the "any" fallback can break quest narrative or logic, the alternative is more exceptions thrown from currently "working" mods. |
|
Yes, the way the quest engine works, if it cannot instantiate all the randomized resources of a quest (persons, places,...) the quest is aborted with "gave the job to a spellsword"-type message |
Instead of adding "...,dungeon" at the end of acceptable dungeon types to get the classic DFU behavior (fallback to any type), add "... only" after acceptable dungeon types to prevent picking a random dungeon if none, or not enough, acceptable dungeons have been found.
Delay testing if alternateDungeonTypeIndices is null so that fallback to picking any dungeon (in the absence of the "only" keyword) still works
As mentionned in the quest text
|
I modified the syntax so that unmodified quests (say, in mods) stay handled the classic DFU way, with "any dungeon" as a fallback. Instead of having to add "...,dungeon" at the end of dungeon types as an explicit fallback, it's now the default. If you don't want that behavior, and be strict about what dungeon types must be used, you have to add "... only" after the list of dungeon types instead. Examples:
|
Crypt makes sense for a mummy, but is not mentionned in the quest, so let's make it just a hint
KABoissonneault
left a comment
KABoissonneault
left a comment
There was a problem hiding this comment.
On the code side, the PR looks good. I would prefer having some quest designer feedback for all the dungeon changes. Some have a second fallback based on the theme of the quest I assume, some use "only" and others don't. Seems fairly subjective which ones are strict and which ones aren't.
It could probably use some more longterm playtest.
|
I add fallbacks based on list of enemies (since that's the main visible impact of dungeon types today), trying to find closest matches to the existing quest dungeon type, but I agree that it could benefit from more scrutiny. Same for adding (or not) "... only" to a quest, is the dungeon type explicitly mentioned in the quest text? Or does it make sense based on quest itself? Are there good reasons to enforce a dungeon type? (say, "Fighters Lich" quest that can reward you 50% of the time with the map of the relatively rare Dragons Den dungeon) |
2 participants
Currently, for a dungeon required for a quest, a quest writer can either pick a dungeon type, or just any random dungeon. If a dungeon type is specified but no dungeon of that type can be found in the current region, the engine picks a random dungeon instead.
That fallback means sometimes the quest writer intentions are not followed, including some very bad cases in my opinion (reward map for a rare dungeon type that can be replaced by a map for a random dungeon).
So this PR removes the automatic fallback to "any dungeon". On the other hand, it introduces the possibility to provide more than one target dungeon type, as a list:
The engine will pick in priority dungeons of type dungeonA, then dungeonB, etc, enlarging the pool of dungeons to select from until it reaches the new setting DungeonsPoolSizeTarget (default 3), or no more fallback types have been specified.
Of course, "dungeon" can be specified as a last fallback type to get the equivalent of current Daggerfall Unity behavior for some place.
DungeonsPoolSizeTarget=0 will totally disable the fallback mechanism
DungeonsPoolSizeTarget=999 (or large values in general) will take all fallback dungeons into consideration no matter what, if player prefers randomization over quests consistency.
I also edited existing quests to benefit from this feature, but did not spend a lot of time carefully picking the best set of dungeon types for each one, so there's more likely room for improvement.