Game Mode Description
For the first time ever in the series, we transformed the recipe of WW version of the division dark zone from a 12 players PvPvE game mode to a 32 player PvE mode. Every couple hours, there will be 1 dark zone among all 3 available dark zones that goes completely PvE, this dark zone will have modified rules and gameplays to better fulfill the PVE needs of our mainstream player base.
Player Feedback
Responsibility
I mainly in charge of all the gameplay programming tasks of this mode, as well as tech support for UIs, audios, performance optimization, live configs, etc. Here's a breakdown of my work
New mode life cycle
Based on config file, read in which Dark zone will go PvE at which time
No more PvP activities will be allowed, PvE faction AI will start to invade the area
Mark that dark zone, when time reached, transition to staring phase
Manage the duration of the whole PvE phase
When about to reach the end of this event, transition to stopping phase
No more PvE activities will be allowed, exiting AIs and landmarks will start to extract
New mode gameplay flow
When the event is active (90 mins), there will be a few rounds of boss fights happening, and a round consists of:
Grinding phase
Player will need to grinding landmarks, in which the enemy will drop a few contaminated currencies.
Every time when the player died, they will drop 50% of their current currencies.
Boss phase
After 10 mins, one random extraction site will be activated, and the players need to go there facing the boss fight, 1 random boss (helicopter drone) out of 3 will be spawned, each of them will have unique abilities
This phase will last for around 10 mins, if the player failed to defeat the boss, the enemy will retreat, mark failure of this phase
Extraction phase
If the player successfully defeated the boss in time, they can then call the helicopter to the site, and extract out their contaminated currencies
This marks a complete round, at the mean time, a new round's Grinding phase will start, looping until the mode closed
Player then can spend the extracted currency as a general currency to buy various types of resources, materials in the game, marks this mode a very rewarding mode
Server Client Communication
The majority of the computing work happens on server side, server code will process and manage the whole life cycle of this mode, it will also broadcast delegates to script system, so the critical events like phase changed, mode started and mode ended can be properly picked up by script to spawn enemies. (Script still soly run on server)
Player UI would receive notifications for these important events as well, at this moment, server will grab all valid clients and send each one a network event across the network hub. Each client will then process these serialized network event data upon receiving, render corresponding UI notifications in their viewport
Performance Optimization
With 32 Players, each have their own talents, skills, gear talents, weapon talents, etc, performance become a very serious problem, including:
High network event volume (Server CPU, Client CPU)
All the players are sending and receiving network events over each other, results in servers had trouble processing these events, clients had trouble receiving these events
We tried to batch process network events rather than creating the same network events over and over, for example, instead of creating 50 transaction request when picking up 50 currencies, we just create 1 transaction request containing 50 currencies amount
Entity filter execution event over budget (Server CPU)
With these much players, every skill that used to only find 10 if not 20 agents can now find nearly 100 agents (Players and their gadgets, bosses, roaming enemies, etc.) Causing script execution bottleneck.
We pinpointed the problematic scripts and optimized their searching algorithm to gather more specific agents before iterating through them.
High contention of talent scripts due to too much players (Client CPU)
We disabled unnecessarily and imbalanced talent scripts when the player enters the area during the mode
High computation time when prepaing UI (Client CPU)
Each player will render others name palete, which will do a lot of computations before render, we completely simplified the algorithm of thes UI during this mode to only show essential info for the players.
Entity visual count over budget (Client GPU)
With these much players, GPU entity budget will easily overflow, causing agents to not render at all (Boss disappear) We optimized the algorithm to prioritize what to pop off to make sure important gameplay agents remains in the end (We eventually boosted the agent count, it will consume more GPU resources, but our game isn't target console platform so this trade off becomes worthwhile)
Live Config
As a live service game. It is crucial to make the server live, so we extended an existing feature called live config, which will store an "override" data structure in json file at the server side. Every time when the runtime noticed the live config has been altered, it will regenerate a data to "override" existing data in package, so the logic would be.
Game Config Data
Designer configured data, will be cooked to package and load to server, these are the default config data
Live Config Data
For selected elements, it will try to apply a live config override upon on it, if there're existing live config override data, say we want a mode to open at 3 pm every day, that's configured by designers in package, but then we want to emergently change the opening time to 4 pm, we can do so purely with live config data without closing the server, it essentially support every config in the game, as long as corresponding code supports it.
For this game mode, we used Live Config to dynamically adjust how much players can be in the game (If the server performance is really bad, we will slightly tune down available players from 32 to 24)
We also used Live Config to dynamically modify the opening time of the session, like we want to have one more session during festival, we can simply add that entry in the json file, without build another package and shut down the server.
Comments