Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remote dungeons type selection with fallbacks #2682

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

petchema
Copy link
Collaborator

@petchema petchema commented Aug 4, 2024

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:

   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 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.

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 petchema added enhancement A new feature or an improvement to an existing one. wip Work in progress labels Aug 4, 2024
@KABoissonneault
Copy link
Collaborator

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.
Actually, is the exception handled by DFU? Does it catch it then throw the "I gave the job to some sellsword" message? I think I'd be okay with the change if those errors are handled gracefully by DFU. I assume those errors only happen in a few regions, anyway

@petchema
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement A new feature or an improvement to an existing one. wip Work in progress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants