Hi namelesswc,
the nice thing about flow fragments is that they are versatile. So instead of thinking if you should use the flow location or quest based, why not both?
A useful approach would be to put "group flow fragments" into the root flow. For example one for locations and one for quests. Now there is no thing as "group flow fragments" its just a convention. Because flow fragments don't have an inherent purpose.That way your quests are not bound to your locations.
It could also prove helpful to create specialized Templates for your different flow fragment types. For example one for quests and one for locations, you would assign those to all flow fragments inside those group nodes. And from here you can go many different routes. In your location template you could have properties for
InitialDialog(ReferenceSlot: Dialogue),
BackgroundMusic(ReferenceSlot: Asset),
CanBeEntered(bool) etc. Your quests template could contain properties for
IsQuestAvailable(Script: Condition),
IsCompleted(bool),
CompletedDialog(ReferenceSlot: Dialogue),
CheckCompletion(Script: Condition) etc. Any information you need about locations or quests can be stored here. You can also add GlobalVariables into the mix to track your active quest, or use a special entity to track your active quests.
The other great thing about using templates like that is, that you can easily ask for all quests inside unity using
GetAllOfType. Now at appropriate steps you could generate a list of "potential" available quests using the result of
GetAllOfType and trigger each
IsQuestAvailable property i mentioned earlier.
These are just some options to give you an idea to get you started. It very much depends on your use case and your game structure. But the key point is: If the flow and connecting nodes doesn't make much sense for that particular use case, you don't have to use it. And remember flow fragments don't have a specific use case, they are general purpose container use them for whatever you want, and don't be afraid to use them to split the flow into multiple smaller ones for different use cases.
It can be helpful to look at your articy:draft project and decide "What objects and structures inside articy:draft are hardcoded and part of the game design? And what objects are actual dynamic game content". So for example the Quests and Location group folders and the templates are part of our game design, those are hardcoded and can be considered given inside unity. Everything inside the group folders, we defined as dynamic game content, something we query at runtime and deal with in the way we defined via our hardcoded objects. I hope that makes sense
Hope that helps and if not, let me know!
Best regards
Nico