Stendhal Quest Coding - Part 2
- |
Stendhal Quests
You may want to read the first part of the Stendhal Quest Coding tutorial first.
If you have ideas for new quests or are interested in helping to refine quest ideas, please have a look at the Quest Contributor's Guide or the Stendhal Quest Ideas.
Ask the players whether they will do the quest
Now we want Hayunn to ask the player whether he is going to help:
- quest: My mouth is dry, but I can't be seen to abandon this teaching room! Could you bring me some beer from the tavern?
- yes: Thanks! I'll be right here, waiting. And guarding, of course.
- no: Oh, well forget it then. I guess I'll just hope for it to start raining, and then stand with my mouth open.
As a little exercise you can code this part to check whether you understood the first part of this tutorial.
There is, however, a small problem with the current solution: There can only be one reply for "yes" and "no". So the NPC can only ask one single question in order to be able to process the answers.
Fortunately there is a solution: The NPCs needs to remember the state of the conversation:
Currently our NPC knows two states: IDLE for walking around and ATTENDING for talking to a player. You can change between states by talking to the NPC. So if the NPC is IDLE, it will accept "hi" and move on to the ATTENDING state. If you say "hi" again, nothing will happen because "hi" is unknown in this state. The NPC, however, will now reply to "job" and "help". You can end the conversation with "bye" which will cause the NPC to return to IDLE (and start walking around again).
So, lets return to our example. We want the NPC to reply to "yes" and "no" but only after the quest question was asked. So we add a third state called QUEST_OFFERED. When the player says "quest", the NPC goes to that state. On "yes" or "no" it returns to ATTENDING.
You may have noticed in the above diagram that there is something called "ANY". This is a special "state" which allows the triggers associated with the outgoing arrows to be triggered in any state. You should not use this except for "bye" which should always work.
Okay, enough theory for now, lets write some code:
public void prepareQuestStep() {
// get a reference to the Hayunn npc
SpeakerNPC npc = npcs.get("Hayunn Naratha");
// ...
// if the player asks for a quest, go to state QUEST_OFFERED
npc.add(ConversationStates.ATTENDING,
ConversationPhrases.QUEST_MESSAGES,
null,
ConversationStates.QUEST_OFFERED,
"My mouth is dry, but I can't be seen to abandon this teaching room! Could you bring me some beer from the tavern?",
null);
// in state QUEST_OFFERED, accept "yes" and go back to ATTENDING
npc.add(
ConversationStates.QUEST_OFFERED,
ConversationPhrases.YES_MESSAGES,
null,
ConversationStates.ATTENDING,
"Thanks! I'll be right here, waiting. And guarding, of course.",
null);
// in state QUEST_OFFERED, accept "no" and go back to ATTENDING
npc.add(
ConversationStates.QUEST_OFFERED,
ConversationPhrases.NO_MESSAGES,
null,
ConversationStates.ATTENDING,
"Oh, well forget it then. I guess I'll just hope for it to start raining, and then stand with my mouth open.",
null);
}
As you can see, we now have to use "add()" instead of "addReply()" and that method has a lot more parameters.
We have predefined a number of states in the class ConversationStates that you can and should use.
Graphical representation
There is one last thing that makes your life easier: If you are using Linux, have the graphviz package installed and you are an admin in game, you can select View Transitions in the right click menu of NPCs. This will generate an image of the current transition graph very similar to the images above.
Conditions And Actions
Hayunn now has a short term memory and that is cool for asking questions.
Before we have a look at long term memory, we make a little excursion to the topic of ChatConditions and ChatActions. A ChatCondition, if specified, must evaluate to true in order for the transition to be taken into account. Let's have a look at an easy example:
npc.add(ConversationStates.IDLE,
"hi",
new LevelLessThanCondition(6),
ConversationStates.IDLE,
"Oh sorry, you have way too little experience.",
null);
The NPC will refuse to talk to players who are below level 6.
A ChatAction is executed after a transition is taken. The following example opens the map of Semos city if the player asks for it.
npc.add(
ConversationStates.ATTENDING,
"map",
null,
ConversationStates.ATTENDING,
"1 Townhall, Tad lives here, 2 Library, 3 Bank, 4 Bakery, ...",
new ExamineChatAction("map-semos-city.png", "Semos City", "Map of Semos City"));
There is a number of premade ChatConditions and ChatActions. You can use them easily out of the box. Many of them require some parameters which are documented at the linked places. Of course you can write your own conditions and actions for special cases.
Teaching the NPC to remember the player
Okay, lets get back to the topic: Hayunn needs a long term memory in order to only accept one beer per player. After all he is on duty and a totally drunken teacher is no good...
The long term memory is called "quest slot". It is basically a hash table with one row per quest. You might remember that the following line in the template we added at the very beginning of this tutorial:
public static final String QUEST_SLOT = "beer_hayunn";
That's the name of the slot we are using. It has to be unique, but other than that, we can write anything we want in there. There are, however, two conventions that make things a lot easier: Multiple values are separated by an ";" without space. And the terms "done" and "rejected" are used to denote a complete or rejected quest. There are a number of predefined chat conditions and actions that work based on those conventions.
Having said that, let us make Hayunn check the quest state and reply accordingly:
public void prepareQuestStep() {
// get a reference to the Hayunn npc
SpeakerNPC npc = npcs.get("Hayunn Naratha");
// ...
// check that the player has not completed the quest, yet.
npc.add(ConversationStates.ATTENDING,
ConversationPhrases.QUEST_MESSAGES,
new QuestNotCompletedCondition(QUEST_SLOT),
ConversationStates.QUEST_OFFERED,
"My mouth is dry, but I can't be seen to abandon this teaching room! Could you bring me some #beer from the #tavern?",
null);
// send him away if he has completed the quest already.
npc.add(ConversationStates.ATTENDING,
ConversationPhrases.QUEST_MESSAGES,
new QuestCompletedCondition(QUEST_SLOT),
ConversationStates.ATTENDING,
"Thanks all the same, but I don't want to get too heavily into drinking; I'm still on duty, you know! I'll need my wits about me if a student shows up...",
null);
// ...
}
Note that if the quest is already completed, Hayunn stays in ATTENDING state.
The next step is to save that the quest was completed. We take a simple approach for the moment and only check that the player owns a beer:
private void prepareBringingStep() {
SpeakerNPC npc = npcs.get("Hayunn Naratha");
// if the players says "beer" and owns one, we set the quest slot to "done".
npc.add(
ConversationStates.ATTENDING,
"beer",
new PlayerHasItemWithHimCondition("beer"),
ConversationStates.ATTENDING,
"*glug glug* Ah! That hit the spot. Let me know if you need anything, ok?",
new SetQuestAction(QUEST_SLOT, "done"));
}
Of course we need to add a call to prepareBringingStep(); in addToWorld.
Third Part of this Tutorial
Congratulations if you made it this far. You are now able to process basic conditions and actions. And you can handle both short and long term memory. The third and last part of this tutorial will explain how you accept the quest item and reward the player. It describes some advanced techniques, too. Please make sure the steps on this page work before you continue to the third part of this tutorial.