Proficient in crafting and implementing logical aspects of quests to convey narratives without divulging specific details
In The Sandbox, lands take a more game-oriented approach compared to other metaverses. Consequently, our goal is to craft a narrative and convey it to the player through the different quests we design for the land. Please note that this article only focuses on the logical aspects of quest creation, omitting all narrative details.
In this article we will delve into the quest system, understanding how to navigate it and exploring the types of quests available for creating a quest flowchart in our lands.
The Sandbox Game Maker v0.8.10
The initial step in crafting quests for The Sandbox is to create a flowchart outlining their sequence and associated conditions. We will employ Miró for this purpose.
A white dot serves as the starting point, while a black node means the end of the experience.To represent different player actions, we will use rounded-corner squares.
Each quest must be given a title and placed to the right of the action that initiates it, along with a connection to the objective that marks its completion.To tell the difference between these connections from the ones linking actions, we will use dotted lines with different colors.
Moreover, quest title boxes should have a different color. In the case of different action threads, each box belonging to a specific thread should be clearly recognizable from the others through its unique color.
Additionally, we have the option to cover groups of quests that occur in the same area within a square. In the top-left corner of this square, we can include text that specifies the location where this quests take place. This feature proves valuable for maintaining a balance in the number of quests per location and for tracking the player’s progress throughout the land.
Once we have outlined all the quests required for the land, we can proceed to The Sandbox Game Maker and initiate the quest creation process from scratch, using our flowchart as a reference.
To create a quest, we need to access the Rules panel, which is situated on the top bar of the interface. Within the Rules panel, there are four different vertical subdivisions: “Welcoming Players”, “Quests”, “Victory”, and “Defeat”.
To begin, we need to enable the “Quest” tab by clicking on the slider located next to the “Quest” text. Once activated, we can add our first quest by clicking the “Add Quest” button. In this step, we can provide a title for our quest up to 20 characters in length, and a concise description (restricted to 300 characters).
In this panel, we need to select our “Unlock and Launch” conditions, specify the type of quest we intend to create, define our completion condition and outline the post-completion actions.
Quest message flow
Certainly, let’s break down how these messages interact with each other and the impact they have on the player’s experience. We will go step by step, explaining what each element accomplishes and how they help maintain encapsulated quests.
What is encapsulation? Encapsulation (in programming) refers to the grouping of data, concealing it from other parts of the same program to prevent interference during operation. It is employed to both restrict access to the data and facilitate operations on it.
This message serves to restrict access to the quest, essentially placing it behind a barrier. A quest may be automatically unlocked if it’s intended to be available from the beginning. However, if it’s not meant to be accessible initially, it needs to be locked using a message.
Unlocking quests also provides visual cues for the player. Unlocked quests are displayed in-game with an exclamation mark (!) on top of the asset that offers the quest to the player. This asset must have the ‘Indicator’ component attached and configured to “Quest Cursors → Giver: questname”.
This message enables us to initiate the quest at a specific time of our choosing. It can be set to auto-start if it’s the first quest, triggered as the player enters the land.
Visually, started quests are identified by having their targets marked with a (º), provided they have the ‘Indicator’ component correctly configured on them.
(Only applicable to the “Wait for Message” type of quests) This message allows us to designate the quest as ready for completion.
The quest is labeled in the tracker, providing the player with visual feedback on the quest’s status. Furthermore, the asset with an ‘Indicator’ component that uses “Quest Cursors → Receiver: quest name“ receives a (?) mark above it. Players anticipate that interacting with that asset will lead to quest completion.
The quest completion message enables us to establish the condition that brings about the quest completion. It not only marks the quest as complete, but also removes it from the tracking system.
Action After Completion → Send Message
The action after completion message provides us with the means to manage the procession of the experience. It is employed to enable/disable asset behaviors and can also trigger additional quests. This message is often referred to as “cleanup” because its primary purpose is to delete assets and/or deactivate behaviors to free up CPU resources.
Message Formatting System
Just as in programming, it’s in our best interest to maintain clear and descriptive message names. That’s why, for each quest, we select a keyword. For example, if the quest is titled “Sunrise Chatting”, we would choose “sunrise”. This leads us to message names like “sunrise.unlock”, “sunrise.start”, “sunrise.end”, & “sunrise.cleanup”.
In the case of an NPC the player needs to engage with, and if the NPC has more than one message, when crafting their dialogues, we follow a structures message format: “sunrise.npcname.dialogue.0X”. If two answer options lead to different paths, we use “sunrise.npcname.dialogue.0XA”, “sunrise.npcname.dialogue.0XB”, and so on.
As a general guideline, we stick to the following variable formatting when naming: quest keyword > asset name > action verb > number > letter.
Types of Quests
Counter quests, as their name suggests, utilize an integer value to monitor player interactions with the objective. This can involve collecting items (Collected Objects) or tracking asset deaths (Deaths). In both cases, we need to specify the tags of the assets you want to keep track of, along with the quantity the player needs to gather/kill.
For multiplayer lands, you can only employ the asset death counting option (Deaths). To make this duty properly, you need to use the “The Quest Objective” blueprint from the The quest objective.Consequently, your objectives will always be visible to the players. It’s important to ensure that the desired tag is added to the asset with the ‘Plant’ behavior.
These quests track the status of a specific asset within the land. This asset should be equipped with a ‘Health’ component and can be killed either by using an“Instant Death” message or by reducing its health points to 0.
These quests is relatively straightforward yet highly valuable. The “Seconds to Wait” attribute allows us to specify the number of seconds the quest should remain active. Timer quests can be categorized into three types: “Survive”, “Defend”, & “Message Needed”.
“Survive” quests are suitable for scenarios involving hordes or temporal hazards. The player must stay alive when the timer reaches 0.
“Defend” quests track a specific asset within the land, and the player must to ensure it maintains some health when the timer runs out. Naturally, this asset have a ‘Health’ component attached.
”Message Needed” quests are the most versatile among timer quests. With this component, you can track different actions by sending different messages. It functions as a timed version of the “Wait for a Message” quest and is excellent for timed parkour races and similar challenges.
It’s important to note that once this type of quest has been triggered and completed, it cannot be triggered again. This means that the quest cannot be retried if it’s failed. Due to this limitation, these quests are typically not used as main quests because we cannot guarantee that the following quests will be triggered if the timed quest is not replayable.
Wait for Message
This type of quest relies on a specific message to mark its completion. This message can be triggered by any action the player performs within the land. It’s crucial to ensure that this message is unique and only activated when the player executes the precise action you intend them to perform.
This marks the initial iteration of how we structure quest logic. At this point, the logic systems within The Sandbox Game Maker should be somewhat clearer.