Practical sharing: Summary of the development of the WeChat mini-game "Happy Tank War"

Preface

"Happy Tank Battle" is a work that supports 3V3 real-time battles and is one of the first WeChat mini-games to be launched online. Because this game is a heavy work among WeChat mini-games, the project development cycle is very short, so the game complexity, development difficulty, and performance challenges are also quite large; the project team completed the development of stand-alone and network battle gameplay within one month.

At the same time, because the core members of the client development team have many years of experience in Cocos2d-x engine development, the project team decided to use Cocos Creator v1.6.1 version of the engine for development. As for the JavaScript language used by the WeChat mini-game platform, the development team basically started from scratch, learning as they went along, which was a great challenge for them.

Architecture

In terms of network communication, the project uses the WebSocket protocol for communication, and the communication format is JSON. In order to cater to the XML protocol of TDR, the project team developed a TDR->JSON conversion tool.

In order to facilitate planners to use Excel spreadsheets for data configuration, the project team also developed a tool to convert Excel into JSON files so that the client can read the configuration file.

For maps, we did not use the TileMap that comes with the Cocos engine, but implemented a TileMap-like mechanism ourselves. Planners can configure map information in Excel and use tools to convert Excel into a json-formatted map file for loading by the client.

Due to the tight development schedule, we need to develop both stand-alone and PVP modes at the same time. Therefore, we encapsulated a command layer (CMD layer) to drive the battle logic. For example, when using a joystick to control the movement of a tank, the presentation layer sends the CMD command to the logic layer for processing. In stand-alone mode, the CMD will be stored in the client's local list, and then the command manager CMDMgr will read the local command list during Update to drive the logic layer for processing. In battle mode, the CMD command will be sent to the server, broadcast to all players by the server, and the command manager CMDMgr of the player's client will drive the logic layer for processing during Update. After the introduction of the command layer (CMD layer), the battle logic layer is abstract and independent. Developers do not need to care about the current gameplay mode, and can be easily reused, reducing development costs.

Our PVP real-time battles use a synchronous architecture in the c/s mode. The client performs collision detection and notifies the server of the collision detection results. The server verifies and calculates damage, and then broadcasts it to other players. The game supports disconnection reconnection and client crash reconnection mechanisms. The server has all the status data in the battle and sends all the data to the client when reconnecting, and the client restores the battle scene.

The player position synchronization uses a timestamp-based position point synchronization algorithm. This algorithm was originally used in the doubles mode and confrontation mode of "Air War". The real-time battle in "Air War" uses UDP communication. And in the WebSocketTCP environment of "Happy Tank War", it also achieved good results. The algorithm principle is as follows:

challenge

During the development process, we encountered many challenges, but we solved them one by one. The specific problems we encountered are as follows:

1. WeChat Mini Game Platform adds restrictions on dynamic code execution

WeChat Mini Game Platform has added restrictions on dynamic code execution, such as: eval ('console.log (1)'), new Function ('console.log (1)'), setTimeout ('console.log (1)') and other calling methods cannot be called. In the Cocos Creator v1.6.1 source code, Function is used extensively. In order to solve this problem, we communicated with the cocos engine developer and referred to the changes in cocos version 1.7 (which had not yet been released at the time). We modified some source code and solved this problem.

2. WeChat mini games are not allowed to exceed 4M

As the title suggests, WeChat mini programs have strict size requirements. In order to solve this problem, we have come up with many solutions.

Measure 1: Customize the engine to remove unnecessary modules and reduce the size of the engine. This can be done by setting the engine modules.

Measure 2: Image compression

Using the png image compression tool pngquant, you can effectively reduce the file size of png images (usually by about 60%-70%).

Even with the above two measures, resources will still exceed the limit, and we can only adopt the solution of dynamic resource download.

Measure 3: Dynamic resource download

We added a resource update scene to the game. When the game starts, the game business module is not created when the scene updates the resources. The business module is created and initialized in the game scene, and then the scene is switched. The specific plan is as follows:

1. First download a resource update configuration file, which contains the list of resources to be downloaded and the resource verification MD5 information.

2. According to the resource download list, compare the verification MD5 with the local file. If they are the same, do not download; if they are different, download.

3. After the download is complete, perform an MD5 check. If the check fails, delete the local file and start the download process again. The MD5 check here can not only verify whether the resource download is correct, but also prevent the resource from being maliciously modified and resource anti-cheating.

4. Modify the cocos engine source code. In the load-pipeline, replace resource reading with reading local downloaded files.

Since bugs may occur during game operation, client patches need to be issued. Resource update configuration files may be modified multiple times, and CDN updates may have delays, causing some players to download older configuration files. In addition, some small and medium-sized operators cache old files for cost considerations. In previous projects, when this happened, players were generally contacted to locate the problem. If it was found to be an operator problem, it would be reported to the operation and maintenance staff, and the colleagues in the network department would push the operator to make changes, which was not efficient. In order to reduce the possibility of this happening, we used a dual CDN strategy.

The specific approach is to add a version number mechanism for files with the same name. When updating a file, the internal storage version number of the file is increased by 1, and the update is performed on two different CDNs. When the client downloads, it downloads two copies of the file and takes the larger version number as the reference. In this way, when updating the configuration file, only one of the two different CDNs needs to be synchronized, which can reduce the CDN update delay and the probability of operator cache problems.

3. Performance optimization

Unlike general games, the js script execution efficiency of the WeChat mini-game platform itself is relatively weak. The javascript engine of the iOS environment mini-game currently uses JavaScriptCore, which does not enable jit optimization by default. The js execution speed is slower than that of mobile Safari. From the simple test results, the speed is about twice as slow. From the Profiler, the js script execution time accounts for about 80%. Therefore, reducing the calculation amount of the script is also an important aspect of performance optimization.

optimization

To solve these problems, the project team made the following optimizations

DrawCall

Rendering batch merging is similar to most game projects. It requires reasonable planning of the use of atlases and jigsaw puzzles of image resources used by GameObj at the same level.

It can be divided into puzzles such as map background layer, surface, map objects, tanks, bullets, special effects, UI, etc. Try to ensure that game objects at the same level use the same atlas and adjacent sprites use the same material.

mask

The game displays a circular avatar of the player, while the avatar downloaded from the WeChat platform is rectangular. The original avatar display uses the mask component of Cocos for rendering, which is inefficient. We implemented a mesh-based control ourselves, which divides a circle into n triangles, assigns corresponding UVs to the vertices of these triangles, and thus draws a circular avatar. This reduces the batch overhead when rendering avatars.

Collision Detection

The collision system that comes with Cocos Creator is not efficient, does not do space division, and is not suitable for collision detection of a large number of units. In addition, the collision box of the collision body needs to be updated every frame. There are a large number of static objects in our game map (such as bricks, main bases, steel plates, etc. in the map), and when the player moves in the scene, the map field of view changes by moving the camera, so the world coordinates of a large number of static objects on the map remain unchanged, and their collision boxes only need to be calculated once.

To solve this problem, we added a static attribute to the Cocos node. The calculation results of the static node can be cached to avoid repeated calculations.

Object Pool

The tanks, bullets, bricks, etc. in the game use object pools. A sufficient number of them are pre-loaded when entering a battle scene and reused during the battle to avoid real-time object creation and destruction.

Avoid scene and node updates

After analyzing the source code of Cocos Creator, we found that when a node becomes active, it will trigger a recursive traversal of the scene, which is very expensive.

To avoid this kind of overhead, when an object in the game dies, it is not removed from the scene or disabled, but set to a dead state by moving the coordinates to a far place, and the corresponding logic processing is not executed in the code. Try to keep the frame rate stable and avoid glitches in the performance curve

Cropping

When an object is out of the main character's field of view and is not a persistent special effect or sound, it can be cut off.

Model Adaptation

Art resources are graded into three levels: high, medium, and low. The planner configures the resource names of different levels in the resource table. During the game, a level is selected for display based on the machine model and actual performance.

In the figure, the horizontal axis is time (in seconds) and the vertical axis is FPS. It can be seen that the FPS has been significantly improved. Through a series of optimization measures, it is finally ensured that the low-end iPhone 5S can basically meet the needs of the game.

The above is the development summary of the WeChat game "Happy Tank War". Interested friends can come and communicate together~