(copy of a mail sent to CF — Ryo Saeba 2006/06/10 07:58)
Quests should be finite state automates. Meaning different states, with transitions between states, with conditions for those transitions, etc. Each state would specify special behaviour for NPCs, texts so the player knows the quest status and what to do (or at least some hints). Also there would be the rewards for completing that state, everything needed.
Transitions should describe what the player should do to actually change states.
My idea is to have quest files. Each quest would be one file, describing all states, transitions, including all information on what NPC’s behaviour to change, rewards, and so on.
If required, a quest file could be accompanied by some special maps, archetypes, anything specific.
The quest engine would, at start time, read those files, and process them. It would then, at map loading time, add relevant hooks to NPCs, or track global events (for instance follow player movement to know if they do what is required to complete a task). It would also keep, for each player, quest status, and such.
Advantages I see:
quest’s information is in one file, it’s easy to see globally how it works, versus today’s dispatched in maps, making it hard to look at, and check whether it’s broken or not
as a correlary, adding/turning off a quest means moving one file (or a directory)
it wouldn’t not rely on the hacks i did for the first basic quest system. I don’t really like’em anyway :)
we can think of DM commands to look at quests, know what quest a player did, reset quest status. Maybe even dynamically alter quests! *g*
we can add a quest editor, probably included in the map one :)
Drawbacks, opened questions:
one could change a map without updating a quest, thus it could be become broken - server should try to handle that graciously, and report it in any case
to have a really powerful quest system, and fun transitions (from bashing a specific monster to having 3 players do a special dance at a certain time), the conditions / transitions will require a full scripting language. So either reuse an existing one (Python, maybe? Or LUA? Or anything else?), or make our own - I’d favor reusing existing one, to avoid making Yet Another Script Language. Though of course if we use Python the Python plugin would become mandatory.
this quest system could be done either at server’s core level, or as a plugin. Last option would require some changes in plugin architecture (basically move plugin handling from server part to common lib part, to add hooks at a basic level. Also add interplugin communication).
tracking player behaviour could be resource intensive - that will need testing and addressing if required :)
