Island Battleground Pioneer

My in-service period: April, 2017 ~ October, 2017

Overview

This project aims to replicate the experience of PlayerUnknown's Battlegrounds on mobile device in 2.5D perspective. As a game starts, tens or hundred of players land on an island. The only target for every player is to be the only survivor at the end. To achieve this, player has to well hide himself and pick up weapons or equipment of various utilities to kick out other players.

I was appointed as one of three principal developers to start and build the foundation of this project. I collaborated with the game artists and produced all of the rendering effects. In addition, I finished all interaction functions and effects of those interactive objects or surroundings in game scene. I further revised relevant edit tools to facilitate game artist's better editing and baking of game scene.

By August, 2017, the fundamental playable edition of this project was approved by NetEase Games. Greater amount of fund was imported and our development team was enlarged. With this project got on track for subsequent development, I resigned from NetEase Games and started to strive for landing on my next station.

This project was released in March, 2018 eventually. In the following sections, my contributions to this project mentioned above will be briefly introduced. Considering the confidentiality contract I signed with Netease Games, relevant technical details are not included.

Rendering

The overall rendering effects of this game aims to mix cartoon and science fiction styles. I collaborated with our game artist and tested several rendering schemes including cel-shading. By further comparison, a scheme combining semi-realistic and fashionable manga performances was determined. Considering the orientation of this project of low hardware capacity threshold, our shaders had been optimized and simplified to a degree fitting most mobile phones while exhibiting our targeting rendering performance.

To exhibit the semi-realistic effects for science fiction element, we amplified the metal effects on some of our weapons, landscapes and floors. These effects were reached by simplifying the standard PBR algorithm. The cartoon element, on the hand, was manifested in our game models and their textures. In addition, we had applied static ambient occlusion textures and subsurface scattering tone to our characters. These decorations vivified our character appearances while brought endurable cost.

I also produced the shader and corresponding logic for some significant interactive effects: the poison gas for instance. The island battleground our players fight within is encompassed by a circle of poison gas. As time elapses in a game, this circle will converge and eventually cover the whole island. The health of player will decrease as long as he steps into the gas region. Our players, therefore, have to escape from the gas region and swarm to those reducing uncontaminated area. To achieve this, the gas shader reads a time limitation and dynamically surge into the interior island from outside. In the final edition of this project, this converging poison gas circle is replaced by a gradual ice freezing process, but the inherent logic remains still.

I made the following video to exemplify the effects mentioned above. As these effects might be revised or refined after I left NetEase Games, the rendering effects you see in this video may not completely accord to what I described above.

Video 1. A showcase of the rendering effect

Scene Interaction

In our game scene, player could interactive with some facilities and environments, assisting them to trace other players or hide themselves. Destructible facilities and grassy region that I developed during my in-service period for this project, are two representatives of this interactive type.

Destructive facilities refer to those walls or constructions where players shelter themselves, but could be destroyed by attacking them. Whenever the facility is destroyed, players stay within or around it will be exposed. To achieve this, the process of attaching the facility from different angles and its collapse will have to be exhibited and synchronized to each of the clients.

Grassy region is where player hide himself: as a player step into a grassy land, he gets an "eye symbol" on his head, showing that he gets invisible to other players outside the region. Meanwhile, he still keeps his vision observing the outside. What is notable is that players hide in the same grassy region are visible to each other. In addition, if a hiding player fire to players outside, he immediately exposes himself and lose the hiding buff. During the development, our game artists placed and dispersed grassy regions of various shapes around the scene. With these regions parsed at server side, their bounding boxes were built and used to detect player's entering or exiting from it. The detection results would notify our sever to set up and synchronize the updated visibility state of those involving players to each of the clients. Grassy region is also destructive, but only by using flamethrower. As flame ejected into grassy region, the grass starts to burn. Player staying in the burning region will consequently get injured and the region loses its hiding property when it burns into ash.

In the final release of this project, destructive facilities mentioned above are not much placed. Instead, nondestructive constructions where player picks up various weapons and take shelter in it, are extensively deployed. Therefore, I will just show the interaction with grassy region in the following video.

Video 2. A showcase of interaction with grassy egion

Scene Editor

This game distinguishes itself from other similar products by enabling "big world", a massive game scene with significantly larger size while without any loading interruption as player roaming across different regions.

This had required us to improve our game engine to support the preload of those scene chunks player is likely to arrive and release of those player has left per seconds. Besides this, there's a more thorny problem during our early development: big world edit. With the original version of scene editor, whenever a game scene is opened, all scene chunks and terrains will be loaded, even though only one or several of them are to be edited. Using this version, as our scene area got larger, our game artist had found it more difficult to locate a targeting area. In addition, given sizable memory space occupied by scene resources, the editor had run significantly slower. Addressing this problem, I learnt related source code of game editor and produce a new version with a new feature that supports game artist to just load those targeting scene chunks instead of the entire scene. By opening up a panel showing the indexes of all scene chunks in a grid board checkbox, artist could choose and load their targeting chunks. These choices will be recorded in artist's local space, facilitating them to directly reload targeting chunks when the same scene is opened next time.

This feature significantly boosts the editor's running speed in big world scene edit, improves artist's working efficiency and facilitates the work assignment and integration for artist team. Given this new feature, scene baking based on chosen chunks, is also supported.