Quest scripting for 2D RPG

Started by
3 comments, last by stein102 9 years, 10 months ago

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.

Advertisement

Scripting can be really useful, but it also might be overkill if all you're using it for is quests and cutscenes.

For any scripting language to interface with your game you need to write a binding interface that exposes the necessary elements of your game's java code and data types. This means you're probably implementing all the low-level functionality to carry out quest logic and cut-scene commands already in your java code -- not to specific quests, but as a utility to implementing specific quests. If you've already done that, defining quests or cutscenes is usually a pretty data-driven affair, for which XML is probably suitable. It's not hard to implement conditional logic, looping or quest variables through an XML interface either.

You might indeed have good reasons for adopting a scripting language, even if its just to achieve a less-verbose interface for creating quests and the like, but don't be confused that its necessary, or that adopting a scripting language will get you much of anything for free. If you have a working XML solution that can be extended by the same kinds of work you'd need to do anyways to expose your game internals to a scripting engine, and you're happy with XML, don't feel like you have to toss it aside to do things the "right" way.

throw table_exception("(? ???)? ? ???");

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.

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

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.

Sean Middleditch – Game Systems Engineer – Join my team!

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.

This topic is closed to new replies.

Advertisement