Quote: Original post by reapfyre
The only problem I have is figuring out which answers should be displayed in the conversation menu..
A player may have 50 Answers in his file, 10 are for a specific NPC who he's talking to right now.. How can I limit those 10 down to 3 or 4? Note that any new Answers he 'learns' from the NPC he should beable to say straight away.

So either in the Code or in the database I need to beable to pick 3 Answers the player can say, that aren't just randomly picked from the database, and that are somewhat intelligent answers..

This (for me) was a problem with Morrowind - that you ended up with a multiple choice list that contained far too many topics and then when you choose most of them the NPC would respond with a generic and uninteresting response.

Personally I've opted for using a variation on the standard dialogue tree model, but alternatively why not try setting a priority / level of importance for every answer or conversation topic. Then when you meet the NPC with a lot to say the most interesting topics are chosen ... and if the NPC has nothing to say you still have the more generic chatter. Only potential problem is that you would need to be careful to make sure that important information is not filtered out and not made available to the player (I imagine this could be a real problem if one NPC is very central to the game and has a lot of important topics to talk about).

Quote: Original post by Anonymous Poster
If tblQuest is a superset for a multi-stage quest, then shouldnt the
tblCharQuest have a reference to it (and thus to the sub-stages) and then the one to the particular substage...

The database needs to store each quest's status, whether completed or not. Having tblQuest as completed or not will only tell the game whether the entire quest has been completed.. I need to know each individual subquest completion status and tblQuest really only holds the name and description of the overall quest as a whole. This may be 1 row in tblQuestDetail, it may be 50+.

Quote: Original post by Michalson
"tbl" prefix?...
...comparing MySQL to VB's object naming prefixes is like comparing Charles Manson to Hitler. My soul crushing needs priorities.

Since I'm trying to explain in much detail and as simple as I can so that I can get some help from this forum, then yes I will use naming conventions so that when I make a reference to something, people know what Im refering to, it also helps me know what people are talking about when they make suggestions. They made Prefix's for a reason you know. And this is just a screenshot of the relationship diagram, it is not the live database, the database doesn't use prefix's.



Thank you all for your help.
Timkin you got that right, thats exactly the problem..
It does seem easiest to fix this problem in the interface itself.

Ive thought before that I could have 4 Answers the player can choose from.
-1 being a random answer picked from the npc->charanswer list.
-2 being fixed answers from the answer list.
-1 being an answer that was just 'unlocked' from an npc's phrase/conversation.

Do you think this will work? or do you think it just wouldn't allow for smooth transitions through conversations? I like both your ideas Timkin and Jon Alma.

The menu system for 'topics' should work fairly well, that wouldn't be too hard to add on either since there are some 'answers' that are 'unlocked' from an npc that are available to ask any npc, not just the npc who 'unlocked' it. Those cross-accessible answers could be the 'topics' for the menu system. Thus you could start the same topic with each npc, if that unlocked topic allows cross-npc conversations.

Quote: Original post by reapfyre
Ive thought before that I could have 4 Answers the player can choose from.
-1 being a random answer picked from the npc->charanswer list.
-2 being fixed answers from the answer list.
-1 being an answer that was just 'unlocked' from an npc's phrase/conversation.

What if the player could really do with the other answers on the charanswer/fixed-answer/unlocked answer lists rather than the ones you've randomly selected? (Not that you've explained what each of these lists are.)

I cannot see any way that this will not be a complete recipe for frustration on a player's part. Limited multiple choice is simply a poor match for unlimited topics.

Just give them all the unlocked topics. If you really need to keep the interface trimmed down then group them by some other criteria (generic vs. specific, or by quest, etc) and provide a top-level menu. Or hide all but the top-level topics at conversation start, and allow them to be unhidden by viewing other topics.

Quote: Original post by Kylotan
I cannot see any way that this will not be a complete recipe for frustration on a player's part. Limited multiple choice is simply a poor match for unlimited topics.

I disagree with this point. Personally, I'd be more frustrated by having to wade through a list of 20 responses trying to work out which ones were relevant to a single line of discussion that I wanted to follow, rather than being able to filter the maximal set of responses I could make based on the topic I choose to discuss. Furthermore, I'd rather look at a concise list of topics from which I can make a choice to direct the conversation, rather than try and steer the conversation from assorted responses that may not be applicable. Obviously though, this is a personal preference and I wouldn't expect everyone to agree with me.


Timkin

Perhaps I wasn't entirely clear. I did suggest grouping by topic to prevent the user from having to go through a flat list of 20 responses. But if there are potentially 20 pieces of information that the NPC can offer up, then I want access to all of them. If there's any filtering to be done, it is best done explicitly by the player. I don't want to have some arbitrary system picking out 4 responses which may or may not be of interest, and especially not if that is in any way random. A tree structure is a tried and tested way of achieving this and I'm having trouble seeing why the original poster can't use such a method, instead of trying to fit an arbitrary number of responses into some sort of dynamic multiple choice system.

Quote: Original post by Kylotan
Perhaps I wasn't entirely clear. I did suggest grouping by topic to prevent the user from having to go through a flat list of 20 responses. But if there are potentially 20 pieces of information that the NPC can offer up, then I want access to all of them. If there's any filtering to be done, it is best done explicitly by the player. I don't want to have some arbitrary system picking out 4 responses which may or may not be of interest, and especially not if that is in any way random. A tree structure is a tried and tested way of achieving this and I'm having trouble seeing why the original poster can't use such a method, instead of trying to fit an arbitrary number of responses into some sort of dynamic multiple choice system.

Okay, one of us has misunderstood the other... and I have no idea which way the finger is pointing (maybe at both of us) ;)... the suggestion I made is basically what you're saying here, but that the tree is rather a flat object embedded in the interface, consisting of a menu for selecting topic and a list for displaying reponses relative to this topic. I was distinctly suggesting moving away from using an 'AI' to choose the responses available to the player. The only difference from what you're saying is that you would have all responses on the screen at the same time, partitioned according to topic.

Timkin

So if I was to implement the tree view conversation topics.. how could u display that? Note that it is a web-based game, so collasping tree branches etc I could code but I also only use &#106avascript and DHTML, etc for the visual components, no downloading like flash etc.

Would the answer list in a tree view look something like this?


+ 'Work'
|_What do you do for work?
|_Do you have any work for me?

+ 'War'
|_How long has the war been going for?
|_When do you think it will end?

+ 'King'
|_Do you think the new King deserves the throne?
|_Who was the King's predeccessor?

+ 'Evil'
|_Why do you think the monsters have come now?
|_What has kept the peace so long in the kingdom?


And would the grouping menu's look like this?

Work War
King Evil
Quest Skills

I guess these are fine if you're asking the NPC all the questions..but what happens when the NPC asks the player a question? Does he select from the 'group' of answers which one to say? But shouldn't he only beable to say, Yes, No, Maybe?
In the tree view and grouping view all the answers 'are' available, surely you couldn't answer an NPC's question with another question because they're 'all' available..
How would you use this system properly? The NPC's never ask questions? Would it be the player initializes the conversation everytime and has complete control of how the conversation runs and the NPC is just a bot spewing back information as the player asks it?
Just a thought.

Quote: Original post by reapfyre
Would the answer list in a tree view look something like this?

(snip)

If you like... the interface is down to you. Really the problem is in deciding which options to present. I'd just show the top level, and when one is chosen, hide the others and reveal the relevant sub-topics.

Quote: I guess these are fine if you're asking the NPC all the questions..but what happens when the NPC asks the player a question?

This is the first time you've mentioned the prospect of an NPC asking a question, and potentially opens up new problems. However there doesn't necessarily have to be a difference if you keep things simple. It's still just about opening up responses, and whether they are statements or questions can be largely ignored.

Quote: In the tree view and grouping view all the answers 'are' available, surely you couldn't answer an NPC's question with another question because they're 'all' available..

This is why you allow for topics to be temporarily hidden. Any topic that requires a degree of sequential conversation will need to hide sibling topics when started and unhide them when finished.