This is the “micro channel small game development actual combat” series of 16, this series we will start from 0, make a 1010 game.
If you don’t have any experience in game development, you can read my “Anyone Can Make Games” series, which will guide you hand in hand to make your first wechat game.
The small game development tool used in the tutorial is wechat official small game production tool: wechat small game production tool
I used to pay little attention to optimization, because I have been working on mobile games. The update speed of mobile hardware is very fast, with faster computing capacity, stronger rendering capacity and larger memory. As a result, if you’re not making a big game, it’s almost impossible to think about optimization.
Until I started to make micro games on wechat, as a small game, there are many limitations, such as the calculation ability, rendering ability, especially the limit on the game size (no more than 4M), these limitations forced me to change some of the previous ideas of making games.
At the beginning of finishing delicate 1010, I didn’t care too much about the optimization of the game, because the game was small, and the simple style was used, and the material resources were relatively few, so the whole game ran smoothly. However, as I continued to expand and add more content to this little game, problems arose.
On July 4th, I updated a new game mode: The Quest Mode. It is equivalent to doubling the content of the original game.
Let’s take a look at the two graphs below. Here are two important pieces of data:
Total time: refers to the time from clicking on the game icon to officially entering the game.
CPU: Refers to the amount of computing required to run a game.
You can see that the game’s startup time and CPU started to increase after the addition of the Quest mode. One of the most serious was the increase in startup time, which peaked at 9 seconds, as if a player had to wait 9 seconds to open a small game, they probably wouldn’t open it again.
In response to the above problems, I set out to optimize the game, first looking at the official documentation for optimization recommendations.
The official optimization Suggestions here: gamemaker.weixin.qq.com/doc/minigam…
The content is relatively light, with a few principles and no detailed guidance. But at least there was some direction, and I started on a journey of mini-game optimization.
The following is my record for a micro channel game has been online optimization operation.
Streamlining game resources
Every imported game resources will eventually be included in the package in the body, in the process of game development will import a lot of resources, contain a variety of images, audio, digital, and so on, finally some resources have not been used, then carefully check the import of resources, to find and remove the unused resources, in order to avoid they increase the size of the game.
The most common type of resource in the game is graphics, and with graphics we have to stick to the principle of using the smallest possible image to achieve the desired effect.
For example, the background image of the dialog box in the game originally used a 380×580 rounded rectangle image, and finally used a 190×290 image after doubling the size.
There is a partial loss of detail in the edges and shadows, but it is generally acceptable, thus reducing the size of the original large image by half.
Another principle for image resources is reuse. Wherever you can reuse the same image, reuse the same image.
As shown, in the optimized [Delicate 1010] home page, the 8 buttons use only two types of images, one is a long rounded rectangle (for sound and vibration buttons), and one is a square rounded rectangle (for all the rest of the buttons). By adjusting the size and color of the picture, different buttons can be made.
Here I use rounded rectangles, because the rounded rectangles can cause problems when they are greatly enlarged or reduced, so I use two types of rounded rectangles. If I use square rectangles, then all the buttons can be reused in one image.
Simplifying game Logic
The logic of the game is our building blocks.
First remove blocks that are not used in the game. Carefully check the logic blocks in the game, delete useless or idle game blocks, usually for useless blocks to timely delete, do not put there, to form a good habit.
Secondly, we should adhere to the principle of “reuse”. For repeated logic, we should reuse “function” or “notice” to avoid using repeated building blocks for many times.
Use functions to override logic
For example, in Delicate 1010, a dragged block that does not meet the requirements will return to its original position. There are many “if, or else” blocks that do not meet the requirements, and the same two blocks are used repeatedly for all the requirements.
In this case, we can make a function out of the repeating blocks.
You can see that multiple parameters are set in this function so that the function can be used wherever the zoom function is needed.
Finally, a function is used to replace the original reused building blocks.
Use advice to reuse logic
There are certain limitations to using functions, especially for local variables, where changes to local variables within a function are not saved when passed as arguments. For example, if a local variable 10 is passed into a function as an argument, and the local variable is doubled inside the function, the final result should be 20. However, after the function is executed, the value of the local variable is still 10, so only global variables can be used for variables processed inside the function.
So for repeating blocks that need to deal with local variables, we can reuse them by using “notifications”.
This is part of the logic code in the change theme. You can see that the code in the red box is reused. Here we can put the duplicate code into a notification.
We simply send ourselves a notification of where repeating blocks are needed. This part of the original code has been reduced by half through reuse.
One thing to note here: the current wechat mini game development tool has an upper limit on the number of building blocks.
This was a problem I encountered when adding new content a few days ago. The project could not be saved. After consulting the development team, I knew that the code exceeded the limit.
So think carefully about each building block you need to use to achieve the desired function with as few blocks as possible.
Another thing to consider is that the current code limit determines the size of the game you are going to develop, so if you want to make a big game using wechat mini game development tools, you need to think about this code limit in advance.
Plan the Scene properly
My original solution when adding the Quest mode was to create a new scene just for the quest mode. In this way, the classic mode and the Quest mode can be separated from each other. In the future, no matter which mode is modified or expanded, it only needs to be developed in its corresponding scenario.
Creating one more scene is a lot more resources, and there’s a lot more that can be shared between the two modes of play. However, because much of the resources and building block logic could not be shared across scenes, much of the content had to be copied and pasted, resulting in a lot of duplicate code and resources.
After hitting the maximum code limit, I had to rethink the scenario and merge the two scenarios into one.
As shown here, I combined the original “Classic mode” and “level mode” scenes into one “game” scene. After the merger, a significant amount of code space was saved, and it was later possible to add “edit” scenarios to enable user customization of levels.
The take-home message here is don’t go overboard with scenarios. If you can do something with one scenario, don’t use more scenarios.
Reduced the number of sprites in the game
The number of sprites in the game scene determines the amount of rendering and computation required. In general, the more sprites there are, the more rendering and calculation is required. In order to improve overall performance, the number of sprites in the game should be reduced as much as possible.
Click on debug to see the number of sprites in the current scene in the “Global Variables” option.
As shown, before optimization, the number of sprites in the initial scenario was 325. Although the game’s interface seems very simple, the number of sprites is very large.
Our goal was to keep the number of sprites in the game as low as possible while keeping the game looking good, and I made the following optimizations to do that.
The original 10×10 grid in the game was created using a single grid, so it would take 100 sprites to draw it. Instead, I imported a drawn 10 x 10 grid image so that only one Sprite was needed for a display grid, which reduced the number of sprites by 99.
In addition, all the shapes in the game were originally composed of single blocks, but now I made the shapes into a picture directly, which again reduced the amount of sprites.
The final optimization reduced the number of sprites in the scene by more than 100, even after new features were added.
At the same time, it can be clearly seen from the CPU indicators, after optimization, the consumption is significantly reduced, because fewer sprites means less CPU consumption.
Create a simplified initial scenario
The “game startup time” is a very important metric in mini-games. It means how long it takes for the player to unlock the game, and usually the shorter the better.
There are many factors which can decide the length of time, including the size of the game, the amount of resources, the status of the network, the player the performance of the mobile phone, etc., most of these factors is uncontrollable, besides we all kinds of optimization methods of the above mentioned, there is a way that can help us improve the start-up speed of the game, is to create a startup scene as simple as possible.
The original startup scenario.
Added simplified startup scenarios.
Here I added a very simple startup scene for the game, consisting of a small ant icon and a few building blocks. The scene opens much faster because there are fewer resources and fewer building blocks to load.
Also, don’t forget to select resources in the artwork Settings to load when switching scenes.
In this way, due to the start of the scene resources are very few, it can be quickly loaded and opened, and then we load from the start scene to open the later scene with more resources.
Finally, to sum up, for the optimization of Micro-channel games, we can start from the following aspects:
- Streamlining game resources
- Simplifying game Logic
- Plan the Scene properly
- Reduced the number of sprites in the game
- Create a simplified initial scenario
With these optimizations, I managed to reduce both the startup time and performance cost of Refined 1010. Hopefully, these optimizations will give you some Pointers as well.
Optimization is a never-ending thing, and I think the best optimization should be done before production, because a better idea, a better plan is better than these after-the-fact fixes.
It would be hard for me to feel the feeling of making things within all kinds of restrictions if I didn’t make wechat mini-games. Think of the game developers who wanted to make games with 256K cards. Although the restrictions were larger, it still didn’t affect the birth of many classic games. So is it easier to get inspired when you’re working within a certain limit?
If you also want to learn to do games, pay attention to my public number [small ants teach you to do games] on it.
Welcome to experience my first small game work, wechat search “delicate 1010”, a delicate and warm small game.
Original is not easy, if you think the article is good, please click a “like” to give me some power, thank you ~