I joined the Dune Awakening project approximately 7 or 8 months prior to release. I split my time between tackling critical crashes and bugs in the name of stabilization and developing custom systems to support new features and content. I quickly had to learn about a breadth of systems that made the game function, from our multi-server architecture for the Deep Desert that required a deep understanding of networking to how the interaction system functions when it comes to different kinds of items. It was hectic leading up to launch, and afterwards things only sped up as we raced to get content ready to serve up to the player base.
Into Arrakis…
Stabilization and Launch
I came onto the project rather late in the development cycle. As the release date was coming up, it became all hands on deck to get the game out the door in as clean of a state as possible. I still believe the launch of the game went smoothly for the most part, to my understanding the smoothest in Funcom’s history so far. Players were enjoying the game which was always a good thing to hear.
In the months before the release that I was working on the game, I was part of the Live team. We tackled some of the most technical of the crashes and bugs that cropped up, searching through callstacks and crash logs received from other teams and from our beta players. This was a bit of a “baptism in fire” as far as getting introduced to the project goes, I had to come put to speed quickly on a litany of systems.
Many of the crashes related to server authority transfer and travelling between servers. The Deep Desert portion of the game (at launch) was a mesh of 9 servers positioned in a 3x3 grid. As players would move between them the authority of who owned the client would pass between servers. Many of the systems in the game had not been fully constructed to account for this and so we had plenty of bugs to sort out spread across systems including: Building, Inventory, Combat, Vehicles (Especially vehicles), Sandworms, Journeys, Persistence, Parties and Guilds. We also had our own custom multithreading architecture that was used (and misused) in many places to improve processing speed. It had a habit of coming into conflict with things like saving player state and was often the root of other system’s woes with authority transfers. Fortunately I came up to speed fairly quickly, and was able to contribute to solving a several dozen issues before I moved over to start building content for post-launch.
This ^ thing caused me so much pain
CHOAM Salvage Rights
The CHOAM Salvage Rights event was the first (and potentially last) time gated event for Dune: Awakening. It was the lead in for the Chapter 2 update and involved scattering the Hagga Basin map with anti-ship turrets that players would need to sabotage, crashing spaceships for players to salvage, as well as several merchants and a persistent sky effect. The goal was to make the map feel alive and active prior to the chapter 2 update, and in this regard it did succeed.
I was heavily involved in getting this event to work properly. I was responsible for building the event modifier that would allow us to spawn the ships and turrets around the map, as well as building custom loot, NPC, and actor spawners to function with our level streaming setup. The games systems for things like loot, NPC spawners, and resource nodes were not set up to work with content that could appear and disappear during runtime. This meant that ensuring the loot containers, cuttable doors, and ambushing NPCs all spawned in properly required custom implementations.
The main chunk of the work involved the content spawning Event Modifier. This bit of tech utilized custom terrain block actors to stream in sublevels when prompted by a spawn controller. This spawn controller randomly selected the terrain block actors up to a set number and would activate them at randomized intervals, leading to ships crashing fairly consistently around the map. I also had to enable the content within the sublevels for each terrain block to register with its owning terrain block. This allowed ships to indicate to their owning terrain block when they’d been destroyed, so the terrain block could then indicate to the spawn controller it needed to start spawning the next ship.
This setup involved some hurdles. In Unreal Engine 5 when you stream out a sublevel, it doesn’t get fully destroyed. The actors within the level have EndPlay called, but they dont get cleaned up. This means that when the terrain block gets streamed in again, it’s state can be dirty. My one regret in working on this system is that I didn’t get the opportunity to introduce a way to work around this issue, and specify whether a sublevel should be fully cleaned up when streamed out. Due to time constraints we had to do the dirty version of resetting the state to its expected values for any non-spawned actors in our event content sublevels in EndPlay.
The Concept and The Subsystem
Events
The plan for post launch content was set up to be released in chapters. The vision was for there to be limited time events that would act as teasers for the upcoming updates. This became rather tricky, as we would be designing and implementing an event that was tied to the story of the game (making it sort of not repeatable). This meant that we were not given a ton of resources or manpower to develop the systems and content needed. While I am still proud of what we got out the door for the Chapter 2 event: CHOAM Salvage Rights, it was undeniably not as polished as it could have been. This was largely due to factors outside of the control of the NC office. On the bright side, it was a very technically interesting system to build out and I was able to learn a lot about level streaming and its relation to networking.
The Events subsystem was a standalone subsystem that integrated with our GameTweaks system. This integration allowed our Live Ops team to activate and deactivate events in live builds without the need for patches or hotfixes. It was specifically set up in a way to allow us to make modifications to event parameters as well, so that if for instance a spawn rate for particular content was to high it could be tweaked easily. The system allowed us to define events and event modifiers, multiple of which could be active simultaneously. We built different types of modifiers to allow us to both modify actors and systems always present in the game, as well as to spawn in event specific content across the main Hagga Basin map.
