Branching quest system

Question

I've started working in a quest system for my game, but I stumble in a zone where I have to many, if/else conditions to handle a quest, whether you have X and Y item in your inventory, whether you have already talk with a NPC, or whether some other quest stage is a given value and so on.

This end ups making the code very unclean, hard to fix and extend.

I'm wondering what's a good way to handle this.

I've read that keeping your quest as XML file is a good practice, but I've never worked with XML before(I know what they are, but I'm unfamiliar with how to properly make one)

I made a template quest to handle fetch/talk quests in a CSV file. Which looks something like this:

But I'm not that I'll end-up shooting my own foot with this custom system.

The branches of a quest can depend on items, previous quests, npc status, player status... So, what's a good way to deal with this?

---

EDIT:

This is not a duplicate of this question since the answers for this question are either using XML (which I said I don't have the know-how) or use multiple if/else conditions, which is my start problem.

Answer 1

One way of handling this could be to implement some form of graph system:

http://en.wikipedia.org/wiki/Graph_%28mathematics%29

Or as a state machine:

http://en.wikipedia.org/wiki/Finite-state_machine

In both cases you describe your quest states (stages) as nodes, and the edges/transitions as the actions that can be performed to move from one state to the next.

The example you provided would lend itself quite nicely to this setup (with a bit of modification).

By using something generic like a state machine allows you to reuse the same code for everything, but the only issue area is coming up with a way of tying in player actions/conversations trees. But if you also represent your item database as a spreadsheet/in xml it becomes a bit easier.

In this article there is an example of how Grim Fandango has it's first "quest" laid out: http://www.squidi.net/three/entry.php?id=158