Search

A multi-crossing (or n-crossing) is a singular point in a projection at which n strands cross so that each strand bisects the crossing. We generalize the classic result of Kauffman, Murasugi, and Thistlethwaite, which gives the upper bound on the span of the bracket polynomial of K as 4c_2(K), to the n-crossing number: span is bounded above by ([n^2/2] + 4n-8) c_n(K) for all integers n at least 3. We also explore n-crossing additivity under composition, and find that for n at least 4, there are examples of knots such that the n-crossing number is sub-additive. Further, we present the first extensive list of calculations of n-crossing numbers for knots. Finally, we explore the monotonicity of the sequence of n-crossings of a knot, which we call the crossing spectrum., Comment: 28 pages, 19 figures

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.

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.

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.

An n-crossing is a point in the projection of a knot where n strands cross so that each strand bisects the crossing. An übercrossing projection has a single n-crossing and a petal projection has a single n-crossing such that there are no loops nested within others. The übercrossing number, ü(K), is the smallest n for which we can represent a knot K with a single n-crossing. The petal number is the number of loops in the minimal petal projection. In this paper, we relate the übercrossing number and petal number to well known invariants such as crossing number, bridge number, and unknotting number. We find that the bounds we have constructed are sharp for (r, r + 1)-torus knots. We also explore the behavior of übercrossing number under composition.