Or, how to make players do things in your game In this article I would like to share my experience building quest / tutorial systems for simulation games. It will consist of a theoretical and slightly more practical part based on developing quests with ECS (and reactive systems). Without further ado let’s start with the theoretical part. In games, quests are tasks, which player can accomplish in order to get further in the game and receive some kind of a reward. Tutorials can be seen as mandatory quests. A quest can contain a list of single tasks, but for simplicity I would like to define, that there is only one task per quest. Tasks are normally defined by game designers and are described through unlocking requirement, goals or completion requirements and rewards. In some cases it is good to provide task cancelation requirements. But before I go in depth on the ingredients of different requirements, let me first list all possible states of a task: — the task did not met the unlocking requirement yet pending — the unlocking requirements are met, but it is not in progress yet, maybe because of the limit of possible tasks in progress unlocked — the task was unlocked and shown to the player. It might be useful to have a sub-state, or a separate state for task. This symbols that the task is technically in progress, but player did not read the objections yet. I did not give it a separate state because it is UI specific in progress new — task was in progress and player did everything necessary to complete it. Now it is time to collect the reward. If there is no reward the task might directly switch to the next state. There are also systems where quests autocomplete completed — task was completed and user collected the reward done — this state is important if you want a quest to disappear. It’s particularly useful, if you introduce a new quests which player, who advanced beyond a certain threshold, shall not see canceled Now it is time to speak about different requirements. Unlocking Requirements Those are mainly based on game state / player progress. The simplest requirement is level or XP, but it is also very common to chain unlocking of the quest to a resource or a certain interaction. Say you want to teach a player to do crafting. When a player accumulates the right resources, we should unlock a quest where the player needs to use those resources for crafting. Same can apply to building, upgrading, training etc… Even using some distant, or just unlocked parts of the UI may be designed as a quest, with unlocking requirements of this UI element appearing. Another unlocking requirement which I find very useful is completion of another task. Task A unlocks only when task B and C are done. This way we control the flow of the quests, linearising the order quests are presented in. Cancelation Requirements As mentioned in the state description, it is very important to avoid some basic quests when the player is too advanced. If you introduce a quest for beginners you will set unlocking requirements in a way that advanced player will also met. However you don’t want advanced players to do basic tasks. canceled In my opinion the simplest thing is to couple cancelation to an XP of some sort, or on a completion of another task. Completion Requirements There are mainly two requirement categories for completion: Game state based Ad-hoc actions For example we are building a farming game and we have a quest based on apples. In category we define that the quest is completed, when the player have 2000 apples. If apples is a consumable resource the player would have to stop consuming it and keep harvesting apples till s/he has 2000 of it. Game state based In the category, we would define that player should harvest 2000 apples after the task moved to state. This way we do not impose any consumption restriction on the player and don’t care about previous achievements. Btw. quests with completion requirements can be auto-completed. Player might already reached the state needed for completion. However the based, always needs to be worked on. Ad-hoc actions “in progress” Game state based Ad-hoc actions Rewards A task/quest without reward is a little bit disappointing, specially if a quest involves some grinding. The simplest solution is to give players XP, but sometimes completion of a quest can be used to give a player some rare items, or random GATCHA. As mentioned before quests are defined by game designers, they are tools to steer players in to direction. However there is only so much stuff a game designer can come up with. If your quest system is well-formed, you might try to procedurally generate them. From my experience, this is actually one of the last tasks a game production team gets to do before automation mode. desirable How do I implement a quest system with ECS In my article I argue that data can be divided into three categories: Games Data and Entitas Configuration Game State Runtime Data In case of quests, we need to use all three of those categories. The definition of the quest is stored as a configuration. , and quests are stored as game state. In progress Done canceled At game initialisation, we would go through the configuration and create a set of and quests, according to quests already persisted in the game state. We also check if we can store new quests as . “pending” “in progress” canceled At runtime we need a set of reactive systems, which will monitor the relevant parts of the game state and transform quests to and if possible to . Quests based on , will have components storing the progress. pending unlocked in progress ad-hoc actions We need another set of reactive systems, which monitor the game state and user interactions in order complete a quest, or at least change quest progress in case of . ad-hoc actions When a quest moves to , it will be persisted in the game state. done This is basically the magic sauce. The details can become a bit more involved, but in my opinion, ECS is a very quest friendly architecture. Specifically if you are following it strictly and turn every player event to a component. BTW. writing reactive systems for procedural generated quests is not a rocket science.

Flow

Chain

Too Long; Didn't Read

Discover Saakuru: Web3 Mass-Adoption with 0-FEES

Building a Quest System

Too Long; Didn't Read

Coins Mentioned

Maxim Zaks

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Building a Quest System

Too Long; Didn't Read

Coins Mentioned

Maxim Zaks

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES