Quests and Quest Tools

---

Repeatable Quests

The responsibilities of the World Experience team included maintaining and expanding the quest system, and over the course of my time at New World I worked on a number of quest features and gatherables. One feature I engineered was expanding the quest system to allow for repeatable quests. This feature was originally developed to make seasonal quests for our holiday events automatically reset at the end of each event, so that designers would not have to remake the same quest for the following year - however I architected the system to allow a wide range of applications, such as daily or weekly quests. Designers used this system to reward players who logged into our game every single day, in the form of recurring quest rewards for completing dungeons, engaging in PvP, or participating in world events.

Back To Top

Quest Tool

For the release of Nighthaven, we brought our internal quest tool into production to complete the quests for the new zone, as well as to re-write quests for existing zones. The tool, written using the Qt framework, had been primarily developed by an external team, but at the time that I joined still had a lot of work to do before it was ready to be integrated into our team's workflow. As designers began to transition from bloated Excel workflows to the custom tool, it was critical that the tool was reliable, intuitive, and foolproof. I worked with the design team to identify friction points with the tool, and found quick and effective solutions to allow the tool to become usable as soon as possible.

Simplifying Data Authoring

The purpose of a tool is to make the data authoring process easier - this includes data formats that are complex and unintuitive to construct. My team developed a feature to allow quest designers to globally track progress throughout a quest, in the form of “locking” and “unlocking” a unique identifier based on task state. These locks, referred to as NPAs internally, were critical for things like showing or hiding an NPC based on how far the player had progressed in a quest. In the quest tool, I was tasked with adding a visual indicator of where within a quest the NPA would lock or unlock - however, I realized as I was working on the system that we should also add a simple editor within the tool to provide designers with a more intuitive way to use this powerful but complicated feature. This was important because the NPAs were defined as a long, complex text string, with a very specific data format. This worked fine with test data, but I knew that as designers began using the system, it would be exhausting to incorporate into the long, complex questlines they create. I coordinated with designers to come up with a simple but effective visual editor that would significantly simplify the process of authoring the NPA data, which helped designers understand the system better, and to utilize this powerful system without fear of a mistyped character causing disastrous, hard-to-understand bugs down the line.

Future-Proofing

Live service games are constantly changing, and sometimes that means the data must be changed too. One controversial fallback of the quest tool was that it was much more difficult to mass-edit quests when needed - in Excel, its as easy as a find & replace all, but in the quest tool, each quest had to be individually updated. To address this, I added a system for programmatically updating the data for all quests made in the quest tool, so that changes to any quest systems would not require designers to edit data for hundreds of existing quests. I felt strongly that mass edits should be done carefully, and should be extremely obvious to the user making the changes - so I had the system track all quests that were converted, and pop up a detailed list of all changes before prompting the user to save and submit the conversions immediately. While the first iteration of this feature required a programmer to make the data conversion, it proved to be absolutely necessary in getting the Nighthaven and updated Reekwater quests ready to ship.

// [PSEUDO-CODE]
// The DATA_CONVERSION macro is used to define a data conversion, along with a helpful message to understand what the change is doing.
// All defined data conversions run on the base XML as the quest tool reads in quests from disk. 
// If the associated lambda function returns true, the quest has been modified - 
// It is then checked out from source control, saved, and displayed in a detailed list of converted quests as the tool starts up.
DATA_CONVERSION(questElement, "[JIRA-12345] Change all Morgaine quests to be Cecilia quests instead", [this]()
{
    //If the quest_giver attribute on the quest node is Morgaine, change it to Cecilia
    if (GET_ATTRIBUTE(questElement, "Quest_Giver") == "Morgaine"){
        SET_ATTRIBUTE(questElement, "Quest_Giver", "Cecilia");
	    
        // Return true if the quest was modified so that we can add it to the list of converted quests
        return true;
    }
	
    // The quest does not need to be converted.
    return false;
});

Streamlining Workflow

There are many different data types associated with quests - including definitions for NPCs, dialogue states, quests, quest tasks, and more. While much of this data needs to be kept separate, there are some elements that should stay consistent between the different data types, such as the release version for a quest and its sub-tasks. When I started working on the quest tool, it made no assumptions about any data, resulting in a lot of copy/pasting and missed data entries that would cause bugs down the line. I worked closely with designers to identify the most frustrating aspects of working in the quest tool, and added logic to automatically sync fields that should always be consistent, saving us a lot of time in the quest crafting, and a lot of future headaches debugging issues caused by missed data fields.

Back To Top

Dialogue Camera Tool

When players interact with an NPC, the camera focuses on the NPC according to a camera values associated with the dialogue line. While these values can be determined by a pre-set angle based on the NPC’s position, any further modifications required designers to manually enter dozens of camera values in a complex, unintuitive data format, and then carefully copy each value one by one into a spreadsheet before reloading the game. To speed up this workflow, I developed an in-game tool to allow designers to dynamically move the camera, adjust camera values such as FOV and depth of focus, and then easily export the values to our datasheets. Users can also adjust the location of the player/NPCs in the dialogue cutscene, as well as modify their head angle. This allowed designers to very quickly create more dynamic dialogue sequences, with less repetitive camera angles, and more interesting character framing to better convey the emotion of the quest.

I took care to ensure this tool was as user-friendly as possible. This meant modifying the camera values with intuitive sliders, radio buttons, and selection menus, and having the tool use the current settings to generate the complex data formats the game reads from saved data. It was also critical to understand how the tool was being used - when I spoke to designers about the problems they were facing, they stressed how unforgiving the existing system was. For example, if they made any mistakes while editing, such as accidentally exiting out of the NPC dialogue or entering a data field incorrectly, any existing changes would be lost, and they would have to start over, which was an extremely time consuming and frustrating process. To address this, I made a system that tracked each modified camera state while the game was open, so players could modify multiple camera states in a single session - which was very useful for editing cameras for an entire questline. Dialogue cameras are tied to the current dialogue key, so this system worked by creating a map of dialogue key -> overridden camera values for every camera that the tool had modified. When a dialogue is opened, the camera system first checks if there are any overridden camera values to load in place of the values read from disk - allowing designers to pick up editing where they left off seamlessly. These override values could then be bulk-exported at the end of the session, and pasted into the correct datasheet in one single chunk of data.

---

Back To Top

---

World Experience

---

Global Storage for Crafting

Problem Description

In New World, the player has a local inventory, and around 20 storage sheds located throughout the world that they can deposit items into. Each storage shed has a cap on the number of items it can hold, but players can move items freely between any visited storage sheds while interfacing with a shed. This implementation allows us to limit the number of stored items that are replicated to the player’s client at any given time - in general, we only care about the items stored in the zone the player is currently in.

However, this created a frustrating experience for crafters in our game - crafting tables could only pull ingredients from the local storage shed, so players would have to sift through all of their storage sheds trying to find relevant ingredients and move them to the local shed before crafting. Since the launch of New World, players have begged to have crafting stations pull ingredients from all storage sheds, to get rid of the need for inventory micromanagement.

While the quality of life improvement for this feature would be extremely significant, implementation had to account for performance and scale. Across all of their storage sheds, players could potentially have more than 10,000 unique items in global storage, each with around 60 bytes of data. Frequently replicating and iterating over all of these items would be a significant hit to messaging bandwidth, client RAM, and performance - especially with hundreds or thousands of players requesting these items from the server at the same time.

Solution

While the client needs to know how many ingredients we have while crafting, the number of ingredients that can be used at each type of crafting station is relatively small. Instead of replicating the entire list of all 10,000 unique items the player may have in their storage, we only need to search for the 50 or so relevant items. Additionally, most of the item data size is not relevant to crafting - the entire item data contains information about perks, rarity, and stats, but all that matters to the crafting system is the item id, and the quantity we have.

With this information, I engineered a system that would create a roster of relevant items, and the storage sheds that contained them. When the player opens a crafting station, the system creates search parameters based on the item types needed, and iterates once over the player’s global storage sheds. If an item matches the search parameters, the item and its local quantity is added to the search results - additionally, the current storage shed is added to the list of relevant storage sheds. Once this process is complete, we replicate the list of unique item ids and their total quantities, to be displayed on the crafting screen. By only replicating the id and quantity, the number of bytes per unique item is reduced from 60 to only 8 bytes.

When the player crafts an item, it changes the global item quantities for the ingredients we're tracking, but we don’t want to have to repeat the entire search process every time the player crafts something. Instead, we maintain the quantities within the search results roster, in addition to removing the items from the sheds we marked as having search result items. When items are successfully removed from a storage shed, the quantity removed is deducted from the results roster on the server, and that updated item quantity is replicated back to the client.

This implementation allowed for players to craft with their global storage contents seamlessly, and with minimal performance and memory impact - in fact, rewriting the storage replication logic allowed for several optimizations in the replicated size of the player, since the amount of data replicated for crafting was significantly reduced due to only tracking the item ids and quantities. This feature launched shortly after the release of Nighthaven, and was widely celebrated by hardcore crafters in the game.

Back To Top

Player Housing

In new world, players can purchase and decorate houses in up to 3 settlements throughout the world. I inherited ownership of this complex system, and was responsible for any updates to the housing system, and for debugging any live issues identified by players.

[Under Construction]

Back To Top

World Changes

With the introduction of New World: Rise of the Angry Earth, the First Light settlement was destroyed and the entire zone was re-worked into a high-level, uninhabitable wild zone. This was an incredibly cool and immersive design choice - but we had to ensure players didn’t feel “cheated” by the destruction of a zone they had invested their time and money into. On the housing front, this meant ensuring their houses were properly refunded, their stored items were easily accessible, and that players understood at log-in what happened. This change required careful modification of storage and housing logic, to ensure players could not lose their items.

I engineered a system to refund removed plots as soon as the player logged in, and immediately refund the contents and notify the players. Typically, a player’s house contents are loaded from the database through the housing plot it was purchased on - however, the plots in this settlement had been destroyed. I added logic to identify when a player had owned a house on a destroyed plot, and to re-route the critical restoration process through the player. Once the house’s contents have been loaded, the items are sent to a designated storage shed, the house gold cost is refunded, and after confirming the transactions succeeded, the house data is deleted from the database. Additionally, a popup was shown immediately notifying the player of the house destruction, how much gold they were refunded, and where they could find their housing items.

In addition to the housing changes outlined above, all storage items had to be moved from the existing first light settlement storage shed to a new shed - and players needed to be able to pull the items from this shed to recover their items immediately, even though the shed was inaccessible until the ROTAE quests were progressed. I added configurable logic to move items from a source shed to a destination shed on login, and added checks to ensure that items could always be remotely withdrawn from an inaccessible storage shed via the storage menu. Because this change only happened once on the player's first login, I also added extensive testing features to be able to force a player into the state that would trigger the move, so that the feature could be tested easily at scale. This system proved to be invaluable, and was used to alter storage locations for several future zone changes.

Back To Top

---