Automatic quest state listener configuration

[ohheymatt]

Hi again!

For all of the quest-giving NPCs in my game, I want to enforce a standard configuration of quest indicator tracking
1. quest available: set to a yellow "!"
2. quest active but unfinished: set to a white "?"
3. quest available for turn-in (i.e. all quest entries are "success"): set to a yellow "?"
4. quest is complete: no indicator

I've gotten this to work with a combination of the Quest State Listener, Quest State Indicators, and a child Quest Indicator UI GameObject.

I would love to make the combination of these three components into a prefab that I can easily re-use for any NPC that has a quest. However, I'm not sure how since each Quest State Listener's "Quest State Indicator Levels" field needs to be manually set based on the entries of that specific quest instead of some kind of "all quest entries states = success"

What's the best way to get this functionality with the minimum amount of configuration through the component inspectors?

Thanks!

[Tony Li]

Hi,

QuestStateListener's methods are virtual. One solution would be to make a subclass of QuestStateListener and override the UpdateIndicator() method to do checks 1-4 you listed above.

[ohheymatt]

OK, I'll give that a go. Appreciate it!

Semi-related but kind of a unity question: do you know of a good way to hide serialized fields of a superclass? If I make a subclass to reduce the complexity of configuration, it would be nice to hide the extra stuff from the inspector. Obviously just a nice-to-have, but it's come up enough times that I'm curious!

[Tony Li]

Technically you could write a custom inspector that doesn't draw the fields that you want to hide. I'm not aware of any other way to hide serialized fields inherited from parent classes. But from an engineering standpoint I might recommend against that. Technically it's related to the Liskov Substitution Principle, which is part of SOLID design principles. When you hide something that a parent class has made public, you might not remember it in subclasses, and this could cause confusion -- for example, if you try to define the same thing, or even worse the same thing in a different way. When you're talking about Unity editor inspectors, it's a bit of a gray area since they already make a mess of what's supposed to be public vs. private.