HTML5 real-time multiplayer 3D games

Six weeks ago, we wanted to try to use HTML5 to implement a twitch3D game. In the end, we completed several games and were surprised to see what we achieved. You can try one of the games: Air Hockey
Currently, most browsers support WebGL well. three. js is a useful library for using WebGL. It provides concise APIs, built-in practical functions, communication modules, etc. Its disadvantage is... Few documents. However, you can use many existing examples to learn how to implement the functions you need. Some examples use state. js and dat. GUI to monitor frequency frames and modify settings. These two libraries are very useful. Dat. GUI can be used to fine-tune latency compensation algorithms and game appearances, such as light intensity and material attributes. We bought the 3D models required in the game (air hockey, mallet and puck) from TurboSquid, thanks to three. the Blender export plug-in of js allows us to easily convert the Blender scenario (using the purchased model) into json format for use in browsers. In the process of separating the model, adjusting the material and reducing the number of polygon, We honed Blender usage techniques to optimize the file size. If you are new to 3D on the Blender interface, WebGL and three. js will be difficult, because there are many unfamiliar terms and concepts. Since we are not familiar with 3D, it takes a lot of time to adjust the light and material. We tried various adjustments repeatedly, refresh repeatedly, and experience the results. When you see Mr. doob in RO. I think of a better way to give a speech on the ME project (which needs to be turned over, that is to say, before merging the final effect, separate each part into a separate small demo to facilitate effect adjustment. For network communication, we want to try to create a game that can respond to low latency in a timely manner and challenge the player's responsiveness. air hockey seems suitable. Mobile ice hammers and ice hockey require good network performance. As long as the network is delayed, the playability of the game is greatly reduced. Fortunately, WebSocket provides good performance. Our network solution is relatively simple, but this has already proved our point of view: it is feasible to use HTML5 to achieve interaction (twitch, I don't know how to translate) games !, The network solution is as follows: the client sends the gamer's ice hammer location to the server. based on the previous position, the server calculates the ice hammer speed of the two players, and then calculates whether there is a collision or new ice hockey speed and position. The server sends the latest ice hockey and ice hammer locations to the two clients. The client updates the interface. Of course, latency will complicate the processing process. If the data packet from the server end to the client takes 50 milliseconds, the player finally sees the interface 50 milliseconds ago, which makes it difficult for the player to hit the ice hockey. To solve this problem, the client calculates the latency between itself and the server, for example, 50 milliseconds. When the client receives the position and speed of ice hockey from the server, it uses the same calculation method as the server to calculate the position and speed of ice hockey after 50 milliseconds. Then the client shows the ice hockey to the budget position so that players do not need to calculate the location error caused by the delay to hit the ice hockey. There are also many popular Lag Compensation technologies to verify effectiveness, which can improve the playability of the game. However, our demo only uses the above method-game networking technology in 1990s, because it is enough for us to create an interesting, real-time, browser multi-player game. In addition, it is worth mentioning that everything should be subject to the server data, so that all real-time multiplayer games are so prevented from cheating.
JavaScript we think that developing in the form of HTML5 frontend + Node. js as the backend can reduce development time, because the client and server can reuse code. Especially in real-time games, because in this case, the frontend and backend must have the same analog computing logic. Compared with the previous project, the same logic reuse method in the client and server saves us about 30% of the time. We try to use RequireJS to write client code, but if we use AMD (Modules/AsynchronousDefinition) to encapsulate all our code, it will be unbearable at any time! Fortunately, we have discovered Browserify, which provides implementation encapsulation for many Node standard libraries. Such code events = require 'events' and class Game extends event. EventEmitter can run simultaneously on the server and client. Unfortunately, Browserify is not compatible with Backbone. js. Therefore, we have written 50 lines of CoffeeScript to replace the functions we need in Backbone. js. Choosing CoffeeScript instead of writing JavaScript directly is because it can streamline the amount of code, and all Node management tools (such as nodemon and forever) seem to support CoffeeScript. At first, we worried that it was difficult to debug code written with CoffeeScript, but it turns out that the js Code generated by CoffeeScript is extremely readable. Browserify uses the new Code ing standard, which helps to visit the code using Chrome developer tools. I believe it will not take long for us to directly debug CoffeeScript on the browser. You can directly debug CoffeeScript on chrome. http://ryanflorence.com/2012/coffeescript-source-maps/ ) Performance and optimization as mentioned above, we use Node. js to serve as the server, except Node. js. We don't think there are any other solutions that can meet our requirements for the server and the client to run the same code. So far, we are quite satisfied with Node performance. In our load testing, the 512 M Rackspace VM can support about 100 games at the same time. Because the performance is so good, we have almost no time to optimize it. The discussion about HTML5 performance inevitably involves GC (Garbage Collection, we found that GC pause may cause a significant pause in the game (and we were initially concerned that GC pauses might cause noticeable pauses in game play). Chrome does not have this problem, only FireFox runs Air Hockey to show obvious smoothness points (there are noticeable blips in smoothness). We think this is related to GC. However, we didn't spend any time on this to reduce the number of GC operations. Of course, we think that if you write code more carefully to reduce garbage, it may achieve better performance in Firefox. The biggest obstacle to game development on the browser is the lack of tools. We can see that there are a lot of game frameworks, but either there are limits on the development method of the game, or they are acquired or not released: we see a lot of frameworks, but they either constrain you into making your game a certain way, or they get acquired and are never released .) there are many excellent libraries and components for game development, but developers need to combine them by themselves. Flash and Unity have established a good development environment. The iOS and Xbox Live Arcade platforms also provide terminal-to-terminal solutions to create and release games. However, the browser platform is still too new. Writing HTML5 games is as troublesome as writing assembly code. During our development process, we could not find a scroll bar to adjust the color or light intensity of ice hockey. To get the results, we must run it or get the literal code from a very complex software. (If we wanted any of that we 'd have to build it or buy in (literally) to a heavier framework .) we are very happy to see the possibility of implementing a multiplayer game that is close to the control of the mobile terminal on the browser. As a fan of StarCraft and Halo, we are ready to see the appearance of the two in the browser, and we also hope to arouse your expectations for their appearance on the browser. Here we can get early versions of our game and game development tools: http://artillerygames.com .


Original article: http://blog.artillery.com/2012/05/realtime-multiplayer-3d-gaming-html5.html