Data-driven workflow for inheritance-based quest system

I have a complete quest/mission system that works great, in which objectives are all implemented via inheritance- there's some BaseObjective class with a virtual bool IsCompleted method, so adding new categories of objectives is as simple as creating subclasses for each objective type- KillObjective maintains a list of enums identifying the type of enemy that needs to be hunted, PickupItem has an int key identifying the item the player needs to find, and so forth.

Where I'm running into trouble is building a reasonable content creation workflow for non-programmers to generate content for my system. I already have a node-based editor window that lets writers create and connect quest nodes, but the type and amount of information different Objective subclasses need is so variable that I'm not sure how I can translate that into a generic workflow. Right now, I'm doing it all through string parsing- in our editor, the Objective is just a single string that starts with the objective type, and the remaining tokens represent the data that objective needs, so it ends up reading something like 'KillObjective GoblinMinion 10' or 'FindItemObjective HauntedPumpkin'.

That works, but it's kind of taking the worst of both worlds: content creators will need to constantly refer to a syntax cheat sheet, and programmers need to worry about parsing and sanitizing the strings, and making sure they contain the right information. So is there a obviously better way to go about this? I've thought about making a custom property drawer with a dropdown QuestType enum that populates the rest of its inspector based on what quest type is selected, so content creators are only ever working out of dropdowns instead of text fields, and that seems a little better, but it's still kind of a pain in the rear end for writers. Is there anything I'm missing that could make this more user-friendly without compromising our ability to QA and debug the resulting quests?

 

What if the "FindItemObjective" and "HauntedPumpkin" tokens were ScriptableObject assets? Then your writers could specify objectives by plugging together tokens.

 

Thanks for the suggestion! We ended up using a combination of tokens and dropdowns, it's still a bit clunky, but it completely alleviates our content creators from requiring programming knowledge, which was the whole point