Search

JavaScript is the most widely used web programming language and is increasingly used to implement sophisticated and demanding applications in such domains as graphics, games, video, and cryptography. The performance and energy usage of these applications can benefit from hardware parallelism, including SIMD (Single Instruction, Multiple Data) vector parallel instructions. JavaScript's current support for parallelism is, however, limited and does not directly utilize SIMD capabilities. This paper presents the design and implementation of SIMD language extensions and compiler support that together add fine-grain vector parallelism to JavaScript. The specification for this language extension is in final stages of adoption by the JavaScript standardization committee and our compiler support is available in two open-source production browsers. The design principles seek portability, SIMD performance portability on various SIMD architectures, and compiler simplicity to ease adoption. The design does not require automatic vectorization compiler technology, but does not preclude it either. The SIMD extensions define immutable fixed-length SIMD data types and operations that are common to both ARM and x86 ISAs. The contributions of this work include type speculation and optimizations that generate minimal numbers of SIMD native instructions from high-level JavaScript SIMD instructions. We implement type speculation, optimizations, and code generation in two open-source JavaScript VMs and measure performance improvements between a factor of 1.7× to 8.9× with an average of 3.3× and average energy improvements of 2.9× on micro benchmarks and key graphics kernels on various hardware, browsers, and operating systems. These portable SIMD language extensions significantly improve compute-intensive interactive applications in the browser, such as games and media processing, by exploiting vector parallelism without relying on automatic vectorizing compiler technology, non-portable native code, or plugins.

At the heart of your favorite games is the game loop. At the core of the game loop is control over the game clock. In each frame the game does some or all of the following: updates the game state, triggers timers, processes user inputs, renders graphics, and plays audio. Each of these operations must be synchronized using a virtual clock controlled by the game loop. This chapter explains how to implement a deterministic and efficient main loop for any type of game designed from the ground up to run in the browser.

Efficient use of system resources is essential to most game applications, to ensure that the game runs correctly and as smoothly as possible across a range of devices and browsers. Here, the term “resources” can refer to available memory, CPU execution time, or other processing or storage units in the system. Although JavaScript can be considered a rather high-level language, the data structures employed by JavaScript application code can significantly impact upon resource usage.

If you’re writing a 2D game in HTML5, chances are that you’ll want the user to have the ability to pick an object on the screen. More specifically, at some point, the user will need to select some item on the screen, or in your game, which may represent part of the world. We call this “picking” as the user is selecting what object they are interacting with. Consider, for instance, your standard social time-management game. The user is presented with a 2.5D play area where bitmaps (or “sprites”) are rendered with some perspective distortion on the screen. For the more advanced users, you can quickly saturate the play area with these sprites, often stacking many of them together, only leaving a few pixels visible between overlapping objects. In this environment, determining the picking result of a mouse click is quite difficult. The canvas API doesn’t provide any form of pixel-based selection and the large number of objects makes it difficult to brute-force the technique. This section will cover how to address performance and accuracy problems in canvas picking using a few old-school techniques that most of us have forgotten about.

Building an HTML5 game in the modern world is rife with difficulties. In addition to technical limitations and variations among browsers, you have the added burden of the current consumer world, which is predominantly driven by a boom in smartphones and tablet devices. What makes developing for this slew of heterogeneous devices difficult is the massive array of resolutions, physical sizes, and performance among them. For your web game to be successful, you’ll need to adapt it to take advantage of the many screen resolutions available so that users can experience it on as many devices as possible. To do this, you’ll need to adjust your game dynamically, depending on the current resolution, to achieve the desired game layout. This, at its core, is known as responsive design.

There is a great focus on making HTML5 games for mobile devices, which is good, of course, but core pro gamers are usually visualized as having a gamepad in their hands. So why not use it and deliver the full experience of a game using the Full Screen, Mouse Lock, and Gamepad APIs? The last API provides the ability to use a console's controller to play HTML5 games—how cool is that? With the W3C specification presently being written, we will have an API that is easy to implement, does not require any plug-ins to run in your browser, and is as simple as just plugging in your device and playing the game right away.

Designing an efficient method of loading game asset data for HTML5 games is essential in creating a good user experience for players. When games can be played immediately in the browser with no prior downloading there are different considerations to make, not only for the first time play experience but also for future plays of the game. The assets referred to by this chapter are not the usual HTML, CSS, JavaScript, and other media that make up a web site, but are the game assets required specifically for the game experience. The techniques mentioned in this chapter go beyond dealing with the standard image and sound data usually handled by the browser and aim at helping you consider assets such as models, animations, shaders, materials, UIs, and other structural data that is not represented in code. Whether this data is in text or binary form (the “Data Formats” section will discuss both) it somehow needs to be transferred to the player’s machine so that the JavaScript code running the game can turn it into something amazing that players can interact with.

TypeScript ( http://typescript.org ) is a typed superset of JavaScript that compiles to plain JavaScript. TypeScript is cross-platform, runs on any browser, and is open source. Microsoft created it, and it’s hands down one of the best languages for building HTML5 games. One of the great things about TypeScript, apart from adding typing to JavaScript, is that it allows you to start using some of the cool features of ECMAScript 6 (ES6) now, even though it may be years away from being finalized. This means that you can put to good use classes and other higher-level constructs that you find in languages such as C# and Java; moreover, TypeScript is incredibly similar to ActionScript 2 and 3. The final key advantage of TypeScript is that it outputs human readable JavaScript, plus you can use existing JavaScript libraries or inject the code directly into your TypeScript classes and start taking advantage of typing provided by the compiler.

It is a bit hard to imagine, but the Web wasn’t always as dynamic as it is today. Before I discuss WebSockets, let’s take a trip down memory lane.

If there’s one message emanating from the 3D content creation community these days, it’s “Ouch!” We all know why. There’s too much pain in the 3D content creation pipeline: incompatible formats, obsolescence of older material, platform limitations, and so on. Fortunately, there’s something we can do to ease the pain: create tools that adhere to open standards, such as COLLADA, a royalty-free, open standard schema for exchanging 3D assets.

Since Snow Leopard (10.6) was released in 2009, OS X has provided built-in support for COLLADA assets. So far, this support has enabled visualization of COLLADA assets in Preview and Quick Look. Developers using Quartz Composer have also been able to render COLLADA assets in their compositions, but until now, an API was still to be exposed. Now, with Mountain Lion (10.8), OS X has introduced a new 3D framework called Scene Kit that adds significant COLLADA functionality. This chapter explains how to use Scene Kit to render COLLADA assets. Incorporating a worked example, it offers an overview of Scene Kit and its relationship to COLLADA; shows how to integrate Scene Kit with Xcode; presents key aspects of the Scene Kit API like COLLADA scene import and scene graph manipulations, animations, and rendering; and touches on more advanced topics such as custom rendering. To get the most out of this chapter, it is recommended but not required that you have a basic knowledge of COLLADA and a working knowledge of Objective-C.

In computer graphics, frames are processed and painted on the screen by what some people refer to as the “animation,” “main,” “game,” or “update” loop. Personally, I prefer to call it “main,” “game,” or “update loop” for the sole reason that it’s standard practice in the industry to use this routine to perform other tasks besides painting pixels on the screen.

As hardware evolved, games went from two-dimensional affairs into the third dimension. This evolution also happened in the browser. Although two-dimensional rendering could be done through the use of the Canvas application programming interface (API) it wasn’t until the Web Graphics Library (WebGL) debuted that the graphics hardware was actually exposed to a lower level within the context of the browser. This API has now been implemented by every major browser vendor, making it possible to create a fully three-dimensional game without relying on a plug-in.

HTML5 games are becoming more and more important in the mobile gaming industry. There are already many casual and social games available in HTML5. Compared to native games, HTML5 games support real-time updating, click-to-play without the need for installations, and efficient development cycles.

Many of the most popular games have a multiplayer component. All but one of the top ten most popular games on Steam, a digital distribution and communications platform for PCs, are either designed for a multiplayer experience or contain support for multiplayer (see Table 12-1). As you will discover in this chapter, adding multiplayer support to a game increases the range of experiences that a player can have by introducing the elements of human psychology and social interaction to the game agents. However, adding real-time multiplayer can be rather tricky to implement correctly. Although it may seem daunting, by following some principled methods, you can add a new, exciting dimension to your game.

Since the early days of video game development when the programmer had to write the code plus design and create the levels without the aid of a game editor, the tools to create games have evolved into the must-have game development software we use today. Now the level editors are built into the development kits, and the developer’s job is much easier—but still filled with potential pitfalls. In the past few years, it has become common to decouple game level editor operations and functionality from game-specific features, so that the editor can be reused for more games and game types. The same thing has happened on the game engine side: engines have become more and more flexible and reusable. But problems remain. One big issue with game level editors is complexity and manageability. Once you have added many features to the editor, it will grow in source code size and complexity, and will become harder and harder to maintain and extend. Another problem is that you have to choose a GUI toolkit to create your interface. That can become a headache if you ever decide to switch to another GUI toolkit, since many editing operations are tied in with the UI code itself. To address the issue of changing GUI toolkits in these fast and ever-shifting times, we present a method of decoupling the visual user interface code from the non-GUI editing operations code in the game level editor or other tools. By separating the UI from core editing functions, you can change to another GUI toolkit in no time, leaving the editing operations code almost untouched. The decoupling operation can be accomplished via C++ editor core functionality code and various editor user interfaces using GUI toolkits like Qt, MS WinForms, WPF, MFC, HTML5/JavaScript, or even a command-line editor UI, all using the same editor functionality code as a common hub. Communication between the editor functions and the visual interface is achieved through a command system (basically the Command Pattern). We will also explore the architecture of a plug-in system using this command communication approach.

Any two-dimensional game is going to, at some point, have a separation between semistatic background content and dynamically animated foreground content. The background content can become a burden to the rendering pipeline, as it can easily consume megabytes of data as well as a hefty chunk of your rendering pipeline. In this chapter, I’m going to discuss a few strategies for overcoming this burden, providing trade-offs where your game may need them.

If you had told me ten years ago that I'd someday compile real-time, 3D C++ games into JavaScript so I could run them in web browsers, I would have thought you were crazy. Since then, software has shifted from retail stores and optical discs to online app stores and web applications. Internet users have become increasingly security-conscious, and JavaScript engines have gotten faster by orders of magnitude.

When it comes to optimization, both real-time 3D applications and web pages happen to share a common target: images. Images, whether they take the form of textures or tags, often make up the majority of the visual information on your screen at any given time. The metrics for optimization differ based on the medium, however. 3D apps, such as games, need images that can be loaded quickly, drawn fast, and take up as little memory as possible by taking advantage of hardware-supported texture compression formats. Web pages, on the other hand, are primarily concerned with the bandwidth required to download the images to your device, skewing heavily towards small, lossy formats like JPG. In other words, 3D apps are concerned about the size of the image in video memory and web apps are concerned about the size of the file on the server.

Back in Chapter 3, we covered the common pitfalls that cause a game to perform poorly, as well as the techniques to address them. Now we will tackle techniques to make your game look and feel just like a native one on mobile.

As developers, we tend to do a lot of repetitive tasks. We are constantly compiling code, packaging it, and deploying it to different places. As the project scales, the complexity of these processes continues to grow. If there is one constant among humans, it’s that we are not great at doing repetitive tasks, especially complex ones. Sure, we can do one single task over and over again, but anything more complicated, and the system quickly breaks down. This isn’t anything new; Henry Ford realized it when he took advantage of the assembly line to lower the cost of making cars. We can do the same thing for our own code by taking advantage of automation.

Making games is exciting, exhilarating, and hugely fulfilling. Making good games isn’t easy. Making great games that work on multiple platforms is . . . what this chapter is about.

For a game to be enjoyable, smoothness is critical. A smooth game can feel lifelike and amazing; without smoothness, a game will be sluggish and annoying, even with the best art.

When we consider mobile HTML5 games, we usually compare them with native games. One might think that native games are always superior to browser games or that browser games can never touch native games in performance. But check out the top 10 games in the native app market. Often you will find that many of the top-selling games do not use 3D graphics, particle effects, and so on. It seems that we are able to create similar kinds of mobile games in the browser with HTML5.