The Artillery Blog

Beyond the Browser:
Artillery’s Native Game Client

by Ian Langworth
on 08 September 2015

We’re well overdue for an update on Project Atlas, so let’s fix that now. In the coming weeks we’ll be posting more information about the game design, but today we’re announcing an important change: Project Atlas will be delivered as a native PC and Mac application.

In 2012 we announced that “the browser is the console” and our intentions to push the limits of HTML5, WebGL, and JavaScript by releasing our real-time strategy game, Atlas, for the browser. This was met with a lot of skepticism on several technical fronts, which was expected and understandable. Many claimed that JavaScript’s meager performance relative to native machine code made it unsuitable for building games and its single-threadedness would be a showstopper.

After some clever tricks and a lot of hard work we’ve made it over these technical hurdles. We now have a production-quality engine and toolchain for developing a real-time, multiplayer RTS. We rewrote critical code paths in C++ and compiled them with Emscripten (often yielding 10x speed-ups), and we made our game multi-threaded with WebWorkers. As of this writing, Atlas currently runs on my gaming PC at 144 FPS in Google Chrome without plugins and with audio/visual effects as well as environment and character art. Unfortunately, despite this benchmark, browsers still fall short in delivering an optimal player experience which will satisfy the demands of consumers, especially gamers.

One problem with the browser is that we’re unable to confine the mouse cursor to the game. Hiding the operating system’s cursor with the Pointer Lock API and drawing a cursor in WebGL introduces unacceptable latency. Even when using an OS cursor, display latency is still too high for competitive gaming.¹

While playing the game the escape key can pull players out of fullscreen, ruining the experience. Many other keys are captured by the OS and can’t be overridden. Also, moving the mouse cursor to the top of the screen causes a security notice to appear, and the inability to confine the cursor makes edge-scrolling frustrating on multi-monitor setups.

Also, networking in the browser is generally limited to TCP, which at first consideration seems completely acceptable for a lockstep networking protocol where message ordering is required. We’ve pushed TCP to its limits, but despite our best efforts, unacceptable bursts of lag are commonplace. A UDP-based protocol would give us the flexibility to optimize our networking protocol and deliver a better experience. (Yes, WebRTC is available, but there’s not much of a software ecosystem around it yet, and it will always be more restrictive than native UDP networking.)

In addition to the limitations of the platform, Chrome and Firefox feature aggressive release schedules, which is great for consumers but problematic for the development of large, intensive web applications. Frequent new features and security updates result in a great browsing experience, but we found it impossible to deliver consistent stability and performance as our application platform shifted beneath us. The browser teams from Google and Mozilla have been invaluable in our efforts to bring this game to the web, but the unfortunate reality is that, even if we don’t change a line of code, Atlas might stop working tomorrow.²

Atlas hasn’t been rewritten, however. Thanks to some great existing technologies – io.js, SDL2, Coherent UI, and ANGLE – we’ve been able to put together what can be best described as a browser-like application optimized for games. The engine and game assets are still streamed and cached via HTTP, our OpenGL-based renderer still works on Windows, and all of the DOM rendering occurs in a separate thread. Also, all of the C++ we used to compile to JavaScript can now be compiled to native code.

While the native client will provide players with a great in-game experience, we remain enthusiastic about our in-browser development. The game continues to work in the browser, as do replays and live observing, so sharing a replay is as easy as copying and pasting a URL. All of our tools, including our map editor, unit and ability editor, model viewer, and particle effects editor are exclusively browser-based, and we’re excited to someday open up these tools and let our community develop content as well. We hope that browsers will solve all these issues someday, but our first priority is amazing gameplay and we’re going to do what we need to do to provide that.

We’re pleased with our technical progress so far and even more excited about releasing Atlas to a broader audience. Stay tuned to our blog for some upcoming updates about our learnings in game design and be sure to sign up to the beta list for Atlas.

(1) We made some measurements in preparation for this article using a high-speed camera and custom mouse with LED lights and we recorded the time between clicking the mouse and seeing a response in our game. On Mac OS X with Chrome 45 on an Apple Thunderbolt monitor the delay was ~75-90ms in fullscreen mode and ~100-110ms in a window. With the native client application we recorded 40ms in fullscreen and 60ms in windowed mode. We’re going to run the same tests in Windows and we expect the results to be the same or better.

(2) We could test Atlas on new browser versions before they’re released, identify every performance and stability regression, and report them in time for Google and Mozilla to fix them before they are widely released. However, that’s just not something we can afford to spend time on.

Share: Y