• 10
• 10
• 12
• 12
• 14

# Quest scripting for 2D RPG

This topic is 1407 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hey there, I've been working on a 2D RPG using Java and the LibGDX framework. I have a working quest system right now using XML for quest data but it seems to be fairly inflexible and I want to have more flexibility in my game. I've seen a lot about using scripting langauges such as lua or Python for quest scripting. So I have a few questions.

1) How should one scructure a script that describes a quest? For example say you need to collect 10 of some Item and return to a specific NPC to complete the quest. After completion you get some reward.

2) What are the pros/cons of using LuaJ/Jython? I'm not familiar with either language so I have no bias towards either of them.

3) How difficult would it be for a script to interact with a java object, call Java methods, etc?

Any suggestions or links to references would be greatly apprecated.

Thanks.

##### Share on other sites

Silly question, but if a libGDX project is compiled to Java, or Android *.apk, or html 5 Javascript, or robovm Java for iOS, then trying to call an embedded scripting language isn't going to work, right?  I would think trying to integrate a scripting language would be more trouble than it is worth.

Edited by Glass_Knife

##### Share on other sites
Typically you want to keep things as data-driven as possible. That is, use an actual scripting language very sparingly. A quest can be comprised of a series of steps, with each step having some requirements to complete, and then a reward. More complex games might need more intricacy here, but the gist remains the same. You might allow calling out to a script here or there for some pieces of this, but again, do so as rarely as possible.

The advantage of being data-driven is that you can build a nice GUI for churning out quests. You can also write tools that analyze quests to ensure they're completable, tell you an estimate of the difficulty/reward ratio, and so on. Roughly something like:

<quest name="Save the Place">
<stage id="get_key" name="Get the Key">
<requirements>
<talk npc="gatekeeper" />
</requirements>
<results>
<acquire item="red_key" />
<experience amount="100" />
</results>
</stage>
<stage id="enter" name="Enter the Place">
<prerequisite>
<complete stage="get_key" />
</prerequisite>
<requirements>
<arrive area="the_place" />
<unlock door="gate" />
</requirements>
<results>
<experience amount="100" />
</results>
</stage>
<stage id="cleanse" name="Kill the Dudes">
<prerequisite>
<complete stage="enter" />
</prerequisite>
<requirements>
<kill enemy="dude" number="10" area="the_place" />
</requirements>
<results>
<experience amount="500" />
</results>
</stage>
<stage name="Report Success">
<prerequisite>
<complete stage="cleanse" />
</prerequisite>
<requirements>
<talk npc="gatekeeper" />
</requirements>
<results>
<experience amount="2000" />
<acquire item="cool_sword" />
</results>
</stage>
</quest>
There'd likely be a bit more to it in a real example. You can allow scripting to offer new types of prerequisites, requirements, or results, but that script should be separated from the data; the script is an implementation detail of how quests work, not a fundemantal piece of logic to the quest itself. The data still defines the outline of what goes on.

You can allow stages to be optional, allow both OR and AND requirements (so you either need to do A or B, not both), integrate more tightly with your dialog system, control spawning/instancing, and so on.

The system allows both easy editing in a GUI, should you choose to build one, and naturally maps to in-game displays. The game might have some little quest marker on the screen (or in the game journal) that looks something like:

(X) Get the Key
(X) Enter the Place
( ) Kill the Dudes (4/10)
Stages could also set item id's as quest items (so an item is a quest item only while the quest is active), set a target location/enemy for directional indicators, etc. All data-driven with not a single extra line of code needing to be written for each quest.

##### Share on other sites

Typically you want to keep things as data-driven as possible. That is, use an actual scripting language very sparingly. A quest can be comprised of a series of steps, with each step having some requirements to complete, and then a reward. More complex games might need more intricacy here, but the gist remains the same. You might allow calling out to a script here or there for some pieces of this, but again, do so as rarely as possible.

The advantage of being data-driven is that you can build a nice GUI for churning out quests. You can also write tools that analyze quests to ensure they're completable, tell you an estimate of the difficulty/reward ratio, and so on. Roughly something like:

<quest name="Save the Place">
<stage id="get_key" name="Get the Key">
<requirements>
<talk npc="gatekeeper" />
</requirements>
<results>
<acquire item="red_key" />
<experience amount="100" />
</results>
</stage>
<stage id="enter" name="Enter the Place">
<prerequisite>
<complete stage="get_key" />
</prerequisite>
<requirements>
<arrive area="the_place" />
<unlock door="gate" />
</requirements>
<results>
<experience amount="100" />
</results>
</stage>
<stage id="cleanse" name="Kill the Dudes">
<prerequisite>
<complete stage="enter" />
</prerequisite>
<requirements>
<kill enemy="dude" number="10" area="the_place" />
</requirements>
<results>
<experience amount="500" />
</results>
</stage>
<stage name="Report Success">
<prerequisite>
<complete stage="cleanse" />
</prerequisite>
<requirements>
<talk npc="gatekeeper" />
</requirements>
<results>
<experience amount="2000" />
<acquire item="cool_sword" />
</results>
</stage>
</quest>
There'd likely be a bit more to it in a real example. You can allow scripting to offer new types of prerequisites, requirements, or results, but that script should be separated from the data; the script is an implementation detail of how quests work, not a fundemantal piece of logic to the quest itself. The data still defines the outline of what goes on.

You can allow stages to be optional, allow both OR and AND requirements (so you either need to do A or B, not both), integrate more tightly with your dialog system, control spawning/instancing, and so on.

The system allows both easy editing in a GUI, should you choose to build one, and naturally maps to in-game displays. The game might have some little quest marker on the screen (or in the game journal) that looks something like:

(X) Get the Key
(X) Enter the Place
( ) Kill the Dudes (4/10)
Stages could also set item id's as quest items (so an item is a quest item only while the quest is active), set a target location/enemy for directional indicators, etc. All data-driven with not a single extra line of code needing to be written for each quest.

Okay, I see what you're saying. I'll stick with XML in that case.

So what I could do after that is parse the XML and create an instance of Quest for each quest. Additionally I could create a list or even a stack of Stages that get added to the quest. Sound decent?

But yes, I was actually playing on building a GUI for editing the quests :)

Thanks for the suggestions.