Jump to content
  • Advertisement
Sign in to follow this  
Boris Filipov

Implementing different types of quests in an RPG.

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
Represent quests as a directed graph. Users actions move them along the edges from starting to ending node.



+-> C -+
/ |
A -> B --> D -+-> W
\<---+
\ V
\> E -> X


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).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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 <

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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 < Quest Min Level}
STATE1 - STATE5 Transition: {Player Level Within Quest Level range}
STATE5 - STATE6 Transition: {Quest in player's quest list}
STATE6 - STATE7 Transition: {Head of Bob in player's inventory}
STATE7 - STATE8 Transition: {Player has spoken to hermit}
STATE8 - STATE9 Transition: {Player killed Joe}
STATE9 - STATE10 Transition: {Player Speaking to questmaster}
STATE6 - STATE11 Transition: {Player Dead}
STATE7 - STATE11 Transition: {Player Dead}
STATE8 - STATE11 Transition: {Player Dead}
STATE9 - STATE11 Transition: {Player Dead}
STATE11 - STATE1 Transition: {}



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











Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!