Developing mobile 3D games based on Three.js+WebGL

one, introduction

In this article, we will use WebGL technology to develop a mobile game that can run on mobile devices at a frame rate of 60FPS. The style of this game is similar to Flappy Bird and Temple Run. It is called Winter Rush. This article focuses on the three.js technology related to WebGL used in the game development process.

The image below shows a snapshot at the beginning of the game.

During the game, the player can use the left and right arrow keys (or tap left and right on the screen) to move left and right.

two, Why 60 FPS is important

The higher the frame rate, the smoother the game content will be rendered. For a game product, the smoothness of motion effects and the timely response of controls are particularly important. Computer screens usually refresh at a frequency of 60hz, so this is our biggest constraint. Please note that 60 frames per second is just an ideal target, but in fact any frame rate above 30 FPS will look good.

Paul Lewis has conducted in-depth research on this aspect. To this end, he has set up a special website to discuss relevant technologies. The website address is http://jankfree.org/.

I am very proud to tell you that the sample project provided in this article can work at a frame rate of 60FPS on iPad 4th Gent and Nexus 4 mobile phone.

To achieve my desired FPS target, I adopted the following approach.

three, Simplify the 3D scene

Geometry: Simplify the geometry in your scene by reducing the number of meshes and the number of vertices per mesh. Remember: low poly is always cool! In this game, only two cylinders are actually used to implement the tree effect: one for the leaves and one for the trunk. In the game, when moving on the track, only 10 trees are actually placed on the track.

Materials: A large part of the 3D engine's computational cost is spent on calculating the lighting effects of each geometric surface in the scene. The fewer lights there are in the scene, the lower the computational cost. The material computation costs in the Three.js engine are divided into the following order from low to high:

(1) Basic material: This is the most basic material. It does not require lighting calculations. You can do a lot of things using Basic materials and image textures.

(2) Lambert material: This material can create a less glossy appearance.

(3) Phong material: This material can achieve a very glossy appearance. In my tests, the Phong material proved to be much more expensive than the Lambert material. For example, in the example provided in this article, if you switch from the Lambert material to the Phong material, the FPS value on the iOS platform will drop from 60 to 15.

Four, Object Reuse

This is probably the most important rule to follow for a high performance web experience. After the objects are created during the initialization phase, try not to create new objects during the game. This will avoid memory "thrashing" - which can cause the browser to "choke". Website http://www.html5rocks.com/en/tutorials/speed/static-mem-pools/
There is a great article on using JS object pools here. In this game, I reuse 3D objects (such as trees) by resetting their positions when they are behind the camera. In each frame, it is checked whether the object is behind the camera. If the object is behind the camera, its position is reset away from the track. It should also be noted that in this game, I used the THREE.Fog technique to achieve the purpose of occluding trees. On the other hand, of course, this is also a fairly popular solution.

five, Mobile track

The snow floor of the track in the game is a flat mesh. We use the Perlin noise algorithm to generate the terrain height (i.e. the Y-coordinate of the vertex). This approach allows for random but smoothly changing potholes. To achieve the appearance of a natural moving track, we used the following techniques:

(1) In each frame, we move the entire floor a small distance towards the camera, and the movement speed is based on the player's operation speed.

(2) In the program, we check if the floor has moved behind the camera by more than a predefined STRIP_WIDTH amount. If so, we reset the floor position STRIP_WIDTH backwards along the track. We then recalculate the terrain height - this is done by increasing the Perlin noise position by the STRIP_WIDTH value.

In-game, this looks like the screenshot below.

six, Simplifying collision detection

In Three.js, you can do very accurate collision detection for each face by using Raycasters. Lee Stemkoski provides a great example of this approach (http://stemkoski.github.io/Three.js/Collision-Detection.html). However, this approach can be expensive, requiring calculations for every pair of objects that could potentially collide. In many cases, you can simplify collision detection by assuming that each object is a sphere, and simply measuring the distance between them.

Note that you may need to manually adjust the collision distance and collision box position to achieve a more playable feel. However, there is also an issue where the player may hit an object that is off camera when strafing. The solution to this is to move the player shot box a little further away from the camera.

seven, Implementing shadow effects

In Three.js programming, the EffectComposer class allows you to execute multiple post-processing shaders in sequence. This approach requires the use of multiple off-screen buffers to pass the results of the previous shader to the next one. On mobile devices, this approach gives suboptimal performance. The solution is to combine the multiple shaders we write into a super shader. Of course, achieving this is just a matter of copying and pasting each shader code, but you also have to consider the proper order. For our Winter Rust game, we combined the Vignette, Brightness/Contrast and Hue/Saturation shaders into one large shader. In addition, it should be noted that some effects are too GPU-intensive for mobile devices, most notably blur-related techniques.

eight, Time Control

For the animation loop, we should use the requestAnimationFrame method and apply a time offset to the animation. This makes the animation speed independent of the game frame rate. The travel distance should depend on the actual time that has passed instead of the number of frames. This technique will not increase the FPS of your game, but it will increase the speed perception of your players if the FPS is too low. Please refer to the relevant code below:

 //kick off animation 
 
 var clock = new THREE.Clock(); 
 
 clock.start(); 
 
 gameLoop(); 
 
 function gameLoop(){ 
 
    requestAnimationFrame(gameLoop); 
 
    var delta = clock .getDelta(); 
 
    //use delta to determine all distances traveled 
 
    movePlayer(MOVE_SPEED * delta); 
 
 }

Nine, Run on target device

Once you have identified your target devices, you will want to continually test on those devices and keep an eye on the FPS values. The iOS simulator in OS X is an excellent tool for debugging iOS issues while developing on the desktop; however, be aware that the simulator does not reflect the performance of an actual device. Adobe's Edge Inspect (https://creative.adobe.com/products/inspect) is another excellent tool that enables you to easily connect multiple mobile devices to a local web page. It will automatically reload the page when it changes, and also gives you access to Android console errors.

ten, JS library for mobile development

This section lists several famous js libraries used when developing my game, they are:

• Three.js: This one goes without saying;
• Zepto.js: This is a great jQuery alternative that is 25K in size and is fast on mobile devices.
• Howler.js: This is an excellent sound effects library that can handle the sound problems of various mobile devices;
• TweenLite: This library makes it easy to implement easing effects, and is efficient on mobile devices.

eleven, Which devices can run WebGL?

The number of devices supporting WebGL is growing rapidly. In addition to running on all major desktop browsers, WebGL content now runs on iOS and Android devices without major issues.

However, not all WebGL-capable devices are created equal. WebGL is a demanding technology, so running on relatively older devices is recommended to focus on running the most basic content. For example, the iPad 2 was launched in 2011 and it can run WebGL, but its capabilities are very limited. WebGL generally runs well on mobile devices manufactured in the last two years. My main mobile testing devices are a 4th generation iPad (manufactured in 2013) and a Nexus 4 (manufactured in 2012), which provide a relatively good reference baseline.

twelve, Areas for improvement

It is recommended that interested friends try to add the following items to the project while studying the example project provided in this article:

• Tilt control on mobile. I chose to use tapping to implement tilt movement on mobile because it more closely matches the desktop experience. Note: using the tilt accelerometer is a completely different control system and you may want to try that alternative.
• Developing an enthusiast-type desktop version. Since I wanted to make this game run as well as possible on slower devices, I had to give up on some of the fancy effects and geometry. So, it should be better to use richer graphics when building a desktop version.
• Using Android Fullscreen API
• Take the HTML menu technique used in the program and float it over the WebGL scene, maybe add some nice shader wiggle transition effects, etc.

Thirteen, summary

This article briefly describes the key points of using Three.js to develop a 3D game for mobile devices. ***, I sincerely hope that readers can develop WegGL game products with good performance on mobile devices.

Note: The download address of the example game Winter Rush in this article is https://github.com/felixturner/winter-rush.

[Exclusively translated by 51CTO.com. Please indicate the source when reprinting on partner sites]