Six Impossible Problems

by Mark Logan
on 09 July 2012

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.

hero

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.

Blog Home

The Artillery Blog