The Artillery Blog

Browser Garbage Collection and Frame Rate

2012-10-27T00:00:00-07:00

Realtime games are a different breed of software than data-driven websites. A harsh constraint for game developers is that, in order to get 60 frames per second, your game loop needs to execute in less than 16.66ms. If you know your target CPU and your execution time budget, you can work within this constraint. But when you’re writing a game for the browser, you have one more thing to worry about: the Javascript VM needs to pause periodically to collect garbage and manage the memory heap.

The good news is that modern browsers have vastly improved the efficiency and common-case runtime of their garbage collection phases. But are they good enough to make games with smooth animation today? How much garbage can your game safely create? Once your game loop fits into the CPU-time budget, can you know that it will be scheduled fast enough? Are you going to meet some target frame rate for the 99th percentile rendering time? The answers depend strongly on the client (hardware and browser), but we can make some measurements on typical computers and make some useful generalizations.

Methodology

Let’s assume a typical game will have an animation loop which is gated by window.requestAnimationFrame(), with the hope that the browser will schedule the loop at a stable 60fps. Also, assume that there is a single function which computes the next game state and “draws” it (to the DOM and Canvas). If we monitor the inter-arrival times of these requestAnimationFrame() calls while watching the JS heap size we can see if garbage collection pauses are responsible for dropped frames.

The following example runs in Chrome, which supplies window.performance.now() and window.performance.memory.usedJSHeapSize (when invoked with --enable-memory-info). Similar affordances exist in Firefox and Safari.

We can also make some adjustments to the implementation of computeNextGameStateAndPaint() to see the effect of different amounts of garbage generation.

After this runs for a while, frameDataList will contain a list of samples which are easy to analyze:

> window.frameDataList
[16.672734, 133128],
[16.183574, 128228],
[39.847293, -12158528],
[16.974714, 119222],
[16.672734, 140248]

Correlation between slow frames and GC events

Garbage collection events aren’t explicitly announced by the VM, but we can infer that one has just happened whenever the JS heap size decreases between two samples. We might undercount the number of garbage collection events by sampling too slowly, but we can’t overcount it this way.

Here are some plots showing the inter-arrival times of a series of animation frames, along with some decoration indicating changes to the size of the JS Heap. The bubble radius is proportional to the magnitude of the heap size change in the last frame, and color indicates the sign. This data was collected using Chrome 22 running on a high end laptop.

Here’s an example of an absurdly high amount of garbage generation with 200,000 anonymous objects becoming unreachable every frame. While this is an artificial and unrealistic memory-use profile, it still produces thought-provoking results. Notice how bi-modal the frame times are when there’s a lot of garbage being generated inside computeNextGameStateAndPaint(). It’s clear that the slow frames which do occur almost always occur in conjunction with a garbage collection pass.

If you can read this, jqplot failed to run. Sorry!

As we dial down the rate of garbage generation, the situation improves materially. GC pauses start to fit inside the gaps between frames, and predictable 30fps is within reach.

If you can read this, jqplot failed to run. Sorry!

At 2,000 objects/tick, 60fps is looking rock-solid.

If you can read this, jqplot failed to run. Sorry!

Conclusion

Too much garbage will certainly cause stalls that impact frame rate, but the critical amount of garbage is discoverable early in the development cycle of your application. It is possible to get stable fast frame rates provided you stay inside your per-frame CPU budget and keep the rate of garbage generation under control.

Play Powderkeg!

2012-10-04T00:00:00-07:00

We’re very proud to announce Powderkeg, a synchronous, real-time, action-packed multiplayer browser game! Give it a try at powderkeg.artillery.com! (Google Chrome or Firefox is required.)

Powderkeg represents the first step in building the Artillery Platform, which will enable game developers to easily build high-quality games that run in the browser without plugins. When speaking with developers the feature which is most attractive is easy multiplayer integration.

Imagine building a game where player input all looked the same even if players were on separate continents, like a game console whose controllers had really long wires. Now imagine if you didn’t host servers yourself and you never needed to write a line of lobby or matchmaking code. This is what we want to offer as part of the platform.

We’ll present the details of our platform later on. In the meantime, go ahead and play a few rounds, and let us tell you about how it works.

Network Synchronization

Powderkeg works by running the game simulation in exactly the same way on each client. This is accomplished by initializing each client’s pseudo-random number generator with a server-provided seed and transmitting the same input to each client. Clients send their input to the server, the server quantizes all input into frames (or “ticks”), and over time each frame is sent to each client which replays the input in its own simulation, resulting in the game you see.

If the client waited for input before showing any kind of player movement, you’d notice a delay between pressing an arrow key and your player moving. That’s why the Powderkeg simulator supports “hinting” – when you press a key, the runtime asks the simulator if your player can actually move in that direction and moves him if it can. The result is very responsive game which mixes strategy with split-second skill.

Dealing with Lag

Latency is problematic for all networked, multiplayer games. Everyone always wants to connect to a nearby gameserver with a low ping, and players with high pings incur hatred and pitchfork mobs. TCP, which WebSockets are built upon, compounds the problem due to its packet-ordering guarantee.

We thought it would be a good idea to provide information about each players’ connection, just as you’d find in any large multiplayer game, so that players can easily identify who is slowing down the game. On each player’s info square you’ll see a “signal meter” that represents that players’ connection quality. If you mouseover the meter you’ll see some more details:

The tooltip shows information collected during the last run of the network latency test. “Noise” is the percent of messages which took longer than the standard deviation, “ping” is the average ping time of non-noisy packets, and “max” is the longest sample collected.

Powderkeg performs a network latency test when you open the game to test the delay between you and our five game-serving regions around the globe. When you click “Find a Match,” your latency is used to match you with people closest to you geographically to ensure low lag and a glitch-free experience.

Graphics

Most of the game art is laid out in 10 sprite sheets – explosions, powerups, environment, one for each color player, and a few more. The UI is mostly HTML and CSS, when integrates with our game’s runtime easily. Artwork and UI assets are loaded intelligently so that anyone opening powderkeg.artillery.com will see a menu as quickly as possible.

Powderkeg should display at a constant 60 frames per second on Chrome and Firefox. You shouldn’t see any jitter despite the hundreds of entities used to make the map and explosion tiles. Because of our focus on multiplayer support, we didn’t spend a lot of time on building our own graphics engine or WebGL, and it turned out that using the canvas element is fast enough.

All of the art in the game was produced by Adam deGrandis, a multi-talented artist and all around awesome person. If you’re looking for an artist for your next game, we recommend him with the highest of honors.

Sound

We found high-quality sound effects and music from Soundrangers and AudioJungle. Since we built the game targeting Chrome and Firefox, getting all of that audio into the game was pretty easy. The HTML5 audio tag works well in the latest versions of Firefox, but the Web Audio API in Chrome is even more straightforward.

What’s Next

We’re pretty excited about what we’ve accomplished with Powderkeg so far, and we’re even more exited about what’s next. We’

If any of this interests you, please sign up for our mailing list to receive beta invitations as our platform becomes available. If this is so interesting that you’d like to work with us, great news! We’re hiring.

Have fun!

Welcoming Our New Investors

2012-08-03T00:00:00-07:00

At Artillery, we are committed to an ambitious, long-term vision. We believe that it could take five to ten years to truly achieve our goal of building the world’s best gaming platform inside the browser. We know the path to get there is difficult, and we know that we need a world-class team of investors, advisors and employees.

That said, we’re thrilled to welcome our new venture investors:

First Round Capital
Signia Ventures
Lowercase Capital
CrunchFund
General Catalyst
Andreessen Horowitz

We also appreciate the support of the many great angels that have helped us build our company so far: Ben Ling, Kevin Colleran, Alison Rosenthal, Tim Ferris, and too many others to list here.

Kent Goldman of First Round Capital and Rick Thompson of Signia Ventures will be joining our board of directors.

We feel lucky to have such a strong group of supporters who share our vision. To all of you: Thank you for your support. We will make you proud.

Six Impossible Problems

2012-07-09T00:00:00-07:00

Alice laughed: “There’s no use trying,” she said; “one can’t believe impossible things.”

“I daresay you haven’t had much practice,” said the Queen. “When I was younger, I always did it for half an hour a day. Why, sometimes I’ve believed as many as six impossible things before breakfast.”

– Lewis Carroll

We’re pretty optimistic about the possibility of bringing console-quality gaming to the browser. There are already lots of turn-based resource-collection/”click-and-wait” games and plenty of casual puzzle games, but we believe the platform is ready to take a step forward. We’re talking about real-time, multiplayer gaming – specifically high-quality graphics, content-rich game worlds, and everything else that gamers expect from a console or native PC game. In fact, most of the individual pieces have been proven possible in the dozens of brilliant HTML5 demos that appear every month.

Despite these wonderful demos there are some really hard problems in front of us. We’re excited but a little daunted by what needs to be done. At Artillery, we know we can do it, but we know we also need to build a really great team. The following is a taste of what we want to accomplish. If this stuff excites you, get in touch with us.

Without further ado, here are six impossible problems we need to solve over the next few years to make our vision a reality:

1. Let players begin playing rich, triple-A games seconds after clicking a link.

“Impossible! Games today are multi-gigabyte affairs. You can’t download that much in seconds!”

–Anonymous Gaming Industry Executive

This is not an easy problem. But is it impossible? Consider two things: First, you probably don’t need all of a game’s assets to render the opening scene of the game. Second, there’s plenty of ways that the server could compress and/or gracefully degrade game assets depending on client bandwidth. Here are just a few of the things we’ll do if necessary to make content-rich games load in seconds:

Build an asset streaming system that can look at a game, figure out exactly which assets a player will require at each point in the game, and get them there just in time.
Build tools to automatically create degraded versions of assets, and have the client download the degraded assets first, so the player can start playing the game immediately. Then, stream the high quality assets as quickly as possible, and swap them in as they finish downloading. Some of these techniques are simple: You can get nearly a 10x reduction in PNG file size by converting a 24-bit image to a 64 or 256 color paletted image. For 3D games you could ship lower-poly meshes, lower-resolution textures, and round off significant digits from mesh vertex positions. This would all need to be done with minimal effort on the part of the artist, of course.
Invent custom compression techniques. Can we take advantage of the inherent redundancy of animation sprite sheets to get better compression ratios than a general-purpose image compressor can achieve? Can we do better 3D mesh compression by exploiting the spatial structure of the mesh?
Build tools for procedural content generation that work for game designers. What if game designers could procedurally generate a map that they mostly like, and then make tweaks to it as needed? The client would download both the inputs to the procedural map generator and the tweaks, instead of an entire raw map file.

2. Help game designers create real-time, multi-player games without knowing anything about networking.

If you look at all the brilliant indie games being produced these days, it starts to look like it’s a new golden age of gaming. But why are there so few multiplayer indie games? We believe it’s because indie developers don’t have the time or resources to design, debug, and operate networked, multiplayer games. We’re working on building a JavaScript game runtime which allows developers to build multiplayer, networked games as though they were building a non-networked multiplayer console game.

This is easy to do for turn-based games, or for games that are more forgiving of network latency, like tower-defense games, but it’s a lot harder to do for latency-sensitive, arcade-style games. We believe we can do it in a way that allows game designers to forget about networking and focus on perfecting their gameplay, and yet makes the game feel perfectly responsive to players even when there’s 100ms of latency or more between them and their opponents.

For this to really work, we also need to make it totally effortless for developers to build games that can run in the browser and on our servers. Otherwise, we don’t have a way to prevent elementary cheating techniques from working.

Sound difficult enough? We’re already working on solving this problem for one type of game (more on this later), but different types of games require different techniques for multiplayer networking, client-side prediction, and lag compensation. We will eventually support FPS games, RTS games, MMO games, and any other type of game you care to mention. If you’ve got experience in multiplayer game networking or distributed systems, and are curious about how we plan to do this, we’d love to talk with you about these problems.

3. Create a hosting service for the most latency-sensitive web applications ever built.

The engineering involved in creating a multiplayer networked game is not easy. In addition to the difficult programming involved there’s the loathsome task of operating a cluster of servers. That’s not an attractive prospect for most small game studios.

We want to build a game hosting system that allows studios to publish multiplayer games onto our platform with one click. We’ll host the game servers, we’ll serve game code and assets to players, and we’ll connect players to the games through lobbying. We’ll be running the lowest-latency web applications ever built. Google returns search results in about 250ms, but 250ms is an eternity when it comes to competitive multiplayer gaming. To keep latency down, we’ll obviously have to make our backend code as fast as possible, but we’ll also have to put servers near players, and scale game servers automatically to handle increased load.

4. Build game development tools that allow designers, artists, engineers, and play-testers to collaborate in a way that works for everyone.

There are amazing tools available for game developers: engines, integrated development environments, level editors, etc. Unfortunately, few of them let you target the browser platform natively, and individual libraries still need to be strung together. What’s missing is a single, hosted integrated environment that makes game development and collaboration as easy as possible.

We need to build a game development environment that does it all: asset management, collaboration and version control, a short feedback-and-iteration cycle, and the ability to easily publish a game to Facebook, standalone sites and Steam. It should give you everything that’s available in professional engines, but it needs to be hosted and run in the browser – no software to install, seamless collaboration with your team, and fast updates so that bugs are fixed and features are improved.

5. Make high-fidelity, resource-hungry games run perfectly in JavaScript.

We know that there’s always going to be a performance edge available to game developers who build native games in C/C++, and we know there will probably always be developers who want to get close to the metal so they can squeeze out every last drop of performance. But really great games are still being made in Flash, and we’re confident that the games eventually built in JavaScript + WebGL will be even better. V8 is insanely fast and WebGL is clearly a viable way to do hardware accelerated graphics in the browser. You’ve seen the demos. The games are coming.

So does that mean we can just sit back and wait for Google to keep making Chrome and V8 faster? Nope. Our platform will still have to be the fastest available. It’ll need to provide 2D and 3D graphics, collision detection/physics, and whatever else game developers need to make great games in the browser. All that code is going to have to run as fast as possible. It might, for example, have to be garbage-free to avoid triggering garbage collection pauses, or we might need to figure out the best way to let developers run path-finding or AI logic in WebWorkers.

We will also need to take advantage of new browser standards and APIs as they become available, including the Gamepad API, Pointer Lock, WebRTC, and whatever else we need to use to make our vision a reality. We’ll be as close to the bleeding edge as we can get while still having a large-enough installed base of players. (We’re especially psyched to be developing for the browser without have to worry about IE8 compatibility.)

6. Increase the speed of light to reduce network latency.

Ok, this one we’ll admit is impossible.

Just kidding.

Maybe.

If you find yourself salivating at the prospects of working on these problems, we are hiring. If you think we’re crazy, and want to tell us exactly why, we’d still love to talk to you and try to convince you that yes, we really are crazy, but that we’ve also got a shot at solving all these problems. Let us see if we can convince you to help us solve them.

Consoles Are Dead

2012-06-27T00:00:00-07:00

Consoles are dead. It’s time to lay down the controller, and pay our respects.

For the last 25 years, I’ve owned almost every single console that there was. From the original Nintendo, to the Playstation 3, I count over 15 consoles and portables. Many were epic, like the Nintendo 64, while others wore out their welcome a little too soon.

Some of my favorite memories were when my friends and family would gather around a new game and we’d duke it out for hours. The really great games and consoles usually nailed one thing really well: Multiplayer. There was nothing like the thrill and competitive spirit of nailing the perfect Dragon Punch or getting the red shells in Mario Kart’s battle mode. Twenty years later, my friend Yuji and I still fire up Street Fighter II on an original SNES.

Lately, it seems like some things have gotten lost. Games sometimes resemble movies more than they resemble games. Gameplay has been replaced with cut scenes. Fancy graphics and recycled sequels turned into fancier graphics and fancier sound. Gamers like myself were seduced back to the computer to play games like Counterstrike and StarCraft while I waited for the next Halo to come out.

Unfortunately, as a gamer on the go, these don’t meet my needs anymore either. I’m looking for something rich yet something that I can pull up when I want. Something that I can play with my friends and something that is as accessible as pulling up a website. Millions of people are playing social games, but most of them are still just isometric resource-collecting games. We’re not faulting anybody — we all need to make money. However, we see a better world out there.

It’s time to kill the console… or better yet, build a better one. One that lives in a browser and can be accessed from any device. One where I can play against my brother just by sending him a link and we’re dropped into an experience together. We’ve assembled a team to bring back that joy back again.

Experiments with WebSocket Performance

2012-06-12T00:00:00-07:00

Networking is one of the biggest obstacles facing HTML5 game developers. While WebSockets provide a TCP-like communication mechanism, game networking often relies on UDP, and there’s no way to do UDP-like communication in the browser without a plug-in.

Why do games often rely on UDP? Imagine you need your server to send a small message to a player every 100ms. In a perfect world there’s relatively little difference between using UDP and TCP for such a task. You send the player a message, and some amount of time later, the player gets it.

Of course, we don’t live in a perfect world, and in our imperfect world packets occasionally get dropped. If you’re using UDP, and a message gets dropped, the player only has to wait an additional 100ms to get the next message (assuming that it isn’t dropped as well). That is, new messages are sent out every 100ms, and the loss of one message can’t delay the arrival of the next.

With TCP, the player’s computer will receive the packet containing the next message 100ms after the missing message, but the operating system won’t send that data to the game program, because it will have detected a gap in the TCP transmission. That gap needs to be filled in before the game program gets to see any new data. How does it get filled in? The sender will wait a certain amount of time (see Computing TCP’s Retransmission Timer for more information) for the receiver to send an acknowledgement of the missing packet. After that time has elapsed and no acknowledgement has been received, the server will retransmit the packet that was dropped. Depending on how long the retransmission timeout is, this can add up to a sizeable delay, which in turn can cause a noticeable blip in the responsiveness of your game. Worse still, subsequent messages can’t be received by the game code until after this retransmission has happened, so one dropped packet can slow down several others.

But what’s the real effect of all this in practice?

Methodology

Let’s take some really simple measurements. We’ll run a server that accepts WebSocket connections, and bounces every message it gets back to the client. Now, we can write some javascript that establishes a connection, sends a bunch of messages to the server, and measures how long it takes for each message to be sent back. Once we’ve gathered this data, we can make a histogram. We’ll do this in a way that resembles the situation I described above, in which messages are sent out periodically, without waiting for a reply first.

In the tests below, I used ipfw (Mac OS X’s firewall/router tool) to model different amounts of latency and packet loss, and took 250 samples.

Measurements

What should we expect to see when we run this experiment? Most of the measurements will be clustered around a single value, specifically the round-trip-time between the client and the server. But if any packets get dropped during our test, we’ll see a few messages that take longer to return.

So the two parameters most significant to our results are the baseline round-trip-time, and the packet loss rate.

Before I show you all the data I gathered, go ahead and run these measurements from your own machine: (Note: you’ll need to be using Chrome or Firefox for this to work. If you don’t have a recent browser, scroll down to see the measurements I’ve already taken for you.)

Collecting latency data: 0/250

Hopefully, your connection doesn’t have any packet loss right now, and so you’ll just see one bar in the above histogram. But we’d like to see the impact of varying rates of packet loss, so we’ll have to somehow induce the packet loss ourselves.

On OS X, it’s easy to model latency and packet loss rate with the ipfw tool. First, I’ve simulated some different packet loss rates on a low latency connection. First, I ran these commands (as root):

$ ipfw add pipe 1 ip from any to any out
$ ipfw add pipe 2 ip from any to any in
$ ipfw pipe 1 config delay 12ms
$ ipfw pipe 2 config delay 12ms

This will result in a round trip time of about 50ms. (The packet is delayed by 12 ms twice in each direction, for a total of 48ms, which is pretty close to 50.) After I ran these commands, I measured the message latency at a variety of different packet loss rates, and made histograms from the results.

If you can read this, jqplot failed to run. Sorry!

50ms Latency, 0.1% Packet Loss

Now, let’s add some packet loss.

$ ipfw pipe 2 config delay 12ms plr 0.0005

This will mean about 0.1% of messages will get dropped. It’s 0.1% because they have a 0.05% chance of getting dropped on the way out and 0.05% on the way back. (Yes, I know it’s actually 100 × (1 - .9995²) percent. 0.1% is close enough.)

If you can read this, jqplot failed to run. Sorry!

50ms Latency, 1% Packet Loss

Now we bump it up a little further.

$ ipfw pipe 2 config delay 12ms plr 0.005

If you can read this, jqplot failed to run. Sorry!

50ms Latency, 5% Packet Loss

$ ipfw pipe 2 config delay 12ms plr 0.025

If you can read this, jqplot failed to run. Sorry!

100ms Latency

I ran the same experiments again, with 100ms of latency.

$ ipfw pipe 1 config delay 50ms
$ ipfw pipe 2 config delay 50ms

If you can read this, jqplot failed to run. Sorry!

100ms Latency, 0.1% Packet Loss

$ ipfw pipe 2 config delay 25ms plr 0.0005

If you can read this, jqplot failed to run. Sorry!

100ms Latency, 1% Packet Loss

$ ipfw pipe 2 config delay 25ms plr 0.005

If you can read this, jqplot failed to run. Sorry!

100ms Latency, 5% Packet Loss

$ ipfw pipe 2 config delay 25ms plr 0.025

If you can read this, jqplot failed to run. Sorry!

Conclusion

The most useful plots to look at above are probably the ones for 0.1% packet loss - a connection with 1% packet loss is already verging on unusable for most people. Even at that low rate, we see that about 3% of messages arrive late.

Look at the percentage of messages that arrive “on time” in each plot. It’s far lower than you might naively expect based on the packet loss rates. For instance, at 1% packet loss, only about 95% of messages arrive on time. This is because one dropped packet delays not only the message that was in that packet, but also several subsequent messages. This is exactly why TCP isn’t the right choice for certain types of multiplayer games.

We’ll be working hard to make multiplayer html5 games a reality, despite these obstacles. Stay tuned!

Reducing Polygon Counts and File Sizes

2012-05-29T00:00:00-07:00

One of the reasons we built Air Hockey was to test how easily we could use a professionally-made 3D model in WebGL. I grabbed the best-looking air hockey model off of TurboSquid, imported it into Blender, and separated the table, mallet and puck into their own models. I converted each model into ThreeJS JSON format using the ThreeJS Blender exporter, loaded them into our scene, and ka-pow! It looked like a real air hockey game.

At some point we noticed that the model file sizes were really big. The three JSON model files were 1.3 MB combined, not including the JPEG for the table’s surface. At some point I was tweaking the puck in Blender and it dawned on me that these models were high-detail, photographic-quality models! The air hockey meshes were much more complex than we needed them to be, and I figured that by making the models simpler (and exporting fewer vertices) I could reduce file size, speed up load time and maybe increase performance of the game. It turns out that there’s a whole category of 3D models called low-poly models, i.e. models that are specifically designed to have far fewer faces/vertices/polygons.

So, how do you reduce the complexity of the models? If you’re using Maya, I’m told that there’s a Reduce menu item under the Mesh menu. I’ve been using Blender (because it’s free) which allows you to add “modifiers” to objects, including one called “Decimate”. The Decimate modifier lets you easily reduce the complexity of a model. It does this by letting you control a ratio which scales down the number of faces in the model, and you can keep decreasing the ratio until you are no longer happy with its appearance.

The original mallet model has 9,504 faces. Setting the decimation ratio to 0.004 reduces this down to only 38 faces, but the model looks more like modern art than an air hockey mallet. A reasonable ratio turned out to be 0.15, which resulted in 1,424 (≈ 9,504 × 0.15) faces. However, Blender’s decimation sometimes results in strange choices of polygon removal – an artifact can be seen on the mallet where some vertices were merged, but nobody seemed to notice this while we were testing it.

I also exported each sample using the ThreeJS exporter and gzipped the result. It turned out that the file size also scales linearly with the number of faces in the model:

In Blender, you don’t need to decimate the entire model. For example, just decimating the corners, legs and trim (but not the blue sides) of the table reduced the number of faces and the file size by around 50%.

This was a really easy way to make our game load faster, and we know optimizing load-time is going to be a huge problem in bringing great games to the browser. However, the Decimate modifier probably won’t produce as attractive a model as a human could with the same polygon count. We’re confident that, for our next game, the right thing to do is work with an artist who is great at building low-poly models. But if you’ve found a model you really love and want a way to get the file size down, this should do the trick.

Real-time synchronous multiplayer 3D gaming with HTML5

2012-05-14T00:00:00-07:00

Six weeks ago we set out to see if we could build a real-time, “twitch” 3D game in the browser using HTML5. We built a few games and were pleasantly surprised with what we achieved.

You can test one of our creations here: Air Hockey

Graphics

WebGL has pretty good browser support at the moment, and three.js is an essential library because of the WebGL boilerplate it handles for you. It has a clean API, built-in functionality, and community support, but documentation is sparse. However, there are so many examples that you’ll inevitably find one which shows how to build what you’re trying to do.

Many of the examples make use of stats.js and dat.GUI for monitoring the frame rate and adjusting settings, which are good tools to include when developing your game. dat.GUI was especially helpful in fine-tuning our latency compensation algorithm and tweaking the game’s appearance, such as light strength and other material properties.

We bought the air hockey, mallet and puck models from TurboSquid, and getting them into the browser was easy thanks to three.js’s Blender exporter plugin, which exports Blender scenes as JSON. We honed our Blender skills to separate the models, tweak the materials and reduce the number of polygons to make the resulting file sizes smaller. (One humorous bug was that the puck wasn’t touching one side of the air hockey table — after an hour of debugging the physics engine we found that the 3D puck model was actually offset a few units on the X and Y axes and wasn’t centered on the origin. Oops.)

If you’re new to 3D, WebGL and three.js can be daunting since there’s a lot of terminology and unfamiliar concepts. Since none of us are 3D artists it took a lot of time to get lighting and materials just right. We did a lot of experimentation by tweaking the graphics, reloading the game and playing against ourselves. A better approach, which we realized when we watched Mr.doob’s presentation on the RO.ME project, is to separate parts of the presentation into small, stand-alone demos which can be tweaked quickly and easiliy before being included in the final result.

Networking

We wanted to see if we could make a responsive, low-latency game that challenges players’ reflexes, and air hockey seemed like a good fit. Moving mallets and a puck around requires snappy networking performance, and we knew that the game would be unplayable if the networking was even a little bit slow. Fortunately, WebSockets provided great performance.

Our approach to networking was relatively unsophisticated but it was good enough to prove our point: “twitch” gaming in HTML5 is totally possible! Our networking code worked like this:

The client sends the position of the player’s mallet to the server.
The server computes the velocity of both mallets, based on their previous and current positions, and then advances the game simulator, which detects collisions and computes the new velocity and location of the puck.
The server sends out the latest puck and mallet locations to the clients, which display it to the players.

Of course, latency complicates this process. If it takes 50ms for a packet to get from the server to the client, then the puck position that the player sees will be 50ms out of date. This makes it harder for the player to hit the puck. Here’s how we solved this problem:

The client measures the latency between the client and the server — For example, 50ms.
When the client receives the position and velocity of the puck from the server it uses the same physics simulator that the server uses to predict where the puck will be 50ms from now.
It then displays the puck at this predicted location. Now the player doesn’t have to “lead” the puck in order to hit it reliably.

There are other modern, well-established techniques for lag compensation that could improve the playability of our game even more, but we didn’t use any of them for our demo. Using only ’90s-era game networking techniques was enough to build a fun, real-time, multiplayer browser game.

Also, it’s worth noting that the server is authoritative about the state of the game. All real-world multiplayer gaming has to be done this way to prevent cheating.

JavaScript

We thought that developing an HTML5 frontend with a Node.js backend would simplify development time because we could share JavaScript code between the client and server. This is especially important for real-time games where the same simulation needs to run on both ends. Compared to a previous project in which we had separate codebases for client and server logic, we think we cut development time down by somewhere around 30%.

We tried using RequireJS to write client-side code, but wrapping all of our code in AMD-style module definitions felt clumsy and alien, and we couldn’t get the whole shared-code thing to work. Later on we discovered Browserify, which was life-changing. Not only did Browserify work great, but it provides wrappers for many standard Node libraries so we could write events = require 'events' and class Game extends events.EventEmitter and have it work on the client-side. The only thing we couldn’t get to work with Browserify was Backbone.js, so we wrote 50 lines of CoffeeScript to replace the parts we needed from it.

We chose CoffeeScript over JavaScript because it allowed us to write the same logic in fewer characters, and all of the administrative Node tools, like nodemon and forever, seem to support it. We were worried that CoffeeScript would be hard to debug, but it turned out that the compiled JavaScript was dead easy to navigate. Browserify also makes use of the new source map standard, which helps a lot with navigation in the Chrome Developer Tools, and we think it won’t be long before someone will make it easy to debug CoffeeScript in the browser directly.

Performance and optimization

As already mentioned, we run our game server on Node.js. We felt that there was no other sensible option given that Node.js gives us the ability to run the same game code on the client and the server. So far we’ve been pretty pleased with Node’s performance, and in our load tests we found that we can run about 100 concurrent games on a single 512MB Rackspace VM before performance starts to degrade. We spent almost no time optimizing our code so this performance was a rather pleasant surprise.

Any discussion of HTML5 performance will inevitably include garbage collection, and we were initially concerned that GC pauses might cause noticeable pauses in game play. With Chrome this turned out not to be a problem. When playing Air Hockey on Firefox, unfortunately, there are noticeable blips in smoothness which we think is related to garbage collection. However, we made no effort at all to reduce the amount of garbage we generate, and we think it’s probably possible to get great performance on Firefox by being more careful about how much garbage your code generates.

Lessons learned

The biggest thing holding back browser game development is the lack of tools. 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 some great libraries and components, but it’s still up to you to string them together.

Flash and Unity have well-established development environments, and iOS and Xbox Live Arcade are platforms which provide end-to-end solutions for building and publishing a game. But the browser is still very, very new, and building an HTML5 game is still analogous to assembly language. In our game there’s no slider we can use to tweak the color of the puck or adjust the brightness of a light — if we wanted any of that we’d have to build it or buy in (literally) to a heavier framework.

We are excited about the possibilities in terms of bringing near-console-like experiences into the browser with synchronous, multiplayer gaming using HTML5. As fans of StarCraft and Halo ourselves, we’re ready to see those experiences come into the browser, and we hope we can inspire you to want them as well.

If you would like to get early access to our games and game development tools, please sign up at http://artillerygames.com.

The Artillery Blog

Browser Garbage Collection and Frame Rate

Methodology

Correlation between slow frames and GC events

Conclusion

Further Reading

Play Powderkeg!

Network Synchronization

Dealing with Lag

Graphics

Sound

What’s Next

Welcoming Our New Investors

Six Impossible Problems

1. Let players begin playing rich, triple-A games seconds after clicking a link.

2. Help game designers create real-time, multi-player games without knowing anything about networking.

3. Create a hosting service for the most latency-sensitive web applications ever built.

4. Build game development tools that allow designers, artists, engineers, and play-testers to collaborate in a way that works for everyone.

5. Make high-fidelity, resource-hungry games run perfectly in JavaScript.

6. Increase the speed of light to reduce network latency.

Consoles Are Dead

Experiments with WebSocket Performance

Methodology

Measurements

50ms Latency, 0.1% Packet Loss

50ms Latency, 1% Packet Loss

50ms Latency, 5% Packet Loss

100ms Latency

100ms Latency, 0.1% Packet Loss

100ms Latency, 1% Packet Loss

100ms Latency, 5% Packet Loss

Conclusion

Reducing Polygon Counts and File Sizes

Real-time synchronous multiplayer 3D gaming with HTML5

Graphics

Networking

JavaScript

Performance and optimization

Lessons learned

Further reading