The 3D mini game “Girls Trying Guns” has reached a new height! An ARPG developed in only 24 days!
What kind of game can be achieved when you develop a 3D mini-game in 24 days?
On the eve of this China’s spring festival, a rouge-like action role-playing game “Girls Trying Guns” was quietly launched. This work aimed at the mid-core/hardcore ARPG mini-game market was developed by only one developer and one artist, which lasted 24 days and was developed based on Cocos Creator 3.4. Although the development cycle is very tight, “Girls Trying Guns” still presents beautiful characters and scenes, great light and shadow performance, and excellent 3D graphics quality, running smoothly on low-end devices.
In the game, the player controls the character through the virtual joystick, and while avoiding the monster attack, the player can melee attack or use the skill to kill the monster. The game currently contains 24 different kinds of weapons, which players can obtain by synthesizing or going to the dungeon to farm monsters. Each piece of equipment has its own unique ID and different attributes. The monsters in the later stage of the game are also randomly generated, with greater playability and complexity.
We were able to talk to iwae, the planning and programer of “Girls Test Guns” from Zhuhai Uwater Technology, to share with us some research and development experience and experiences building the game from a technical point of view. Here is a summary of the discussion:
High-quality artistic performance
At present, there are few medium-to-severe ARPGs in the mini game market, so we hope to make a “3D ARPG with exquisite image quality on the mini game platform”, and “Girls Test Guns” was born. We use real-time lighting + baking to improve the performance of lighting and shadows and revolutionize technical and art in the small game category.
The characters in the game are unlit, shaded cartoon textures. The cartoon rendering effect of Cocos Creator is quite good. We use the ToonShader that comes with the engine to remove the light parts and retain the shadow. At the same time, ShadowMap is used to realize the real-time shadow of the character. High-end machines are enabled by default, and low-end devices use shadow patches instead.
The scene environment uses Cocos Creator’s default PBR material + Lightmap lighting baking, using one main parallel light for projection and two auxiliary parallel lights to set the atmosphere.
To enrich the scene performance of the game and make the visual perception in action combat more dazzling, we made the color and range of the edge light deepen when the character is hit (using Kirinzi’s “First Taste of Shader and Realizing Edge Light” article). Environmental effects, shield effects, and external lighting of some weapons use noise map and UV scrolling (using Kirinzi’s “Shaders’s Single Texture Realizes Dynamic Lighting of Weapons” article). Some shader effects are implemented based on the plug-in Shader Editor.
Strengthen the sense of combat
We have made a lot of attempts in the sense of combat, and we have also asked the bosses in the Cocos engine team for suggestions. At present, we mainly optimize from three directions: action performance, camera, and vision.
In terms of action performance, we rewrote director.tick to control the timeScale implementation of the game, mainly used in the charging when releasing skills, the pause when hitting the enemy, and the slow-motion when defeating the last enemy in this level. Slow-motion, frames, etc., can be easily achieved by setting the TimeScale.scale parameter globally.
@ccclass ( 'TimeScale' )
export class TimeScale extends Component {
// Default time scale
public static scale = 1
start () {
// Overwrite director.tick
const originalTick = director.tick;
director.tick = ( dt: number ) = > {
dt *= TimeScale.scale;
originalTick.call(director, dt);
}
}
}
Camera optimization mainly includes the following aspects:
-
Lens shake effect: There are different vibration amplitudes according to the character’s critical attack or the character’s degree of damage.
-
Camera Field of View: The field of view changes depending on the skill. When some skills are released, a camera close-up will be performed to narrow the field of view, making the player more focused and enhancing the player’s sensory experience; when skills such as displacement are released, the field of view will be enlarged, and the background will be opened so that the player can observe a larger scene.
-
Camera Quaternion Rotation: When some skills are close-up, the camera will rotate simultaneously.
In fact, we are not very satisfied with the impact of the current version, especially in terms of visuals, skill effects, weapon light, explosion point effects, etc., there is still a lot of room for improvement, and the post-production effects of the camera are also planned to be carried out in the new optimized version.
Model adaptation
Higher-quality graphic performance is bound to bring more significant operating pressure to mobile phones, which requires adjusting according to different devices to ensure the quality of the graphics and smooth operation. Of course, the specific adaptation plan needs to be carried out according to the specific game. Our model adaptation plan for “Girls Test Guns” is for reference only.
Most of the mini game platforms can obtain the model through qg.getSystemInfo/wx.getSystemInfo, and then return the model’s high, middle, and low-end configuration according to the model data (mainly judged by CPU/GPU) for model adaptation.
private performanceLogic(): void
{
//Get device benchmark
let deviceType = UIUtils.getDevicePerformacePhase();
if (deviceType == EDeviceType.High)
{
//Enable shadows, highest performance
console .log( "Device BenchMark==H" ) ;
director.getScene().globals.shadows.enabled = true ;
director.getScene().globals.fog.enabled = true ;
}
else if (deviceType == EDeviceType.Middle)
{
//Disable shadows only
game.frameRate= 60 ;
console .log( "Device BenchMark==H" );
director.getScene().globals.shadows.enabled = false ;
director.getScene().globals.fog.enabled = true ;
}
else if (deviceType == EDeviceType. Low)
{
//Disable shadows and decrease anim rate
console .log( "Device BenchMark==L" );
game.frameRate= 30 ;
director.getScene().globals.shadows.enabled = false ;
director.getScene(). globals.fog.enabled = true ;
}
else if (deviceType == EDeviceType.VeryLow)
{
//Disable shadows && fog && anti-alias, and decrease Anim rate
console .log( "Device BenchMark==VL" );
game.frameRate= 30 ;
macro.ENABLE_WEBGL_ANTIALIAS = false ;
director.getScene().globals.shadows.enabled = false ;
director.getScene().globals.fog.enabled = false ;
}
}
}
Referring to the mobile phone chip ladder diagram, anything higher than the Snapdragon 660 is a high-end machine by default, the Snapdragon 660 to 625 is a mid-range machine, and the others default to a low-end configuration.
If the model is not in the model data, we use the screen resolution for model adaptation. Obtain the screen length and width through screen.windowSize. If it is greater than 2300, it is judged as a high-end machine. From 1920 to 2300 is a mid-end machine, and if it is less than or equal to 1920*1080, it is a low-end machine.
When the game is initialized, the configuration of high, medium, low, and extra-low is obtained according to the model adaptation:
-
High-end models, without frame lock, enable ShadowMap shadowing.
-
Mid-range models, do not lock the frame. Turn off ShadowMap shadowing.
-
For low-end models, the frame rate is locked to 30 (strong physics requires additional adaptation), and ShadowMap shadows are turned off.
-
For ultra-low models, while the frame rate is locked to 30, some particle and animation effects are turned off, and ShadowMap shadows and fog effects are turned off.
Performance optimization
Some of the solutions introduced above actually take performance optimization into account. For example, characters use unlit cartoon materials, and scenes use Lightmap to reduce lighting overhead; some special effects such as weapon lighting and shield effects are implemented through Shader to reduce particles. Use; model adaptation optimization to ensure that the game can run smoothly on low-end models.
In addition, the optimization of the game mainly includes:
-
Monsters are further baked with skeletal animation and GPU instancing, reducing CPU overhead.
-
In the particle effects part, some particles use GPU particles to share the CPU overhead. At the same time, avoid frequent display and hiding of particles, and do a good job in the reuse and recycling of particle effects. All particles are batch controlled via play/clear/stop, avoiding playonwake.
-
Character and monster bones are optimized to reduce animation overhead while compressing the animation size. Reduce the number of bones, such as removing bones such as fingers and toes, and re-skinning. A simple software Akeytsu is recommended to batch delete bones and then skin them with one click.
-
We reduce the use of convertToUINode. All 2D health bars, damage text, equipment currency drops, etc., of monsters, use a parent node for convertToUINode, and coordinate conversion is performed when monsters are injured or attacked, reducing the cost of coordinate conversion. At the same time, both the damage numbers and the health bar text use Bmfont and cooperate with the image. The damaged text avoids the animation of changing transparency. All the health bars and damage text have only one Drawcall.
Engine selection and efficiency improvements
Because we want players to experience the game during the holidays, we have only had 20 days of development time left. At this time, whether the engine can help us improve development efficiency is very critical. I am an old user of Cocos Creator. Compared with other engines, Cocos Creator has certain advantages in collaborative development and debugging. The most important point is that Cocos is very friendly to developers, the community is very active, and it is easy to communicate with the official engine bosses. Many problems can be received with timely feedback and solved.
During New Year’s Day, I studied the version update of v3.4 and the animation state machine. I was very excited, and “Girls Test Gun” was arranged immediately. I have to say, compared to the previous version, v3.4 has been flying. After releasing v3.4.1, I packaged the game and upgraded it. The new version fixes many details and is much more stable than v3.4. However, at present, lighting baking does not support automatic UV unfolding. It needs to be imported after external unfolding. I hope that the engine can optimize this part of the experience in the future.
Use of Plug-ins
In this development, we used many plug-ins and demos in the Cocos Store for reference, which helped us significantly improve the development efficiency. Thank you all!
Here is also recommended for your reference:
-
Shader Editor by Super Raccoon: Visual Shader editor, very suitable for Shader Xiaobai and artists, planning.
-
KylinsPostEffects by Kylinzi: post-effects framework package, there are various special effects (such as Bloom, Glow, spatial disturbance, LUT, etc.) that you can learn.
-
KylinsGraphicsDebugger by Kylinzi: 3D rendering visualization checker, which can be used in Lightmap UV detection, texture resolution size detection, Overdraw detection, etc.
-
Cocos Inspector by Chuange: Visual node viewer, which is very good in Drawcall optimization and node debugging!
Before the Spring Festival, many channels were closed in advance, so “Girls Test Guns” was launched on the vivo mini-game platform first. We will optimize it based on the feedback from the current players, focusing on strengthening the sense of attack, adding more characters and weapon types, etc. It will be launched to other platforms, native, etc., one after another. After that, the team plans to use Cocos Creator to develop more moderate-to-hardcore Internet games.
Reference links
Kirinzi, author of First Taste of Shader and Realizing Edge Light
Kirinzi, author of Shader’s Single Texture Realizes Dynamic Lighting of Weapons