Making a Game Out Of the Web

Today I want to talk about our plans for the UI, but it’s a much deeper thing than just making windows and buttons. It’s recognizing that once an MMO is launched, the world belongs to the players who live there as much as it does to the developers who built it. It’s admitting that, as a small studio, we won’t be able to exactly support every single player’s individual playstyle, and that there’s as much talent and creativity spread through the larger community as there is inside our little office. And it’s embracing the fact that in 2013, your ability to connect to something shouldn’t stop when you walk away from a desktop PC.

A few years ago I came around to an idea: This whole “web” thing is probably going to be around for a while. That sounds silly. It should sound silly, because it’s so obvious. But for whatever reason, most MMO developers haven’t gone all-in on it yet. There are “browser-based” MMOs, but most are just taking a traditional MMO and putting it in a web page, without making the most of what that enables. There are MMOs that do an increasingly good job of exposing their data through a web API (EVE and WoW are standouts in this regard), but even then it’s a backdoor view into the game rather than the game itself.

 

What if, instead of putting parts of our game ON the web, we made our game OUT OF the web?

That’s what brings us back to the UI of Camelot Unchained. Over the years I’ve worked with and/or built various UI toolkits. Scaleform takes advantage of all the Flash authoring tools out there, and it’s really big in AAA games — we used it on Skyrim. For Warhammer Online, we used a custom solution of Lua and XML — which was really familiar to players who were already making UI mods in Lua and XML for a certain other MMO. But there’s another option out there that isn’t getting as much use in games as it should. A toolkit that more of our players have experience developing for than anything else out there. A scripting engine that’s been optimized for years by a team of the brightest minds in the industry. A runtime that’s extensively tested every day on hundreds of millions of PCs and renders straight into DirectX textures ready for use in games.

I’m talking, of course, about the ever-present HTML and JavaScript. Each section of our in-game UI can behave as a little fragment of a webpage, with the same CSS and PNGs we all know and love. Whether we’re going to use Chromium or Mozilla or Awesomium or some other implementation isn’t the most important thing here; it’s all the additional possibilities that open up for us beyond just having a fast, cheap, flexible, and extremely moddable UI.

 

Anytime, Anywhere, on Anything

First and foremost, because all of our UI will be implemented as web page(s) overlaid onto the game, our UI can also be put directly onto web pages. Have you ever wanted access to your guild chat from someplace other than a full-on game client? It’ll be right there at www.camelot-unchained.com/guildchat (link doesn’t work…yet). This won’t be some lesser, limited version of what you have in-game; it will be the exact version from the game. Access to characters? Statistics for your realm? The state of the war and frontiers? All there.

Obviously, anything that depends on your character’s physical presence at a certain spot in the game world won’t work in a meaningful way if you’re not connecting from the fully logged-in game client, and there’ll be things that we limit for security or spam-fighting. But as a general rule, your entire in-game social life and much of your economic life will be accessible from anywhere, in any modern web browser, without plugins, in exactly the same form as when you’re running our big shiny standalone 3D desktop client.

 

Accessibility Equals Moddability

As mentioned, HTML and JavaScript are spoken by nearly everyone who’s done any programming. There are some great tools in other languages, but the breadth of experience with them doesn’t come anywhere close to the number of people who know and understand how to put together a basic webpage. We want the only barrier to entry for hacking on our UI to be your own creativity, and that means we don’t want the first hurdle to involve learning a new language or toolkit.

There are also some really nice things that go along with HTML. Want to make your own plugin look like it fits in with the rest of our game, without being a graphic designer yourself? Just inherit our CSS. Want to change the look of the entire game, including other people’s plugins, because you are a graphic designer yourself? Just override our CSS. It’s the C part of CSS that makes the magic. This is also where the sandboxing of modern browser implementations becomes important — because their security’s already been battle-tested in the wild, we can be a little more liberal in what range of scripting we allow.

One of my personal goals, though it may not make it in at launch, is to make installing a new UI mod or plugin as simple as copy/pasting a URL into the game. We know we can’t make everything for everyone, but we want to make sure everyone can make something for each other.

 

Gentlemen, Start Your Mashups

Finally, in order to build our entire UI out of web pages, we need to expose our game to the web in a way that few MMOs have. There’s no other choice. Every game has to expose its full internals to its UI layer. Studios with lots of extra resources may eventually expose an additional, incomplete web API to the game as well, but not so here. Our web API is our first and foremost API. That means that anything you can access in-game, you can access and display on your own website, running your own code.

Want a custom display of who defeated who in that last battle, cross-referenced with what weapons they had in hand? Build it. How about heatmaps of the best places to set up siege equipment? We can’t wait to see them. We’ve got some really creative and talented people here at CSE, but we know there’s more total creativity and talent out there in the entire community, waiting to be unlocked if we just give you the keys.

And best of all, because we’ve got a web browser running in-game, you’ll be able to pull it all back into the game as a UI mod for others to share. There’s no distinction. There shouldn’t be a distinction. It’s 2013, all programming is web programming, and it’s time MMOs caught up with the rest of the Internet.

-Andrew

 

 

Sidebar: Some Technical Notes

This is the nitty-gritty stuff, for the potential modders and hackers out there. Here be programmer-speak; you have been warned! Also, please keep in mind that right now this is a general plan rather than a shipping product, and there’s still substantial engineering work to do with this feature on our end. You should expect that things will change as we shake down the implementation. It’s one of the first pieces of infrastructure we’ll be rocking on if we fund, though.

First, don’t expect to make XMLHttpRequests directly from your own JavaScript if you want to run within the game. We plan to implement a lightweight JavaScript library to act as an intermediary. When running standalone on the web, this library will still speak AJAX and WebSockets while providing an OAuth-style token for user authentication. If you’re running on a server, you’ll of course be able to roll your own through those same public APIs in the language of your choice.

On the other hand, when your (or our) code is running in the game and using that library, for performance reasons some calls will be redirected into the client rather than actually making an HTTP request. We’ll encourage — and very likely enforce — that everyone use that library rather than going directly to our server. That will ensure UI mods can be as responsive as possible by using data the client has already cached locally, while still preserving the ability to work standalone. This will be an evolving process of tuning, and we may move the implementation behind a particular query back and forth between the two. However, this is the programming team’s own dogfood, so we promise to make it tasty.

There is a strong possibility that when running in-game, UI mods will be limited so they can’t talk to any servers other than our own (and via our library at that). When code is running in the wild we obviously won’t be able to enforce that limitation, so the token you get will instead provide less access than going through a logged-in and trusted client. Initially, expect a binary system: You’ll either have full access to a character or you’ll have the ability to send data to the outside world, but not both at the same time. We want to make finer-grained controls happen eventually, but “eventually” may not happen in version 1.0 because working through the implications of every possible combination of mix-and-match permissions is not something that can or should be rushed. As a first step the “limited information but with outside access” may become an alternate mode when running in the client.

The “limited” mode will still include nearly all social and economic data, though. What we’re unlikely to provide when code has access to outside servers is realtime, detailed combat data, exact locations, and similar things that pertain to the action immediately occurring in the game world. We want to actively prevent anything resembling a “global shared hivemind” radar/GPS overlay, so expect information with immediate tactical value to be aggregated, summarized, and deliberately lagged when viewed from the outside. There’s a balance there — we do understand that players will talk on IM and forums outside of the game, so we don’t want to provide less information than they already share via good old-fashioned community. However, please bear with us if we initially err on the side of caution and only incrementally open that end of things up.

Finally, the usual sort of constraints about rate limits and throttling by IP and account will be in play here. Don’t destroy the server; it’s where you keep your stuff.