[crossfire] Quest management system proposal

[Andrew Fuchs]

On 6/9/06, Nicolas Weeger (Laposte) <nicolas.weeger at laposte.net> wrote:
> Hello.
>
> I'm feeling ambitious, so here's a quest management system proposal :)
> Of course, whether I (or someone) will actually implement it isn't yet sure
> ^_-
>
>
> 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.

Good idea to keep branches, and subquests (which you can't do after
the quest is over), etc.

> 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 revelant 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)

Can get a bit wierd if done just on one server.

> * 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 reuing existing one, to avoid making Yet Another
> Script Language. Though of course if we use Python the Python plugin would
> become mandatory.

Some sort of scripting language being mandatory on the server side
will probably encourage it's use by mapers.  It may be a good idea to
discuss implimenting LUA, since it has a smaller footprint, over using
the existing python plugin.

> * 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 :)

I like the idea of using it as a plugin.

> Heck, I may just start working on that soon if I'm feeling in a good mood :)
>
> I'll add that proposal to the wiki when it's back up, of course, so everyone
> can poke it ^_-

-- 
Andrew Fuchs