How to represent quests in an RPG
Author
I am working on a simple tile-based rpg and I have no idea what would be a good way to store data about quests. How do I keep track of when one has been initiated, completed, etc. I am not wanting anything too slick. I just want to implement basic quest types. For example:
1. Retrieve a quest item and return it to someone.
2. Kill a boss of some kind
3. Reach a certain NPC.
4. Reach a certain map location.
5. Cast a spell at a certain map location.
6. etc
These type of things. Anyway any help would be appreciated. Thanks.
Marcus
I would think the best way to handle this would be to use a trigger system. When the player performs some action, say talking to a certain NPC that gives the player a quest, you could have a trigger attached to the NPC. When the player talks to the NPC you would check to see if the NPC has a trigger attached to him, if he does you could execute some code associated with that trigger (this is where C++ and object oriented programming comes in handy) that adds some info to a quest list and attaches new triggers to other NPCs, locations on the map, or mabey the death routine for a boss in some dungeon. When the player sets off the new trigger, You would know the quest is complete. Where you add the new trigger would determine what kind of quest you are working with.
I hope this helps.
I hope this helps.
Well, I guess the way I would do it would be to have a linked list of quests that are yet to be completed. When the player encounters a NPC who gives him a quest, that quest is added to the list. When the player completes the quest, either the quest node would be deleted or moved to another list (such as a completedQuest list, if you want to keep track).
As far as the specifics of the data in the list, you could have a void pointer (assuming C/C++), which would allow you to pass the "objective" (e.g. a pointer to the "boss" structure, or the NPC, or the coordinates of the map location, etc...). You also might have to add some sort of flag variable to determine the type of quest the user is going on.
To determine how the quest was completed, you could check after every time a monster is killed whether or not it was the boss. If your working for UPS (delivering an item), every time the player talks to that NPC, you could check to see if he is carrying the item.
This is just my thoughts on it, I''m sure there are plenty of people with more experience in RPG''s who might be able to give you a better way to do it.
Andy
As far as the specifics of the data in the list, you could have a void pointer (assuming C/C++), which would allow you to pass the "objective" (e.g. a pointer to the "boss" structure, or the NPC, or the coordinates of the map location, etc...). You also might have to add some sort of flag variable to determine the type of quest the user is going on.
To determine how the quest was completed, you could check after every time a monster is killed whether or not it was the boss. If your working for UPS (delivering an item), every time the player talks to that NPC, you could check to see if he is carrying the item.
This is just my thoughts on it, I''m sure there are plenty of people with more experience in RPG''s who might be able to give you a better way to do it.
Andy
First, a general tip when designing control algorithms and structures: Don''t think in terms of actual implementations, i.e. linked list or hash table or what have you. Think in terms of the general abstraction and how they should interact, i.e. containers or maps.
Having said that, there are a number of approaches you can take to solving this design problem.
Design method A (the Active Quest model):
Have a container of all possible quest. At some interval of time run through each quest and check to see if it has been accomplished.
Pros: Simple to code.
Cons: Slow as hell.
Of course, you can prioritize quests by % complete, length, etc. But this will still be pretty damn slow.
Method B (the uber-event model):
A more robust and elegant model would be based on the Observer pattern.
First, design the system such that every game object has a set of events it can fire. E.g., for an NPC these would be things like the NPC died, NPC fell off a cliff, etc. Now, every time a game object is instantiated, register the events it can fire, along with the object itself, with a globally accessible registry.
Now, whenever you want to be notified of a particular event, e.g. a player wins a particular battle, a boss kicks the player''s ass, etc., register a callback object with the registry that will fire when that particular event has occurred.
Under this model, quests are a series of actions the game takes in response to particular events that are fired due to player action.
I like this model, but that''s because I''m an object freak.
MSN
Having said that, there are a number of approaches you can take to solving this design problem.
Design method A (the Active Quest model):
Have a container of all possible quest. At some interval of time run through each quest and check to see if it has been accomplished.
Pros: Simple to code.
Cons: Slow as hell.
Of course, you can prioritize quests by % complete, length, etc. But this will still be pretty damn slow.
Method B (the uber-event model):
A more robust and elegant model would be based on the Observer pattern.
First, design the system such that every game object has a set of events it can fire. E.g., for an NPC these would be things like the NPC died, NPC fell off a cliff, etc. Now, every time a game object is instantiated, register the events it can fire, along with the object itself, with a globally accessible registry.
Now, whenever you want to be notified of a particular event, e.g. a player wins a particular battle, a boss kicks the player''s ass, etc., register a callback object with the registry that will fire when that particular event has occurred.
Under this model, quests are a series of actions the game takes in response to particular events that are fired due to player action.
I like this model, but that''s because I''m an object freak.
MSN
In response to the original question, assuming an event model:
1. Retrieve a quest item and return it to someone.
Easy: have the special someone send off an event when s/he receives the quest item.
2. Kill a boss of some kind
Easy: have the boss send off an event when it dies.
3. Reach a certain NPC.
Medium: depends on when you want the event to fire. When the NPC sees the PC? When the NPC talks to the PC? Either way, just send off the event when particular criteria have been established. (This is a job for the designer.)
4. Reach a certain map location.
Easy: Register the map location to send out events whenever anything enters or leaves.
5. Cast a spell at a certain map location.
Easy or difficult, depending on how much of a performance freak you are: Easy way: set a trigger to fire when both a spell has been cast and a map location is the current location. However, the trigger will be notified whenever the spell is cast, regardless if location has been reached or not. This shouldn''t be a problem, but if it is, well, it''s left as an exercise to the reader to optimize performance
MSN
1. Retrieve a quest item and return it to someone.
Easy: have the special someone send off an event when s/he receives the quest item.
2. Kill a boss of some kind
Easy: have the boss send off an event when it dies.
3. Reach a certain NPC.
Medium: depends on when you want the event to fire. When the NPC sees the PC? When the NPC talks to the PC? Either way, just send off the event when particular criteria have been established. (This is a job for the designer.)
4. Reach a certain map location.
Easy: Register the map location to send out events whenever anything enters or leaves.
5. Cast a spell at a certain map location.
Easy or difficult, depending on how much of a performance freak you are: Easy way: set a trigger to fire when both a spell has been cast and a map location is the current location. However, the trigger will be notified whenever the spell is cast, regardless if location has been reached or not. This shouldn''t be a problem, but if it is, well, it''s left as an exercise to the reader to optimize performance
MSN
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
