Adding a quest system into your game helps to add a lot of depth and meaning into the daily grind of tasks that users perform.
Quest systems also help to provide guidance through you game elements. They give your users a sense of accomplishment as they achieve various goals.
As you implement your quest system, there are various elements to consider in order to implement a successful system.
Keeping Quests Relevant
Quests need to be relevant to the user and their particular stage in the game. One of the simplest ways to destroy a newly implemented quest system is to introduce tasks to your users that don't apply to them.
Let's look at an example. If you introduce a question that requires a certain item or action that is not yet available to the user until a higher level, that quest is now useless to the user. If the user has a large list of useless and invaluable quests, they will be unlikely to pay much attention to the system as a whole.
The same applies if a low level quest is given to a user at a high level. If you introduce a task that requires a user to return to a previous location or level, they may not see the value in it and may want to skip the task in question.
Quests for Already Completed Tasks
As a user, a major annoyance for myself is when I have spent time in a game completing basic actions only to find that I am now being introduced with a quest that requires me to complete an action I’ve already done. This is particularly annoying when that task or item may involve spending a large amount of time or in-game currency. The way to get around this is in the engineering and design of the system.
From the engineering perspective the hook to register the achievement is in the code regardless of what level the user is currently playing at. The catch is that the design of the framework needs to account for quests that are not yet available and store a temporary “completed” status for these actions. That way when the quest becomes available, they completed status can then be redeemed.
Alternatively, the quest hook that evaluates completed status may need to look at user data to see if a newly introduced quest may have already been accomplished. In some cases this data may not be readily available, and you may need to decide how best to get this info.
Pre-Requisite Quests
Some quest systems have the ability to unlock other quests once a certain quest is completed. This type of system is particularly useful when presenting a character or player storyline and walking the player through different stages.
This type of system is accomplished by tracking which quests have been completed. Additional quests unlock, once a designated quest is marked as completed.
There is a risk to this approach, and that is the risk of creating an unintentional block in the user progressing. This will happen if you have quests that they user either (a) can't complete or (b) looses interest in completing.
A user may not be able to complete a quest if it is considered too high value or too high costs. meaning, the user may not have the required in-game items or currency to complete the quest.
In addition, if the quest does not provide valuable enough rewards for completion, the user may simply loose focus or interest. Quests need to provide a reward that presents the user with a value for their spent efforts.
Quest Overload
Amongst game designers there are a lot of different opinions on how many quests should be active for a user at any given time. Some designers even have some valuable stats to back up their positions. What we have seen however is that it varies per game.
This variance is due to the differences in what an average play session looks like. Games that have shorter play sessions tend to benefit from not having as many simultaneous quests. Having too many quests at once makes the user feel like they are inundated and they loose focus. With their focus lost they do not progress in the game and ultimately get distracted and leave.
On the opposite side however, if your game has a longer average play session, your game might benefit from having more tasks available to its users. These additional tasks can help keep the users occupied and provide lots of opportunities for the user to be actively engaged in the game.
Another critical piece of this equation is in the UI and UX of the quest system. If your game has a very cluttered UI, then you may be restricted on how many additional elements you can add to the users view.
When determining the right number of quests to handle, our advice is to run stats on your own personal games. Run an experiment with lots of quests and fewer quests and analyze the difference in engagement experienced in both approaches.
Worthless Quests
Using a quest system can be a great way to introduce basic game play elements to your users. Many games take advantage of this route to show users how to change the game to full screen or how to adjust the volume and so forth. While these tasks are valuable, we caution against having tasks that seem like busy work are do not provide a valuable game story line. This is especially true with your higher end users.
Let’s make up an example. If we have an invest and express style game, let’s assume we are decorating and building up a virtual fish tank. At lower levels it would make a lot of sense to have tasks and quests that teach users how to move the objects within the tank. However if you present an endless gauntlet of tasks to your higher level players of “move 1 decoration to the left” and “rotate 1 decoration”, you users will quickly loose focus in your game. This is because there is no game story line present in these tasks. To the users they are simply tasks - and what fun is that to redeem?
