A Baseline for Fast, Accessible, Responsive Games on the Open Web

The first thing I built on a computer wasn’t all that different from the last thing I built on one.

That first computer was a Macintosh Classic II. It was one of those beige boxes with the handle on the top, a black and white screen that was—what—maybe twice the size of an iPhone 6 Plus, and “Property of Cambridge Public Schools” stamped on its side for reasons I won’t be getting into here.

It had HyperStudio installed on it—the four-striped off-brand “Adidos” version of HyperCard. I loved that goofy little knockoff program, for reasons I still don’t fully understand.

I used HyperStudio to make games. Point-and-click adventure games, puzzle games—even a couple of action games, by cycling through cards as though they were individual frames of animation. It worked a little bit like Keynote or Powerpoint, except with user interaction. I didn’t know what HyperStudio was designed to do, though I was pretty sure it wasn’t originally meant for games. A card was a rectangle I filled with images and text. Click a button and it sent you to the card I specified; click a different button and go somewhere else. It forced me to think within a set of constraints, sure, but I made it work. This is not entirely unlike present day.

Our new tools—HTML, CSS, and JavaScript—are a hell of a lot more powerful than HyperStudio was, but they come with their own sets of constraints. As much as things have changed, and despite all the exciting new browser features, you can still make out the web’s foundation underneath it all: publishing documents. A page is a rectangle I fill with images and text. Click a link and it sends you to the page I specify; click a different link and go somewhere else.

There’s incredible power in that foundation. Years of browsers fighting tooth-and-nail over who can parse a document the fastest has given us an incredibly performant platform to build on. HTML gives us a way to represent whatever information we mean to convey visually, no matter how complex, in a way that assistive technologies can tap into. At its very core, the web’s strength is in publishing. HTML, CSS, and JavaScript—used carefully—will allow us to build things that anyone with a connection to the web can consume via meaningful, sharable URLs.

The last thing I built on a computer—well, helped to build—was a suite of DOM-based games.

The games we’ve built came with all the bells and whistles you should expect, from sound and animation to gritty details like collision detection, but with a few unique features—features we weren’t willing to compromise on, especially under the banner of “Open Web Games.” They’re built on a fast, accessible, infinitely consumable foundation, because that’s what we believe any contribution to the web should be—that’s the kind of game that we consider to be truly open.

The DOM gave us some tricky constraints to work with, for sure, but those constraints led us to solutions that we’re all really proud of. So, we’ve started developing a new set of tools for building modern DOM-based games; to help with responsible asset management, animation, responsive layouts, and more. These tools let us build games in the browser that don’t have to compromise on aesthetics, performance, or accessibility.

We’re looking forward to sharing more details, documentation, and demos of those solutions with all of you very soon, but we wanted to share the conclusion we reached together sooner: that we’ve seen a way forward for Open Web Games using the DOM, and we’re excited to play our part in exploring it further.