Quest_builder.lua is yet another abstraction of the Daimonin quest system. It improves on quest_manager.lua in two main way: (1) it is easier to use for scripters; and (2) it is simple(r) to add new quests to existing NPCs.

Originally developed alongside the wonderful SENTInce it is in fact completely independent and works well with the current interface.

I now need it to be thoroughly tested so mapmakers are encouraged to use it and break it. It can be viewed and downloaded here: http://daimonin.svn.sourceforge.net/viewvc/daimonin/trunk/maps/lua/quest_builder.lua?view=markup

As it is in sourceforge trunk it is on the test server (actually it has been for months).

Documentation and an example NPC script (an enhanced Fanrir with two new quests and lots more to say) is available here: http://www.daimonin.com/pn.php?module=Daipedia&tag=UtilityScriptQuestBuilder

it was on mapwiz for a moment and now gone :/
just tried to use it and update deleted it. heh

The formatting of the documentation you refer to seems a bit messed up?  Its not too bad in Firefox, but completely unreadable in IE7.

Reading the documentation, one thing confuses me ... qb:Build() "Returns the total number of quests known".  In your exmple for Fanrir you define 5 quests, so the initial value of the local variable questnr would be set to 5.  But the rest of the script reads as if questnr 1 should be the initial value for questnr?  Or did I get this all horribly wrong?

I have to admit that I prefer the mechanism I proposed in my Crystal Cave's thread for multiple quests ... where I have a master script that simply adds the quests, checks which quest the player is on, and then "requires" the correct separate script that contains all of the topic handling for that quest.

This gives complete flexibility about which topics you have in each quest and means all the topics for a quest are completely independant of each other - so you can add another quest without having to go through every topic for the existing quests and adding in more "if questnr = x" statements.

I feel the readability is improved as when you read the individual quest scripts you are not confused by all the text that is relevant for other quests.  Imagine a mega-quest NPC who has a detailed 10 part quest with a decent amount of story telling going on at each stage - the "topic_quest()" function would be huge!

But hey - that's just my opinion, and I guess I can still use this approach but using the quest_builder functions instead of quest_manager.

@Grunt: It is meant to be gone from mapserv now. The test server will get it from SF trunk.


Fixed the docs. An errant == was interpreted as markup for a header tag. But the CSS is not perfect by any means. It now looks OK in FF. Other browsers?

Hm, that's probably misleading. IIRC (I wrote the docs and qb some time ago) it actually returns the number of the quest you are on or nil if you've done them all. I'll check in a bit -- Fixed


So Fanrir would have 6 scripts attached related to him? Hm, one problem. How would a later quest refer to an earlier one? But NP. Write the system.

I think that is necessary for the reason given above though. Also, the interplay between qb (or whatever) and tl is important and a bit tricksy. The text (what the NPC says and fitting it all into standard natural language topics) is probably the most labour-intensive but important part of writing quest scripts.

Hm, I shouldn't reply para by para. What I said above.

Nope - still broken in IE.  It all starts to go wrong with the first scrolling code box that qb:AddQuest() is defined in.

Yes - that makes more sense.

Yes, 6 scripts, but thats not really a problem as long as the script files are named sensibly.  Not sure what you mean here by 'refer to an earlier quest' ... do you mean in what the NPC says?  The topic_default() included in quest4.lua would say "ah - you've completed quest 3 ...".  Or do you mean something else?

I'm missing something here (my noob knowledge!) ... "standard natural language topics"?  I'm not familiar with those.  With my approach the interplay between qb and tl is simple - just as simple as writing a single quest in fact!  Which is why I like it

Hehe ...

Anyway, the quest that I've written for Crystal Caves uses this approach - take a look and see what you think.

Hm, my CSS must have overwritten the IE fix in the original. I remember it in comments. I'll have a look later.

About the 6 script, yes I meant something else but actually I'm not sure if it is a valid point. One script per quest would mean irrelevant data would not need to be loaded I guess, but whether it'd make maintenance/reading the script for anyone other than the author easier/harder I'm not sure. I'll look at your CC scripts and think on this later.

I meant eg, 'accept quest' to accept any quest rather than horrible constructs like 'accq1', 'accq2', etc. But again think about it a bit more, maybe this would still work across multiple scripts (if each quest script only defines quest-related data and all tl stuff is in the main script).

OK, looked at the scripts. I don't like it. Too many different files to handle conversation with one NPC. At the risk of a backlash from someone, this will be even more of a problem with SENTInce standard topics. For one thing, the reason for an NPC to talk won't just be to hand out quests, but the status of the player/those quests that he has will be relevant to those other topics.

Not sure I described that well, but what I'm trying to say is NPC talk scripts are complicated and there is a lot of intertwined topics and interrelated data. Separating into files per quest and/or per topic may seem nice for simple NPCs who only really talk about quests and only have two anyway, but very quickly becomes a spaghetti complex of requires and such for moderately complex NPCs.

That said YMMV (and clearly does). By judicious use of global variables you actually can separate a qb-using talk script in this way if you absolutely must.

But IMO the memory saved does not justify the complexity of the mechanisms to require the right subscript(s) or the problems in maintaining/following such multiscripts.

Also, what in thhe Tabernacle's name have you done with thos tl:AddTopic() calls? That is really unnecessarily complex...

There seems to be a bug in qb:AddQuestList(() -- will fix tomorrow. Fixed

Well.  Fair enough ... I don't like it, but in the interests of commonality between scripts I'll abandon my scheme.  I only had it for the Crystal Cave quest, so only 1 set of scripts to rewrite.

I'm not sure how your approach makes cross-npc interaction easier ... ?  Can you explain what you mean by that.

And how is this complicated:

(Yes I know there are one or two more lines used in my CC quest, and we don't have case-select available, but that's the principle.  Its not complex at all!)

Don't know what you mean by the AddTopic complexity - its only an 'if/then' set of loops that allows me to add the topics (and only those topics) that I want to respond to at each stage of the quest.  Your method of adding all the topics means that every function has to do a load of quest-status checking to make sure the player typed something they weren't supposed to - which is equally complex ...

I think you should also not have NPCs say things like "previous quest" - it should be a specific, not a generic, message - after all (in-game) the NPC isn't just a quest giver, but a real character with a problem, and then another problem, etc.

Overall, we both have the same number of ib:AddMsg commands - but you have quest-status-checking in every function and I have it just once, and you have tl-add-topic once, and I have it repeated for each quest.

Oh well, I'm not going to win this arguement, so I think the thing to do is for me to try to rewrite the ToB quest (it needs doing anyway) using your template for Fanrir and see how I get on.

Did I say that?I didn't mean that (I assume cross-NPC means one NPC to another). I mean we need to view all topics a given NPC knows about as de facto linked -- a fairly primitive example of giving an NPC a consistent knowledgebase. Putting different topics in different files and then only loading thos files which contain the specific topic which the player has triggered prevents this holistic approach.

Well that's not mentioning the Initialize and Execute functions (although these are not necessary if you just make some other variables not local).

No. Adding all topics in this way and then doing checks in the topic functions is necessary complexity. It guarantees that the player can always utter a common phrase and get some kind of sensible response (ie, more than Huh?). It also distributes this complexity in a sensible way -- topic functions are complex, the framework of the script is not -- which makes the script easier to maintain, expand, read, and understand.

I agree. But Fanrir is a special NPC as noted in the header comment -- he knows the player is playing a game, his quests are designed to introduce noobs to certain gameplay concepts.

And I'm actually not trying to have an argument, but the fact is that talking to NPCs is a pretty unsatisfactory and unpleasant experience ATM as the interface is used differently from one NPC to the next, there is no consistency about which triggers NPCs respond to, and so on. You wouldn't expect to read a book where every page was formatted differently. Well maybe 'Peter and Jane learn to count', but not an adult book.

When you look at the actual scripts you see where these problems come from. There is no consistency or organisation between scripts and this feeds through to the player and gives Dai an amateurish feel.

Hmmm ... some good answers ... I'm a bit happier about it now (of course, I still need to try it out).

Hehe - yes I know!  You are trying to improve the game ... and this is a healthy discussion around that subject ... which is all good IMO.

@smacky: I haven't really looked at your implementation of the QuestBuilder, but I have some superficial nitpicks:
- Why do you prefix parameter names with _ in all methods. I dislike it and believe that it reduces readability and degrades other use of "_xxx" (such as private functions and throwaway variables)
- I (personally) think your reference wiki page is a bit too hard to read. I did put quite a lot of time and effort into making the other lua class references consistent and readable, so I would love it if you followed my style ;-)
- Your usage example is _huge_. Please use a short example (it doesn't have to run) to show off the general idea, and then link to a complete script in the SVN.

Well I agree that the choice of _ was not the best as it is used extensively for other purposes. But what exactly do you mean by throwaway variables?

I do find it useful to readability to have parameters visually distinct from other variables.

Well I made it originally when we were testing out the new wiki and CSS, so it takes advantage of/overuses depending on your POV several of the features which pnWikka has and phpWiki did not. I did find the straight list of methods on the other pages somewhat dull and unfriendly though, which is why I've made them a bit fancier here.

That said, the important thing for a page such as this is that it is readable to all, so feel free to edit it. OTOH I have also somewhere around here ib, tl, and qm pages in the same style for SENTInce.

Agreed. But ATM there are no complete scripts in SVN. That is one thing I am working on so we have some (I'm probably going to piss everyone off now) good, well-commented, real world (real game) scripts in SVN. And yes I am aware there is some stuff in maps/dev/ but what I mean is like a fully functional Guild Hall for example.

Throwaway variables ... maybe as in where a function returns two values but you are only interested in the 2nd one:

_ , bar = foo()

Don't know?

exactly what I meant