Hi there,
If this is a system that will have non linear progression, linear gates and so on there would be much more needed.
However approach wise its fundamentally right direction you are.
1- I would recommend its own class, preferable a game instance subsystems as UQuestDirectorSubsystem, that can have additional modules and easier to talk with overarching systems in your game.
2-All these systems can call specific functions or events on your subsystem. Simply you can have an interacted function to call from your actors with reference and maybe some enums. Subsystem->CallObjectUpdate->Door(Interacted/Sleeping/Disabled)
3- Yes there will be many updates and events through your architecture. It can get complex in no time, like you would want to know what door opened with what item. You can have a struct to pass payloads to your subsytem for that or instigator to know if its player A or B for a multiplayer game, can be more. Use subsytem also an interface if you prefer with generic evens and functions. Actor reference and status, maybe payload.
However couple of things to mention. Interactions fundamentally is another system that can live encapsulated.
Ex: Door Interactions with Key doesn’t have to know quest state but you can require door to know quest state (as you described). If there is a valid key then door can open. —> Upon opening door can inform quest subsystem of the status change. —> When status changed of that quest in the subsyems couple of things can happen
A: Finish quest - > UI updates, experience etc.
B: Progress → New objective, UI updates etc.
After saying all of above
In your system;
Door → CanOpenFunction()
Function CanOpen(Player):
Subsystem = GetQuestDirectorSubsystem(UQuestDirectorSubsystem)
If Subsystem.CanDoorBeOpened(thisDoor) == false:
Return false
If Player.HasItem(RequiredKey) == false:
Return false
OpenDoor()
// I would recommend doing notify or call function after interaction turns success though not in door but interactions system however its below.
Subsystem.NotifyDoorOpened(thisDoor)
Return true
In that terms door checks key and quest status and UQuestDirectorSubsystem is the bookkeeper. However i would also recommend a data table for each quest for ease of access and designer friendly structures.
Also would be easier to track of your data tables as, current quests, current stage, completed quests, uncompleted, locked and unlocked quests etc. That would be crucial to save game system and general playability of player experience.
Hope it helps and let me know.