Stendhal Quest Coding - Part 2: Difference between revisions

Jump to navigation Jump to search
← Older edit
Content deleted Content added
imported>Hendrik Brummermann
imported>Kribbel
m replace old link
 
(94 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{Navigation for Stendhal Top}}
{{Navigation for Stendhal Top|Contributing}}
{{Navigation for Stendhal Contributors}}
{{Navigation for Stendhal Contributors}}
{{Stendhal Quests}}



{{Stendhal Quests}}


__TOC__
__TOC__



<div style="border: 3px solid green; background-color: #AFA; padding: 1em; margin-right: 20em">
This page is currently reworked. You can find the old content on the [[Talk:Stendhal Quest Coding|talk page]]
</div>


You may want to read the first part of the '''[[Stendhal Quest Coding]]''' tutorial first.
You may want to read the first part of the '''[[Stendhal Quest Coding]]''' tutorial first.
Line 15: Line 12:
If you have ideas for new quests or are interested in helping to refine quest ideas, please have a look at the [[Stendhal Quest Contribution|Quest Contributor's Guide]] or the [[Stendhal Quest Ideas]].
If you have ideas for new quests or are interested in helping to refine quest ideas, please have a look at the [[Stendhal Quest Contribution|Quest Contributor's Guide]] or the [[Stendhal Quest Ideas]].


== Teaching the NPC to ask the players whether they will do the quest ==
== Ask the players whether they will do the quest ==


Now we want Hayunn to ask the player whether he is going to help:
Now we want Hayunn to ask the player whether he is going to help:
Line 28: Line 25:


Fortunately there is a solution: The NPCs needs to remember the state of the conversation:
Fortunately there is a solution: The NPCs needs to remember the state of the conversation:

[[Image:npc simple.png]]
[[Image:npc simple.png]]


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 ATTENING 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).
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.
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.
Line 38: Line 36:
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.
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:
{{TODO|

* code
<source lang="java">
* point to ConverstationStates
public void prepareQuestStep() {
* View Transitions with Graphviz

}}
// 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);
}
</source>

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 [https://github.com/arianne/stendhal/blob/master/src/games/stendhal/server/entity/npc/ConversationStates.java 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 <code>ChatConditions</code> and <code>ChatActions</code>. A ChatCondition, if specified, must evaluate to <code>true</code> in order for the transition to be taken into account. Let's have a look at an easy example:

<source lang="java">
npc.add(ConversationStates.IDLE,
"hi",
new LevelLessThanCondition(6),
ConversationStates.IDLE,
"Oh sorry, you have way too little experience.",
null);
</source>

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.

<source lang="java">
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"));
</source>

There is a number of premade [http://stendhal.game-host.org/hudson/job/stendhal_HEAD/javadoc/games/stendhal/server/entity/npc/condition/package-summary.html ChatConditions] and [http://stendhal.game-host.org/hudson/job/stendhal_HEAD/javadoc/games/stendhal/server/entity/npc/action/package-summary.html 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 ==
== 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...
{{TODO|

* ChatAction
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:
* ChatCondition
<source lang="java">
}}
public static final String QUEST_SLOT = "beer_hayunn";
</source>

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:

<source lang="java">
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);

// ...
}
</source>

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:
== Rewarding the player ==


<source lang="java">
private void prepareBringingStep() {
SpeakerNPC npc = npcs.get("Hayunn Naratha");


// if the players says "beer" and owns one, we set the quest slot to "done".
{{TODO|
npc.add(
* MultiAction
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"));
}
</source>


Of course we need to add a call to <code>prepareBringingStep();</code> in <code>addToWorld</code>.
== Quest Documentation ==


== Third Part of this Tutorial ==
{{TODO|
* should be done much earlier usually
* content should be done earlier (see contributor's guide
}}


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 [[Stendhal Quest Coding - Part 3|the third part of this tutorial]].
== Further Reading ==


{{TODO|
}}
[[Category:Stendhal]]
[[Category:Stendhal]]
Retrieved from "https://meet.konsthol.eu/w/index.php?title=Stendhal_Quest_Coding_-_Part_2"