An Overview of Adaptive Game Design

This article recently appeared on BuildNewGames.com, a collaboration by the teams at Bocoup and Internet Explorer.

“Responsive design” is a fairly popular buzzword in modern web development. The idea behind responsive design is that an interface is designed and should be built such that it can be adapted to any technology, any screen format; some form of the interface should work just as well for an Android phone as it does for a 27” Apple cinema display. It’s a design that flexes and shuffles around content to match the assumed expectation of the user based on context; that context is defined by the technology, use case, and location. So, then, what happens as we build extremely interactive applications- that is, games- on the web? Often, we find ourselves conflicted; “do we support IE 7? Or 8? What about Opera? What about mobile? How about Japanese, or Hebrew?” Traditional approaches involve generating a minimum-requirements spec, where we limit the potential number of users in return for cheaper development and support costs.

There is, however, an interesting and compelling way around this conundrum to engage a much larger market. We can shift around the problem entirely by providing an entirely new class of entertainment to our end user. What I propose is a progressively enhanced, responsively designed approach to web gaming that encompasses all devices, everywhere, by providing engagement across all levels.

This involves breaking away from the idea of building a game, and instead, building a lasting, engaging experience.

This isn’t a new idea; it’s simply subtle. Mass Effect, by BioWare, has launched campaigns that involve mini-games for the iPad 1. Many online games have official forums. EVE Online, by CCP Games, supports building offline social connections; many players in the same corporation talk together in voice chat, IM, forums, and meetups, allowing the chance for tremendously deep interaction without even loading the game client 2. Rich meta-game experiences keep players involved even while not actually playing the game, and often are the result of just a little bit of extra effort. All of these things are supported by the common infrastructure provided by the Internet.

The Assumption: Homogeneity

Web game development is at an interesting crossroads. Traditional game development involves low-level algorithms, intense computer science, strict software design, and rigorous QA. The path this crosses is a much younger field of web development: that of device compatibility, css tricks and a hacked-together content-markup-turned-interactive Frankenstein’s monster (that you may know as HTML). To embrace the web, we must put aside the notions of requirements such as “Must use Windows 7 with 4GB of RAM or more, 2.4Ghz CPU, and GeForce 8-series” and think about smartphones, dumbphones, tablets, laptops, desktops, e-readers, Raspberry Pis, Chromebooks, ultrabooks, Google glasses, e-paper wristwatches, game consoles, and whatever else may be available.

That’s a big list, and we’ve barely touched the surface of available devices for your content. That alone should be frightening. The mobile market already accounts for 50% of all Internet traffic3, which means one of two things: you can take 50% of the market with desktops (shrink that by half if you only want modern browsers), you can take 50% of the smartphone market with iOS and Android apps (shrink that by more than half if you only want decent Internet speeds), or you can provide an experience that is engaging to consumers with top-end and low-end equipment alike. This will come from building a game designed for flexibility and engagement outside of the normal channels. The only way to engage the entire market is to make content available to the entire market. However, don’t try to build the exact same thing on every platform, or you’ll be mired in the huge development costs of doing so.

Every device is used in a different context, and thus has different needs. Mobile devices are often used because a desktop isn’t available and often because the user is mobile. The user may be on a smartphone during lunch break, or on the train. Laptops and desktops are more often used when sitting down to a longer session, and thus the game platform should accommodate the differences in user attention span and capability. Internet-enabled toasters are probably only used in passing to check the news and even then, probably in the morning.

Supporting this variety can be accomplished in interesting ways. Let’s assume, for our practical example, that we’re building an RPG; we’ll call it “Hades III”. We can make the assumption that we want some online multiplayer interaction (say, for trading items and playing through the story together), so we need a communication layer that works across devices. In this example, WebSockets 4 is a great platform-agnostic technology choice. Building our desktop client in HTML 5 allows us to take advantage of modern browsers’ graphics processing hardware through WebGL or Canvas, and allows us to test browser capabilities and provide a lesser experience to less-capable browsers. It also allows us to build a mobile-specific interface and use one of the many HTML5-to-native-app frameworks available (or build a native app and connect through the common WebSockets interface.)

Let’s say our game design also includes a chat and friends-list feature; again, the best choice is a platform-agnostic one because we can’t make any assumptions about what our platform might be. XMPP happens to be usable over WebSockets and HTTP 5 and has libraries for most languages. This means any device with an active Internet connection can chat! Additionally, we can add in a forum system, manual, wiki, fan stories, art, and other non-realtime data to allow players to share information without even requiring a reliable Internet connection. A person-to-person messaging system also accomplishes this by allowing players to connect asynchronously.

Imagine that trading in our game means in-game, real-time trading where players each offer items from their inventory. However, we can open this up even further and build a web-based marketplace where items can be sold or traded in escrow through an HTTP interface or mobile app. Consider every feature an opportunity to build an API to get more features out to more potential players.

All of this follows the pattern of routing around unpredictability by allowing something for any level of capability, rather than either brute-forcing solutions through costly hacks or ignoring a subset of the market entirely. Let’s try breaking our game out into tiers to see what each level of device might experience.

Laptops / Desktops, Latest Browsers

Your users on high-end desktops and laptops have the latest browsers with WebGL or Canvas enabled. They get the full effect: 3D or 2D isometric graphics, WebSocket-enabled chat, and graphical inventory management. The game works great with traditional point-and-click interfaces, as is customary for the platform; you may have designed clickable contextual menus, icons to click, and other OS paradigms that make sense for the users of that platform. This platform likely works for some game consoles like the Wii, which offer similar point-and-click interfaces.

This is where your core players will come from; they’ll get the best experience and will be the greatest source of hype. In fact, for Hades III, you can’t really enjoy the core game unless you fall into this category; there is a minimum spec to play. However, these players may spend a large portion of time away from their more capable hardware, and keeping them connected to the game through other means will help hold onto their engagement. Additionally, players who can’t play the core game can still be involved in the game’s ecosystem though alternative channels.

Laptops & Desktops With Outdated Browsers or Hardware

At the coffee machine at work (who really talks at a water cooler?), Sally asks Joe if he’s tried Hades III. It’s the latest amazement in technology; it has this really cool isometric gameplay. It’s revolutionary, and she loves the real-money-trade auction house where she’s already sold a few items she found. Joe hasn’t tried it out, so during his lunch break at work, he goes to the website.

Unfortunately, his three-year-old laptop is under company policy, and although he can manage to squeak through the company firewall somehow (probably because the sysadmin plays), he’s stuck on a browser that doesn’t have support for the latest technology; maybe it’s an older browser version mandated by outmoded company policy, or maybe it’s simply because his old laptop can’t handle it. Lucky for him, the game designers have cleverly designed a way to engage Joe even with his less-able browser.

Joe can still create a character, customize his appearance, and view portions of the game, to get a taste for it, even while locked out of the core game. The only portions of the game that actually require high-level interactivity are walking around and performing physical actions on the world; nothing’s stopping him from accessing manuals, bestiaries, social connections, and personal customization data. If we provide social connections- for example, through a clan system or forum- this allows Joe to connect to and find other like-minded individuals with whom he can learn the game. An additional, oft-overlooked feature we can provide is XMPP chat; by implementing in-game communication using a common protocol, Joe can find and hang out with his friends in-game, even while unable to play. To take this further, why not enable inventory management? Why not enable to in-game auction house through a web client, thus allowing the players to access even more information and features while outside the game? It turns out, there are very few actions that actually require being in the game, and the more we expose, the more engagement opportunity exists. It turns out that significant feature sets of games can be handled outside of the core experience.

This, itself, comes out of one of the powers of traditional web development: building an application as a platform. Design your game technology in layers: platform (API) and client (the platform-specific graphical display). By building your game as an API, you expose the ability to recreate much of the game whether or not a high-end, realtime client is available to the player.

High-End Native Mobile & Tablet

With a game built as a platform, we have the freedom to create an interface for any device imaginable. Native mobile applications target the specific use case of a player who’s using a mobile device and allows for both quick check-ins that take the space of a few seconds as well as longer stays. Game design accommodating, through a generic protocol such as WebSockets, players on mobile devices can even connect and play in the same world as desktop clients. This, of course, requires some change in interface design, such as touch-based gestures instead of clickable menus and keyboard shortcuts, but the underlying mechanic stays much the same. In the case of our Hades III, we touch spots on the screen to run instead of clicking; we drag inventory items using fingers instead of click-and-drag with the mouse; we speak into the microphone to chat with our friends instead of typing on a keyboard.

However, we have more opportunities to take it to another level. We can do more than simply provide replacements (touch instead of click); we can add an entirely new dimension to our game. We have the opportunity to build out the “universe”; how about a location-based player-versus-player minigame? “Find a player nearby, and import your character’s attributes and pit your luck against theirs.” You can open up an entirely new market and engage current users, increase awareness of your game, and create new players out of those who don’t have powerful desktops or laptops who can now play these side-games instead. You can leverage the power of advertising in platform-specific app stores. We’ve used the power of the web- by building a generic interface, our API- to expand the reach of our game.

Low-powered & Esoteric Devices

Entering the realm of e-readers, e-ink watches, dumbphones, AR glasses, and Internet-enabled refrigerators, we have yet another market segment waiting for us. What can we do here? At a minimum, we can expose the community; forums, slow-update chats, and global ranking. We can expose non-game-dependent features, such as inventory management, and alternative side-games. Using the novel interface provided by something like e-ink watches, we can display alerts on-screen; with the interesting challenge posed by AR glasses, we can display virtualized 3d models in air, virtual flocks of monsters running down the street, or anything else imaginable.

We should also consider the device we’re targeting. Why would a player be interested in our game on an Internet-enabled refrigerator? Maybe the player has a quick question or idea and wants to check something. Exposing meta-content like art, bestiaries, manuals and player-generated fan fiction and lore can provide quick entertainment and engagement readily consumable by these kinds of devices. In fact, what better to read on your Kindle on the train into work than some curated lore concerning the game and its universe?

All These Things and More

All of these devices require significant creative input – they require creating a universe and a socially-engaging game, which can be out of the scope of a casual game. This is almost certainly out of scope if you’re more interested in building yet another line-up-the-gems game. However, if you can imagine larger goals, the potential target market is far more massive; if you build not just a game, but a platform, you can engage a massive market and even dream of accomplishing the feat of being the first billion-player game.

The most important thing to longevity is to build a platform, not a game.

Building a platform- that is to say, an API- is what allows you to expand to devices. Even if you only have the budget or time for a single market segment, and you’re only concerned with very specific desktops with very specific stats, this architectural consideration is worthwhile. It makes success easier to handle. By building a disconnected server with a practice such as REST, you can build your game as your first client. “Dogfooding” your own API is a surefire way to make sure that you can handle plenty of traffic from the web and anywhere else your game may have taken you.

In Conclusion

Any game that aspires to be more than a casual encounter should seriously consider building itself as a platform. Start by splitting your game into two pieces: the game engine and the interface, and build them as separate codebases; don’t allow them to interact besides through an API. Even if you don’t have the time or resources to start off as a multi-platform game, you can at least prepare for the future (and use some good practices while you’re at it). Engaging players online and offline, capturing user attention across devices, and even allowing players to build on your platform improves retention rate. This in turn results in both a higher long-term-value per user and lower maintenance cost as you change, add to, or remove interfaces for your game. Reach for something larger: capture the whole market and increase the value of the legacy that your creation leaves behind. You have the ability to impact the world; the right architecture choices make it a technical possibility.

Resources

• 1. Mass Effect 3 iPad game
• 2. Examples of player-created EVE Online Apps: DotLan EVEMaps, EVE Killboards, TEST Alliance Wiki
• 3. Mary Meeker’s Internet Trends projection via ReadWriteWeb
• 4. WebSockets: A Guide
• 5. XMPP over HTTP / WebSockets

About the Author

Jack Lawson is an engineer, husband, father, & purveyor of fine javascripts. Follow him on Twitter.