作者：Will Eastcott

Will Eastcott是电子游戏领域的技术专家，曾供职于EA、索尼和动视，从事AAA游戏开发，他同时还是PlayCanvas的联合创始人，这是家专门为HTML5游戏提供云端托管开发及发行服务的平台。在本文中，他将就此新兴技术如何影响游戏开发者发表自己的看法，论述为何这一语言是游戏开发的下个前进方向。

你多半看过这些标题。“游戏机已消亡！”“HTML5是未来趋势！”

围绕HTML5技术的讨论通常会引起轰动，且存有偏见。现在我们暂且将此弃置一旁，秉承客观态度。如下是我的主张：HTML5将从根本上改变我们制作电子游戏的方式。在我解释其中原因之前，让我先概述当前HTML5的运用进展情况。

过去30年来，我们见证这样的总体趋势：硬件平台日益强大，且通过持续进步的工具和语言生态系统探索其中硬件的策略日益获得优化。朝超真实游戏空间迈进的趋势未曾间断，其中主机制造商逐步向开发者提供日益强大的技术。

但随着手机游戏的兴起，我们看到新情况。玩家希望能够随时随地通过任意设备和任意好友共同体验简单游戏。这些目前是用户的主要需求。技术依然非常重要，精致像素也很重要，但这里更重要的是，游戏通俗易懂且保持连网。有什么比网络浏览器更通俗易懂且更适合连网？

那么制作这类游戏的选择有什么？你可以从零开始编写内容，但瞄准1个以上平台对于小型开发团队来说是个过高要求。这里存在Flash选择（游戏邦注：虽然Flash技术似乎逐步变得越来越缺乏吸引力）。放弃移动平台且关于Stage3D授权成本的令人困惑消息给开发者带来众多消极影响。

例如，我们享有Havok Vision Engine和Unity之类的引擎选择。这些引擎通常通过专属插件瞄准桌面浏览器，通过本地架构锁定手机设备。然后就是HTML5技术。在你最终选择HTML5之前，把握其优点且知道如何降低其弊端非常重要。下面就来深入查看具体内容。

持续演变的标准

HTML5尚未定型。W3C和WHATWG标准小组依然在持续开发这一技术，因此浏览器供应商追踪的是流动目标。因此，HTML5的支持水平因浏览器而异。

有关跨浏览器不一致问题，我们经常提到的例子是声音。目前行业主要有3种API：Mozilla的Audio Data API、Google的Web Audio API和Audio元素JavaScript API。最近，Mozilla宣布弃用自己的API，很快将开始执行Web Audio。因此显而易见的是，浏览器供应商正积极创新HTML5平台，且朝此平台靠拢，以简化开发者们的生活。

浏览器供应商都积极提供新HTML5 API，尤其是向游戏开发者。3个主要例子是GamePad API (这能够读出所有本地支持平板设备的输入内容）、Pointer Lock API (隐藏鼠标光标，读出原始鼠标操作)及Fullscreen API (这能够将任何HTML元素转变成全屏模式)。

这些API都在短暂时间里以连贯方式匹配及植入各种浏览器中。随着它们的出现，诸如第一人称射击游戏之类的作品突然间更容易在HTML5技术中落实。

JavaScript

代码员对于编程语言怀有强烈情感。出身游戏机背景的人员多半会以怀疑态度看待JavaScript。这是另一有待学习的新语言，JavaScript将比对应的C++代码速度缓慢，矢量化之类的优化策略在JS中缺乏可行性。此外，游戏代码公开于浏览器的开发者工具中，供大家查看。

这里我们有必要引用Douglas Crockford的主张，JS是“全世界最容易被误解的编程语言”。对于C++程序员来说，学习JavaScript轻而易举。它在句法特征在和C++存在密切联系，虽然闭包之类的概念及“this”关键词需要我们适应一段时间。

对于那些不喜欢C++语言刻板及繁琐特性的人员来说，JavaScript就是个奇妙的动态语言。一等函数之类的强大功能将显著降低代码的编写工作量，缩短工作时间。转投JavaScript的开发人员多半不会走回头路。

表现比你想象的好很多。首先，Web Workers API允许JavaScript中的多线程编程。其次，也是更重要的一点是，JavaScript引擎在过去几年里取得很大进展。举例来说，开源物理引擎Bullet已有JS端口，虽然表现不突出，但这说明，你可以通过JS以合理速度运行若干CPU密集型算法。

让我们面对现实——克隆存在于所有平台，但关于HTML5游戏，记住若干要点非常重要。Google Closure Compiler之类的工具在优化源码方面表现突出，基于模糊源码的移植工作与访问原始代码并不相同。随着代码库尺寸的日益扩大，要进行反向设计就变得越发不切实际。其次，若游戏包含在线要素，那么很多代码就可以运行于服务器上，客户只是单薄的想像者。很多“价值”隐藏于服务器中。

2D vs. 3D

设计游戏的一个最根本决策是，图像是基于2D，还是3D模式。2D HTML5游戏通常采用2D背景，这可以通过页面上的画布元素进行查询。各主要浏览器目前都对于2D画面背景给予良好支持，因此若你的游戏是基于精灵元素，那就没有什么可担忧的。

若你打算开发3D游戏，那么事情将更加复杂化。在HTML5游戏中获得高质量、硬件加速3D图像的唯一方式是，运用WebGL，这是个几乎和OpenGL ES 2.0相同的JavaScript界面。桌面平台的WebGL支持在Chrome和Firefox中表现尤其突出，只有Internet Explorer不予以支持。幸运的是，Google Chrome Frame有效缓解微软对于WebGL的抵制，虽然苹果尚没有在Safari中默认支持WebGL，但这目前可供开发者进行利用。

WebGL自1.0规格2011年3月发布以来已取得很大进展。随着OpenGL ES 3.0在SIGGRAPH上揭开面纱，可以确信，相应规格WebGL 2.0的问世将用不了多久时间。这对3D浏览器游戏来说无疑是激动人心的时刻。

移动平台支持

HTML5游戏在桌面平台表现不俗，但将其转移到桌面平台并非微不足道的事情。宣称针对桌面平台的HTML5游戏将能够轻松移植至移动平台完全是夸大其词。你需要准备较弱等级的CPU（游戏邦注：意味着较缓慢的JavaScript执行）和GPU（若你锁定3D平台，这意味着顶点和片段吞吐量有所降低）。

屏幕分辨率通常相差甚远，基于HTML5技术开发游戏无法提供能够顺利运作于桌面和移动平台的控制装置。移动平台的WebGL支持目前还处在胚胎阶段，虽然具体面貌6个月后多半会变得截然不同。

在此期间，有若干选择值得研究。诸如PhoneGap、AppMobi及CocoonJS之类的技术可以将HTML5游戏包装成原生内容，这带来更杰出的表现。此时的一个局限因素是，这些技术不包含可行WebGL支持，但某些中间软件开发者很可能已经在寻找解决方案。

简化开发工作

坦白说，开发HTML5游戏非常简单。浏览器带来稳固的开发平台，尤其是当和若干硬件供应商提供的工具进行比较时。

工具本身无需付费，主要植入浏览器中，编码过程没有编译步骤。JavaScript的动态性质带来强大的“编辑并继续”型开发，时时存在的主机非常便捷。网络开发主要着重于快速更新时间和简单性。

API简洁直观，且由于网页开发者的庞大社区，这里存在众多样例代码和实况指南。

可访问性

若说计算机存在什么普遍范例，那就是通过浏览器导航至网页地址，消费置于其中的内容。尽管如此，玩家通常很没有耐心。要求他们下载或安装内容，你无疑会在第一阶段就丧失众多用户。不是所有玩家都倾向或能够安装专属浏览器插件，以顺利运行游戏。

HTML5游戏无需安装或获得权限就能够运行，和有些人的看法相反，它们可以在初期下载后长久存储于设备中。显然，若你的游戏不要求网络连接，这能够促进离线体验。

因此若你的游戏经历的是快速、无缝隙的页面加载过程，你将拥有将其变成关卡1的愉快玩家。

寻找用户

自Google I/O 2012起，Google Chrome就独自积累了3.1亿活跃用户，这一数据超越当代游戏主机的数量。当你查看其它支持HTML5的浏览器时，你会看到更庞大的用户。

仅是你的游戏搭载URL，能为全世界所见并不意味着用户就能够找到它。曝光度也扮演重要角色。众所周知，应用商店拥有有限的“商店橱窗”，游戏很容易淹没在众多内容中。HTML5游戏也不例外，但其拥有若干原生应用所没有的突出优势。

作为网页，它们能够被搜索引擎索引，获得有机曝光。而且还有各种游戏门户和商店，包括Chrome Web Store，在此你可以提高自身作品的曝光度。但这不仅限于网页推广渠道。举个例子，你可以将自己的HTML5游戏打包成包含嵌入WebView元素的原生应用，然后在Mac App Store上进行出售。

覆盖尽可能多的用户非常重要，HTML5让你能够结合许多推广渠道，而非利用单个渠道。

获得关注

不管你喜不喜欢，制作基于尖端“热门”技术的游戏能够带来更高的曝光度。若你编码两款相同的游戏作品，一个基于C++技术，一个基于HTML5技术，哪款游戏更容易获得媒体关注相当明显。这未必公平，但这就是HTML5当前的情况——用户急切想要看到开发者在此有什么发挥，开发者在此享有很多开拓机会。

重新思考基于HTML5的开发工作

希望你现在能够更好判断HTML5技术是否是适合自己的项目。但这是讨论方面尚存在不足的地方。HTML5并非只是推进电子游戏内部结构的系列标准，我们不应只基于此进行判断。

这推进新生代的生产力应用，带动这样的潮流：将我们的数字生活转移到云端服务器。这一趋势具备惊人潜力，改变我们用于制作电子游戏的工具和流程，我们还尚未触及其表面。

云端服务器窗口

现在，我们将使用云端应用看作平常事。网页邮件目前是最热门的例子，在此我们曾经对将我们的私人信函存储在远程服务器上持谨慎态度，我们现在对此非常放松。如今我们拥有基于云端应用形式的各式各样生产力应用：文字处理器、图像编辑器和代码编辑器等。

云端服务器给游戏带来许多有利条件。用户无需安装任何内容，因为网页应用从服务器输（游戏邦注：或是浏览器的存储器）送至浏览器。工具总是保持更新，这确保用户相互保持同步，总是采用最新且最杰出的内容。用户数据总是安全备份，能够恢复原状。用户的操作系统或浏览器可能甚至被粉碎，内容将被提前保存到服务器中。

对于开发工作来说，这些是有用功能，要让用户查看云端机制，你需要一个浏览器。什么是在浏览器中创建界面的最佳方式？我认为是HTML5。虽然我们可以通过Flash、Java或编写定制插件执行游戏工具，但关于编写复杂网页应用，HTML5是最具扩展性的解决方案。随着ExtJS、Google Closure和SproutCore等便捷网页应用框架的持续发展，这一情况将变得日益突出。

合作新方法

通过多年来接触各种不同的游戏编辑器，我发现，它们多数都通过整合某种形式的版本控制支持合作模式。游戏通常由众多也被我们称作“关卡”的文件构成。关卡也许以XML或其他格式保存。若有两人或多人同时编辑此数据文件，有几点事项需要注意。首先，用户A也许不知道用户B改变了什么，反之亦然。其次，当用户A做出变更时，用户B需要将自己的调整同用户A合并。

我们可以将工具限制成专属检验，但这只是意味着，一个用户可以阻止另一用户，阻挡开发工作。若能够基于自动化模式，进行合并完全没有问题，但这并非总是具有可行性。从视觉上合并代码是代码员习惯做的事情，但你要怎么让设计师凭直觉手动合并两组关卡数据？虽然这具有可行性，但这是个很难解决的问题。

所以让我们采用不同方法。若我们的开发工具都在云端服务器运作，所有用户都连接于同个服务器，为什么不让用户进行无缝隙编辑？HTML5再次给予我们一切必要元素。

通过WebSockets（通过TCP的双向沟通），我们可以在用户间进行流编辑，这样即时合作就具有可行性。只要采用这种方式，亲身体会到其中益处，你就不会想要回到传统的“专属检验”单用户环境。

社交游戏开发

若你是位编码员，你肯定拥有GitHub或BitBucket账号。短短几年前，我们多数人都满足于安装Subversion或Perforce的本地实例。为什么不？它们是基础软件，能够有效备份和管理你的代码。

那么为什么版本控制会变成一种服务？这有许多原因，但主要推动因素是社区。代码员能够以前所未有的方式进行互动，追踪其他开发者或有趣项目，在做出更新后接收即时通知。漏洞和功能能够通过忠实粉丝基础获得修复和添加。相比以ZIP存档形式入驻某人的硬盘驱动器或个人网站，在此项目更有机会获得曝光度。

所以为什么要让编码员享受所有乐趣？相同原则也许和游戏开发更具关联性，在此整个过程被当作是网络服务。这包括代码开发，同时还覆盖资产管理、关卡编辑、本土化、QA和发行之类的其他功能。

让我们面对现实：制作游戏非常复杂，独自制作（优秀）游戏并未多数开发者所享有的选择。所需的整套技能通常过于复杂。开发者需要相互找到彼此，参与自己最感兴趣的游戏项目中。是否想让社区替你创建额外关卡？这不是问题。需要将你的游戏翻译成西班牙语？也许粉丝能够提供帮助。

跨平台必杀技

将游戏推向其他平台非常重要。这能够扩展潜在用户，进而促使游戏取得更杰出的商业成绩。距离Sun Microsystems编撰出Java编程语言的“一次性编写，随处运作”短语已过去很多年，多数当代游戏中间设备都基于此设计理念。

跨平台对于游戏开发工具来说也非常重要。约是15年前，工具程序员会基于MFC之类的技术创建应用。随着时间的流逝，更优质的技术日益推陈出新，令.NET应用开发变成小菜一碟——但这依然仅限于Windows平台。在我们的跨设备生活中，必须坐在桌面PC前，方能访问项目着实非常局限。你应该要能够通过具有连贯界面和合适控制装置的工具在任何设备上访问、编辑及发行你的作品。

基于HTML5创建的界面非常简洁直观，将网页应用设计成跨平台模式是条屡试不爽的路线。

一个链接之遥

HTML5作为工具技术所存在的关键优势是，所有内容都存储于URL。构成游戏的各种资源都能够通过特定网页地址进行访问：脚本文件、纹理、声音、关卡或者甚至游戏本身。若新资产被添加至项目中，开发者可以立即通过Tweeter、IM（即时通讯）或邮件发布链接。其他人无需同步任何内容；能够立即进行浏览。

这同时还简化游戏的发行工作。若游戏已存在于服务器中，具有可玩性，那么将其发行至更广阔的网络只是访问权限的问题。开发者要能够轻松快速实时呈现游戏——无需上传内容，无需编写HTML。发行工作应该只是在网页前端中拉动若干简单杠杆。

总结

关于编写电子游戏，没有什么完美的技术。根据你想要制作的游戏，以及你所设定的商业目标，充分把握选择某技术所带来的影响非常重要。HTML5带来一个非常杰出的平台，不只是为了推动游戏，还为了推动我们创建游戏所运用的工具。若你能够适应它的局限性，应对持续变化的标准，那么你就能够变得更富生产力，游戏就能够覆盖更多用户。

未来，制作游戏的过程将变得更加便捷。开发工具将运行于更多平台上，更易于使用，合作将日益简单化。游戏开发者的全球社区将获得巩固，知识的流通将更加顺畅。最终结果是，更多人将制作出更杰出的作品，我们作为用户将享有更丰富的选择。若没有网络、HTML5和Open Web Platform，所有这些都将无法实现。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Will HTML5 Change the Way Games are Made?

by Will Eastcott

Will Eastcott is a video game technologist that has worked for EA, Sony, and Activision on triple-A titles and is co-founder of PlayCanvas, a technology company that provides a cloud-hosted development and publishing platform for HTML5 games. In this article, he shares his opinions on how the emerging technology will really affect game developers and makes a case for the language as a great next step in game development.

You have probably seen the headlines. “Consoles are dead!” “HTML5 is the future!”

The talk around HTML5 is often quite sensationalized and, dare I say, biased. Let’s put all of that aside and introduce a little calm objectivity. Here is my measured proposition: HTML5 will fundamentally change the way we make video games. Before I explain why, let me summarize the state of play with HTML5 today.

Over the last 30 years, we have witnessed a general trend of increasingly powerful hardware platforms coupled with ever better strategies for exploiting that hardware through an evolving ecosystem of tools and languages. The drive towards hyperreal gaming environments has been relentless, with console manufacturers delivering ever more powerful technology into the hands of developers.

However, with the rise of mobile gaming, we have witnessed a new phenomenon. Gamers have responded exceptionally well to playing simpler games in any location, on any device, with any of their friends. These are the key demands of the user now. Technology is still important, and beautifully crafted pixels still matter, but what matters more is that a game is accessible and connected. What is more accessible and connected than a web browser?

So what are the options for building such a game? You could write it from scratch, but targeting more than one platform can be a tall order for a small dev team. There’s Flash, although with every passing month Flash seems less appealing. A retreat from the mobile space and confusing messages about Stage3D licensing costs have generated considerable negative feeling amongst developers.

There are engines like Havok Vision Engine and Unity, for example. These engines generally target the desktop browser via proprietary plugins and mobile devices via a native build. And then there’s HTML5. Before you finally plump for HTML5, it is vital to understand its strengths and know how to mitigate its weaknesses. Let’s take a closer look.

An Evolving Standard

HTML5 is not done. It is still being developed by the standards groups W3C and WHATWG, so browser vendors are tracking a moving target. Therefore, the level of support for HTML5 is different across every browser. This is illustrated in painstaking detail by the site caniuse.com.

An oft-cited example of cross browser inconsistency is audio. There are currently three distinct APIs: Mozilla’s Audio Data API, Google’s Web Audio API, and the Audio element JavaScript API. In recent days, Mozilla has announced that it has deprecated its own API and will soon begin work on implementing Web Audio. So it is clear that browser vendors are working hard to simultaneously innovate and converge the HTML5 platform to make life easier for the developer.

There has been a concerted drive from browser vendors to deliver new HTML5 APIs specifically for game developers. The three main examples are the GamePad API (which can read input from all natively supported pad devices), the Pointer Lock API (which hides the mouse cursor and reads raw mouse movement), and the Fullscreen API (which can make any HTML element go fullscreen).

These APIs have all been specced and implemented into multiple browsers in a consistent fashion in a short space of time. With their arrival, games like first person shooters are suddenly far easier to implement in HTML5.

JavaScript

Coders harbor remarkably strong sentiments about programming languages. Those coming from a console background are likely to view JavaScript with suspicion. It is yet another new language to learn, JavaScript will be slower than the equivalent C++ code, and optimization strategies such as vectorization are not possible with JS. Plus there’s the fact that a game’s code is available for all to see in the browser’s developer tools.

I think it is important to reference Douglas Crockford’s assertion that JS is the “The World’s Most Misunderstood Programming Language”. For C++ programmers, JavaScript is actually a breeze to learn. It is syntactically closely related to C++, although concepts such as closures and the “this” keyword can take some getting used to.

For those of us who don’t like the rigidity and verbosity of a language like C++, JavaScript is a fantastic, dynamic language. Powerful features like first-class functions will drastically reduce the amount of code you have to write and the time it takes to write it. It’s likely that a lot of people who convert to JavaScript won’t be going back.

Performance is better than you might think. Firstly, the Web Workers API enables multi-threaded programming in JavaScript. Secondly, and more importantly, JavaScript engines have come a long way in the last few years. To illustrate, there is already a JS port of the open source physics engine Bullet, and although performance is not stellar, it demonstrates you can run some very CPU intensive algorithms at acceptable speeds using JS.

Let’s face it — cloning exists on all platforms, but when it comes to HTML5 games, it is important to keep a couple of things in mind. Tools such as Google’s Closure Compiler do an impressive job of optimizing the source, and poring over the obfuscated source code is not the same as access to the original code. As a codebase increases in size, the more impractical it becomes to attempt to reverse engineer it. Secondly, if a game is to have an online component, much of the code can be run on the server, and the client is really just a thin visualizer. Much of the “value” resides hidden on the server.

2D vs. 3D

One of the most fundamental choices when designing a game is whether the graphics are to be 2D or 3D. 2D HTML5 games generally use a 2D context queried from a canvas element on the page. Every major browser now has good support for the 2D canvas context, so if your game is sprite based, there are no worries.

Things are more involved if you are looking to develop a 3D game. The only way to get high quality, hardware accelerated 3D graphics in an HTML5 game is to use WebGL, a JavaScript interface almost identical to OpenGL ES 2.0. Support for WebGL on the desktop is strong in Chrome and Firefox, and only Internet Explorer is holding out. Fortunately, Google Chrome Frame provides an elegant mitigation for Microsoft’s resistance to WebGL, and although Apple has yet to enable WebGL in Safari by default, it is available to developers now.

WebGL has come a long way since the 1.0 spec was announced in March 2011. With OpenGL ES 3.0 freshly unveiled at SIGGRAPH, you can bet it won’t be long until the corresponding spec for WebGL 2.0 is released. Exciting times for 3D browser gaming, to be sure.

Mobile Support

HTML5 games work very well on the desktop, but transitioning them to mobile is not trivial. Claims that HTML5 games built for the desktop will transition with minimal effort to mobile platforms are generally exaggerations. You need to be prepared for a weaker class of CPU (meaning slower JavaScript execution) and GPU (meaning reduced vertex and fragment throughput if you are targeting 3D).

Screen resolutions can vary wildly, and developing your game in HTML5 will not magically enable controls that work well on both the desktop and mobile. WebGL support on mobile platforms is fairly embryonic at the moment, although the landscape should look very different six months from now.

In the meantime, there are some options worth investigating. Technologies such as PhoneGap, AppMobi, and CocoonJS can wrap up HTML5 games in a native wrapper that yields better performance. A limitation at this time is that none of these technologies include workable WebGL support, but it is likely that some middleware developers are already building a solution.

Ease of Development

In the scheme of things, developing HTML5 games is very easy. The browser makes for an incredibly solid development platform, particularly when compared to the tools provided by some hardware vendors.

The tools themselves are free and largely integrated into the browser itself and there is no compilation step when coding. The dynamic nature of JavaScript allows for a powerful edit-and-continue type development, and an ever-present console is very handy. Everything about web development is geared towards fast iteration times and simplicity.

APIs are clean and straightforward, and because of the huge community of web developers there is plenty of sample code and live tutorials.

Accessibility

If there is one pretty much universally understood paradigm in computing, it is navigating to a web address in a browser and consuming the content located there. Be that as it may, gamers are an impatient bunch (apologies for the sweeping generalization). Make them download or install something, and you will definitely lose a significant chunk of your clientele at the first hurdle. And not all of them will be inclined or able to install a proprietary browser plugin in order to run a game.

HTML5 games require no install or permissions to run, and contrary to what some believe, they can be permanently cached to a device after an initial download of resources. Obviously, this can facilitate offline play if your game does not require an internet connection.

So if your game is delivered as a reasonably fast, seamless page load, you will have happy users that actually make it into Level 1.

Finding an Audience

As of Google I/O 2012, Google Chrome has accumulated 310M active users all by itself, a number significantly larger than the total number of current gen game consoles out in the wild today. When you then go on to consider other HTML5 capable browsers, we are looking at a potentially vast audience.

Just because your game sits on a URL and is visible to the world does not mean people are going to find it. Discovery plays an important role too. App Stores have a notoriously narrow “shop window” and it’s easy for games to be lost in the crowd. HTML5 games are no different, but have some key advantages over native applications.

As web pages, they are indexable by search engines for organic discovery. Also, there are multiple game portals and stores, including the Chrome Web Store, where you can make your game known. But you are not restricted to web distribution alone. As an example, you can sell your HTML5 game on the Mac App Store by packaging it as native application with an embedded WebView component.

It is important to reach as many users as possible, and HTML5 allows you to combine many distribution channels, rather than any single one.

Getting Noticed

Like it or not, building a game atop a bleeding edge, “hot” technology will only result in better coverage. If you code two identical games, one with C++ and one with HTML5, it is fairly obvious which one is more likely to be picked up on by the media. It is not necessarily fair, but that is simply how things are with HTML5 right now — people are excited to see what developers can do with it and there a lots of opportunities to be a pioneer.

Rethinking Game Development with HTML5

Hopefully you are now in a better position to determine whether HTML5 can work for the games that you want to make. But here’s where I think the debate has fallen short. HTML5 is not merely a set of standards to power the innards of video games and should not be judged solely on that basis.

It is powering a new generation of productivity apps that is stoking a trend for moving our digital lives into the cloud. The potential that this trend has to shake up the tools and workflows that we use in order to make video games is astonishing and we have not yet begun to scratch the surface.

A Window To The Cloud

Today, we think nothing of using cloud apps. Web mail is by far the most popular example, and where we might have once been wary about storing our personal correspondence on a remote server, we have now become very relaxed about it. There are now productivity apps of just about every type that exist in cloud app form: word processors, image editors, code editors and so on.

The cloud brings a lot of benefits in the context of games. There is nothing to install since the web app is delivered to the browser from the server (or the browser’s cache). The tools always stay seamlessly up to date, which ensures that users remain in sync with each other and are always using the latest and greatest release. User data is always safely backed up and trivially restorable. A user’s OS or browser can even crash and work will have already been saved to the server.

These are all really useful features when it comes to development, and to give users a view onto a cloud-based system, you are going to need a browser. And the best way to build the interface in the browser? In my opinion, it’s HTML5. Although it is possible to use Flash, Java, or write a custom plugin to implement a game tool, when it comes to writing a complex web app, HTML5 is the most scalable solution. The case for this is only becoming stronger with the ongoing evolution of easy-to-use web app frameworks such as ExtJS, Google Closure, and SproutCore to name but a few.

A New Way to Collaborate

Having worked on a number of different game editors over the years, I recognize that most of them have supported collaboration via an integration with some form of version control. A game is usually made up of a number of documents that we may as well call “levels”. A level might persist as XML or some other format. If two or more people edit this data file simultaneously, there are a couple of things to note. Firstly, user A may not be aware of what user B is changing and vice versa. Second of all, when user A has committed changes, user B will have to merge her changes with user A’s.

It is possible to limit the tool to exclusive checkouts, but this just means one user can block others and hold up development. Performing merges is fine when they can be automated, but this is not always possible. Merging code visually is something a coder is used to, but how do you have a designer intuitively perform a manual merge on two sets of level data? Although not impossible, it is a very hard problem to solve well.

So let us take a different approach. If our dev tools are running in the cloud, with all clients connected to one server, why not allow seamless editing from all users? Again, HTML5 gives us everything we need.

Using WebSockets (bi-directional comms over TCP), we can stream edits between clients so that real-time collaboration is possible. Once you have worked in this way and experienced the benefits first hand, there is no going back to the old “exclusive checkout”, single-user environment.

Social Game Development

If you are a coder, it is a fair bet that you have a GitHub or BitBucket account. Just a few short years ago, most of us were content to install a local instance of Subversion or Perforce, to name a couple of popular version control solutions. And why not? They are marvelous pieces of software that backup and manage your code very well indeed.

So why the rise of version control as a service? There are many reasons, but the key driver is community. Coders can now network like never before, following other developers or interesting projects, and receiving immediate notifications as soon as updates are made. Bugs are fixed and features are added by a committed follower-base. And projects stand a far greater chance of getting exposure than if they were sitting on someone’s hard drive or personal website as a ZIP archive.

So why let coders have all the fun? The same principles are perhaps even more relevant to game development, with the whole process provided as web service. This includes code development, but also covers other functions such as asset management, level editing, localization, QA, and publishing.

Let’s face it: making games is hard, and making a (good) game alone is not an option for most developers. The spectrum of skills required is often just too great. Developers need to be able to find each other and get involved in the game projects that excite them the most. Want to allow the community to build extra levels for you? Not a problem. Need your game translated into Spanish? Perhaps your followers can help.

The Cross Platform Holy Grail

Making a game cross platform matters. It broadens the potential audience and can therefore make a game more commercially successful. It is now many years since Sun Microsystems coined the phrase ‘Write once, run anywhere’ in reference to the Java programming language and most contemporary games middleware is designed with this in mind. In a similar vein, HTML5 certainly has the ability to deliver game content to a wide variety of device types.

I would argue that it is very important for game development tools to be cross platform as well. Perhaps 15 years ago, a tools programmer would have built an app with a technology like MFC. With the passing of time, better technologies have arrived, to the point where .NET application development is generally acknowledged as being fairly painless — but with it, you are still limited to Windows. In our multi-device lives, it seems overly restrictive that we have to be sitting at a desktop PC to access our projects. You should be able to access, edit, and publish your work from any device via tools that have a consistent interface and suitable controls.

Interface building with HTML5 is fast, straightforward, and designing web applications to work across multiple browsers is a well-trodden route.

Just a Link Away

One of the key strengths of HTML5 as a technology for tools is that all content sits on a URL. Each of the resources that make up a game can be accessed at a specific web address: a script file, a texture, a sound, a level or even the game itself. If a new asset is added to a project, the developer can tweet, IM or mail the link immediately. Nothing for other people to sync; it is there for viewing straight away.

This also simplifies publishing a game. If the game is already on a server and playable, publishing it to the wider web is really just a matter of access rights. A developer should be able to make a game live quickly and easily — nothing to upload and no HTML to write. Publishing should just be a matter of pulling some simple levers in a web front-end.

In Summary

When it comes to writing video games, no technology is perfect. Depending on the game you are looking to build and the commercial objectives that you have for it, it is important to fully appreciate the implications of selecting one technology over another. HTML5 constitutes a truly awesome platform, not just for powering games, but also for powering the tools that are used to build them. If you can live within its limitations and work with an evolving standard, it does have the potential to make you more productive and help your games reach more people.

As we look to the future, the process of making games will continue to become ever more accessible. Development tools will run on more platforms, be easier to use, and make collaboration far simpler. The global community of game developers will strengthen and knowledge will flow more readily. The ultimate result will be that more people will be making better games and we will all be better off in terms of what is available for us to play as consumers. All of this would not be possible without the web, HTML5, and the Open Web Platform to which it belongs.(Source：gamasutra）