I and a couple of friends are having hard time thinking of a way to store the quests for our web-based RPG. We can't think of a pattern to store the quests, because each quest will be unique and can't be categorized. Should we hard-code the quests or there are other ways to acomplish this challenging task? Our language of choice is PHP and our database MySQL, if it matters.

I would imagine the individual components of your quest could be categorized: for example, talk to Bob, give item Foo to Bob, kill Steve...

You can store those as an enumerated value and simply make a "quest file" that lists the objectives of the quest piece by piece until you complete them.

When your user does something, figure out if that completes an objective, and if so, mark it off on that user's progress somehow. Then once all the objectives for that quest are done, announce the quest completed and give them an item or something.

Additional features of the objectives might be order, or minimum level, or something so you could enforce a certain order to the objectives.

Represent quests as a directed graph. Users actions move them along the edges from starting to ending node.


A - (Accept quest, abandon quest)
B - quest accepted (kill target - C, talk to target - D, kill quest giver - E)
C - Loot target, move to W, you win
D - If your charisma is > 20, you get the item - go to W, you win,
If your charisma is 0 - 10, try different aproach, go to B
If your charisma is < 0, target escapes - you fail, go to E
E - You have failed

This can be easily stored in any format. You store:
- Graph structure
- Node entry/exit events
- Action triggers
- Choices at each node
- Conditions
- Descriptive text

Action triggers will usually be bound to your game, the rest will be part of game engine.

By properly designing the graph, you can also check for completability of the quest (so you don't end up in dead-end), if you formalize your triggers/actions/conditions.

If entire graph is formalized, you can auto-generate quests as well (the quality may be lacking though).

In many professional games, quests are represented as state machines, with transitions driven by script. (This is similar to Antheus's graph approach)

Each node is a state:

STATE1. INITIAL STATE (player has not accepted quest)
STATE2. QUEST ALREADY COMPLETED
STATE3. QUEST LEVEL TOO LOW
STATE4. QUEST LEVEL TOO HIGH
STATE5. QUEST AVAILABLE
STATE6. QUEST ACCEPTED
STATE7. QUEST PART1 COMPLETE
STATE8. QUEST PART2 COMPLETE
STATE9. QUEST PART3 COMPLETE
STATE10. QUEST COMPLETE
STATE10. QUEST FAILED

Between nodes, you have transitions which run scripts assigned to them

STATE1 - STATE2 Transition: {Quest in completed list}
STATE1 - STATE3 Transition: {Player Level > Quest Max Level}
STATE1 - STATE4 Transition: {Player Level <

In many professional games, quests are represented as state machines, with transitions driven by script. (This is similar to Antheus's graph approach)

Each node is a state:

STATE1. INITIAL STATE (player has not accepted quest)
STATE2. QUEST ALREADY COMPLETED
STATE3. QUEST LEVEL TOO LOW
STATE4. QUEST LEVEL TOO HIGH
STATE5. QUEST AVAILABLE
STATE6. QUEST ACCEPTED
STATE7. QUEST PART1 COMPLETE
STATE8. QUEST PART2 COMPLETE
STATE9. QUEST PART3 COMPLETE
STATE10. QUEST COMPLETE
STATE10. QUEST FAILED

Between nodes, you have transitions which run scripts assigned to them



So the transitions and nodes together form a graph, the transitions coming out of the current node are all evaluated, if one is true, then it changes state to a different node, and the transition at that node is evaluated.

This data structure can be saved as 2 lists, 1 list of nodes, and one list of transitions.

You probably want to be able to execute code during a transition, or while in a node, and that could be added