At present, small games are particularly popular, and many teams have also launched WeChat small game projects, and conducted technical pre-study in the early stage of the project. However, from the official WeChat documentation, many pits can be found.
1. Pit of the operating environment
1. API compatibility
- 1.1, Network API
The core of BOM is windows, which represents an instance of a browser. Any object, variable, and function customized in a web page use windows as its global object; lack of Dom means communication for http, websocket, and local storage The API will encounter problems. Fortunately, WeChat provides private implementations of these two APIs. All we have to do is adapt.
The basic idea of adaptation is to detect whether it is running the WeChat platform, and then use the dynamic language features of JS to dynamically rewrite the BOM API. The advantages and disadvantages are as follows:
1. The advantage is that the API caller does not need to make any changes, and the adaptation cost is almost zero. I do
n’t perceive the difference in the running environment between WeChat mini-games and browsers, and it ’s very friendly.
2. The disadvantage is that it will increase the code size, but the loss caused by the increase in code size is almost negligible.
The cost-effectiveness of this adaptation scheme is very high. Examples of adaptation HTTP codes are as follows:
- 1.2, Modularity of WeChat
WeChat mini-games provide a CommonJS-style module API. You can export modules through module.exports and exports, and import modules through require. This is very different from the way browsers import JS files. There is an isolation layer in the middle.
Let us take an example to illustrate the problems caused by modularity.
Usually we use a custom class in a js file on the browser, which can be used directly through the tag.
But this is not possible in WeChat. You need to import the API to an object, and add this prefix when using it. As a result, many codes need to be modified, so how to avoid adding this prefix?
In view of this situation, the solution is to dynamically attach all externally needed methods and objects to the window object, and modify the above code as an example:
- Workflow changes
Since WeChat mini-games do not have Dom and Bom, many libraries that rely on Dom and Bom cannot be used directly, such as jquery.
This environment of WeChat will more or less cause changes in our workflow. The use of third-party game development engines (such as Cocos Createor / Egret / Laya) can make up for the losses caused by these problems.
Second, resource restrictions
1. The total size of the code package allowed for each mini game is 4MB.
Solution 1: Compress the js file and put the image resource on the server for pre-loading.
Solution 2: Use the resource management function of the third-party engine.
2. The WeChat applet requires the developer's server to support https and wss protocols.
Solution: The server enables HTTPS. There are many ways to achieve it, Nginx reverse proxy is recommended.
Three, release audit
After the completion of the development of the mini-game, the following qualifications are required to be published:
1: server domain name record
2: https wss support
3: copy of software copyright certificate + stamp signature
4: WeChat public platform account and AppID
5: developer tools wechat_devtools_1.02.1803210 _x64
6: Copy of the game self-review report + signature
7: iOS development account (optional, fill in the blank)
8: Game version number (need to open WeChat payment)
9: Enterprise developer identity + public account (open WeChat payment) need)