作者：Austin Hallock

在我看过和玩过的数千HTML5游戏中，最让人沮丧的一点便是许多游戏都只是将“HTML5”作为创造“手机”或“Flash”游戏的一种选择方法。这一看法存在的问题便在于，HTML5既不是Flash也不是原生手机语言。只是为了将游戏呈现在iOS和Android应用商店中而使用HTML5去创造游戏一点意义都没有，你最终将面对一款比使用Unity或Adobe AIR还糟糕的游戏。比起使用HTML5去模仿原生手机游戏，作为开发者的我们需要开发针对于HTML5的游戏，利用它所提供的独特优势。

过去的成功

通常情况下最简单的方法便是分析历史上的例子。让我们着眼于过去5年里游戏产业中最响亮的两个名字，以及它们如何通过创建平台而走到今天的位置。

Facebook——>Zynga

因为了解Facebook这一平台以及以及如何通过该平台推广游戏并获取盈利。

在《Zynga Poker》和《FarmVille》出现之前，Facebook商业有许多优秀的游戏，如《Farm Town》（游戏邦注：与《FarmVille》的游戏理念很像，但是早于后者出现）。Zynga真正知道如何面向Facebook创造游戏，并利用Facebook的社交功能进行病毒式传播：邀请朋友（“成为我的邻居”），在玩家的信息墙上刊登游戏进程，以及各种成就等。

我们也能在Zynga发展的急剧下降中看到理解一个平台并为该平台创造游戏的理念体现。它们慢慢转向手机平台，并不再利用Facebook推动其快速发展的各种功能。

iOS——>Rovio

基于物理原理的大炮游戏并不是什么新题材，但是Rovio却将其变成一款能够基于触屏的游戏（即《愤怒的小鸟》），从而让它能够出现在iPhone平台上。如果《愤怒的小鸟》使用的是与普通大炮游戏一样的机制，而不是适于触屏的弹弓，游戏有可能也就不会成为现在的一大文化指标了。

Rovio共开发了51款游戏才造就了《愤怒的小鸟》现在的成功，而在之前51款游戏的开发中，他们真正学会了如何面向iOS平台开发游戏。

HTML5——>？

面向HTML5创造游戏

所以HTML5的“碰触”和“社交”元素是什么？为此我们需要着眼于HTML5和网页作为平台的突出之处。

超链接

分销常被当成HTML5应用和游戏的主要问题。我们还未看到过一款精通分销的HTML5游戏。

我们似乎逐渐忘记了网页平台所拥有的强大分销模式。我们拥有链接，更重要的还是我们有办法让人们去传播这些链接。如内容，文章和视频等等能够通过链接获得数百万的浏览和观看—-但是游戏似乎还未能享受到这样的成功。在某种程度上，Flash游戏算是做得不错了，但是游戏还未能达到视频和内容所获得的成功（游戏邦注：特别是在所有设备上，包括手机）。

我并未看到许多游戏能够创造性地使用链接。它们顶多只是链接到“游戏”页面上。如果游戏能让我通过链接进入好友的游戏，重新开始游戏，或挑战好友以获得更高分数的话就好了。

而这一功能之所以被忽视的一大原因便是，开发者并不想花时间去做到这些；它们并不是完全关于游戏玩法。在Clay.io，我们便尝试着提供这样的帮助，并执行一个“链接”API功能让开发者能够更轻松地做到我所提到那三种情况。

多种设备的使用

HTML5是推动游戏利用多种设备的完美工具。Wii U最早基于其控制器（作为TV的第二个屏幕）带来了这一主流趋势。但问题是你的开发者并不需要Wii U或特别的控制器去做到这点—-Wii U控制器真的是一个标准的控制器。

JavaScript是创造一款多设备的最佳语言。就像Node.js因为能够保持前端和后端语言的一致而大受欢迎，所以可以说是保持设备1，设备2和后端语言的一致性。为什么要基于Objective C编写游戏的iOS版本而基于C编写PC版本？性能可能是唯一原因，但这仍有待进一步讨论。

我看过的最佳例子是艺电所创造的一个演示视频。游戏名为《Strike Fortress》，这是一款利用了手机和PC设置的游戏。

《战地4》做出了一些变化，因为游戏足够复杂，所以基于不同设备（平板电脑vs.PC/主机）呈现出了不同游戏模式。在平板电脑上，你将作为基于2D自上而下视角并拥有一些特殊能力的“指挥官”。这种类型的游戏玩法非常适合使用HTML5，特别是当WebGL足够成熟能够提供具有主机般质量的体验。

我不知道艺电使用了怎样的技术去创造《战地4》的指挥官模式，但是我认为他们可以把握住HTML5。

游戏无处不在

markets（from gamasutra）

这一点很明显，但是我觉得有必要将其包括在内。我看过无数面向桌面网页而创造的HTML5游戏，但却都未考虑过手机平台，而这些类型的游戏其实都能有效地呈现在触屏上。

如果你创造过HTML5游戏，你最好能够尽可能将去推向各个地方。我脑中浮现的是：iOS App Store，Google Play，Windows App Store，Chrome Web Store，Facebook，Firefox Marketplace，Amazon Appstore，Flash Portals等等。

整篇文章都是关于面向HTML5这一平台创造游戏，但这同样也包含了面向所有HTML5所运行的平台创造游戏—-这需要花费更多精力，但却是有价值的。这包含支持输入各种类型的设备（游戏邦注：如触屏，键盘和鼠标），并根据不同的设备规格挑战游戏规模。

搜索引擎优化

搜索引擎已经成为了人们观察内容的最佳方法。社交媒体在过去几年里带来了巨大的影响，但是SEO仍然是网页的强大工具，甚至是在手机平台上。游戏并未充分利用搜索引擎。门户游戏通常是经过优化的，但是作为HTML5游戏开发者，你可以独自进行这些优化。Clay.io和Kongregate便是如此，但是如果有人搜索一些与你们游戏相关的内容，难道你不希望他们能够直接进入游戏页面？

canvas元素本身并不能索引，但是你可以借助一些与游戏相关的描述文本，并使用常见的SEO技术去获得更多搜索流量。

就像Clay.io的《Slime Soccer》每个月都能通过搜索引擎获得2500多次特殊的游戏体验。

你可以找到许多有关如何选择关键词的文章，但是最优秀的还是《How To Do Keyword Research》。

摆脱App Store和Google Play

你的游戏并不是非得出现在iOS App Store或Google Play上才能进入手机设备。这是一个巨大的利益。当然，如果游戏能够同时出现在这些商店中便再好不过，但如果可以无需安装并牵扯到其它商店的话便是个巨大的机遇。

如今，消费者可以通过微信和Kik（这两款应用在亚洲市场取得了巨大的成功）等聊天应用发现游戏。App Store模式从总体上看来很棒，但是用户却很难在此发现独特的新游戏——而微信和Kik则是寻找游戏的不同方法。

除了这些聊天应用，还有一些已建立的手机应用，如Facebook和Twitter都能让玩家通过应用的网络视图而直接游戏。这是一种更棒的游戏体验，在某种意义上让用户感觉自己也逛了应用商店。

带着HTML5朝前发展

让我们别再模拟原生手机应用，开始真正利用HTML5所提供的一切去开发游戏吧。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Building Games for HTML5, Not with HTML5

by Austin Hallock

In the thousands of HTML5 games I’ve seen and played, the biggest downer is that so many are just using “HTML5″ as an alternative way to create either “mobile” or “Flash” games. The problem with that approach is HTML5 is neither Flash nor a native mobile language. Building a game with HTML5 just to put it in the iOS and Android app stores is pointless, you’re going to have a game that performs worse than it would with Unity or Adobe AIR. Rather than trying to emulate native mobile games with HTML5, we as developers need to develop games specifically for HTML5 – taking advantage of the unique offering it brings.

Past Successes

Often times the easiest way to drill home a point is to analyze historical examples. Let’s look at two of the biggest names in gaming in the past 5 years, and how they got where they are by building for the platform.

Facebook → Zynga

Zynga blew up to a $9 billion dollar evaluation because it completely understood the Facebook platform and how to effectively distribute and monetize their games through it.

There were plenty of good games on Facebook before Zynga Poker and FarmVille… heck, there was even Farm Town (the same idea as FarmVille – before FarmVille). Zynga just really understood how to build a game for Facebook and have it spread virally by taking advantage Facebook’s social features: inviting friends (in a more personal way “be my neighbor”), posting progress to a player’s wall, and various achievements.

The notion of really understanding a platform and building for it can also be seen in Zynga’s sharp decline. They were slow to make the shift to mobile and are no longer able to take advantage of some of the Facebook features that caused them to grow so quickly.

iOS → Rovio

A Physics-based Cannon Game wasn’t something new Rovio came up with for Angry Birds – Crush the Castle from before Angry Birds looks awfully similar – but Rovio turned it into a game that works flawlessly with touch, something the iPhone made possible at a large scale. If Angry Birds had used the same mechanic of a cannon instead of the more touch-friendly slingshot, the game arguably wouldn’t have become the cultural icon it is.

It did take Rovio 51 games to get to Angry Birds’ success, but during those first 51 games they clearly learned how to develop for the iOS platform.

HTML5 → ?

Building For HTML5

So what’s the “touch” and “social” of HTML5? To find those we have to look closely at what makes HTML5 and The Web as a platform unique.

Hyperlinks

Distribution is often cited as a major issue for HTML5 app and games – for good reason. We still haven’t seen an HTML5 game that masters distribution.

What we’re forgetting is how powerful of a distribution model we already have with how the web works. We have links, and more importantly, we have ways for people to virally spread links. Content, articles, videos, etc. reach millions of views and plays just through links – games however haven’t seen the same success. To some extent, Flash games have done well, but I still don’t think games have reached the level of success videos and content have (especially on all devices including mobile).

I haven’t seen many games creatively use links – certainly none off the top of my head. They link to the game’s “play” page, and that’s it. I should be able to join a friend with a link, resume a game based on a link, challenge a friend to beat my score with a link and so on.

Part of this falls on the tool makers – developers don’t want to spend time getting these things to work; features that aren’t completely about the gameplay. At Clay.io, we’re trying to help with this, and have implemented a “Links” API feature that makes it easy to do the three scenarios I mentioned.

I’m sure there are still a ton of cool things we could be helping developers with that we’re not… Game developers are the most creative bunch of people I’ve ever worked with, so if you have a creative idea to take advantage of The Web as a platform, and you think we can help, reach out to me at austin@clay.io.

Multi-Device Use

HTML5 is the perfect vehicle for games that make use of multiple devices. The Wii U was the first to really bring this mainstream with its controller acting as a second-screen for the TV… The thing is, you developers don’t need a Wii U or special controller to make this happen – the Wii U controller is pretty much a standard controller with a phone screen shoved in the middle.

JavaScript is the perfect language to build a multi-device game with. Just like Node.js has become incredibly popular by keeping the language between the frontend and backend relatively the same, so can be said for keeping the language consistent between device 1, device 2, and the backend. Why write an iOS version of a game in Objective C, and the PC version in C? Performance would be the only reason, but that’s becoming more and more of a moot point.

The best example I’ve seen of this is in a year old demo video by EA. The game is called Strike Fortress and it’s a game that takes advantage of the phone + PC setup. You can see the demo video here.

Battlefield 4 is doing a variation of this where, because the game is complex enough, there are different game modes based on the device used (tablet vs PC/Console). On a tablet, you act as a team’s “Commander” with a 2D top-down view and certain specialized abilities. See the trailer for Commander Mode here. This type of gameplay seems like a perfect place for HTML5 to fit in, especially when WebGL is mature enough to provide console-quality experiences.

I have no idea what technology stack EA is using for Battlefield 4′s Commander Mode, but it’s the type of thing I think HTML5 is built for.

Games Everywhere

This is one is obvious, but I feel obligated to include it. I still see countless HTML5 games that are built just for the desktop web that don’t take mobile into consideration – keep in mind, these are types of games that would actually play well on a touch screen…

If you’ve built an HTML5 game, distribute it as many places as you possibly can. Off the top of my head: the iOS App Store, Google Play, Windows App Store, Chrome Web Store, Facebook, Firefox Marketplace, Amazon Appstore, Flash Portals, and the list goes on.

This whole post encompasses building for HTML5 as a platform, but that also consists of building for all of the platforms HTML5 works on – it is a bit more work, but it’s worthwhile. That includes supporting input on a variety of devices (touch vs keyboard & mouse) and having the game scale to many different sizes.

Search Engine Optimization

Search engines have long been the best way to get people viewing content. Social media has made a huge impact in the past few years, but SEO remains a powerful tool for The Web, even on mobile. Games aren’t very optimized for search engines though. The portals games are found on are usually optimized, but as an HTML5 game developer you can do that optimization on your own. Clay.io does it, as does Kongregate, etc.. but if someone is searching for something relevant to your game, wouldn’t you rather them directly visit your page?

The canvas element itself obviously isn’t indexable, but you can surround the game with some description text to help, and apply some common SEO techniques to try and get more search traffic.

For reference, Slime Soccer on Clay.io consistently gets 2,500 unique plays per month from search traffic on one keyword.

You can find a plethora of articles on how to choose keywords (the fact that it’s a game shouldn’t matter too much), but one of the best is How To Do Keyword Research.

Freedom From The App Store and Google Play

Your game doesn’t need to be in the iOS App Store or Google Play to be played on mobile devices. That is a huge benefit. Sure, it’s good to have it in both of those stores (and is easy enough to achieve), but the fact that it can be played without requiring an install and the extra bulk of the stores is a big opportunity.

Consumers are now discovering games through chat apps like WeChat and Kik – both of which have had some success on the HTML5 front primarily in Asia. The App Store model is generally good, but it can make discovering unique new games very difficult – apps like WeChat and Kik are a different approach to finding games. More info on this can be found here and here.

In addition to these chat applications, there are the more established mobile apps like Facebook and Twitter where games can be played directly from the app’s webview. That’s a much better user experience in that sense then going through the app stores. Build games that work well with this model.

Moving Forward with HTML5

HTML5 is a beast of its own; let’s break free from trying to emulate native mobile apps, and start developing games that take advantage of everything HTML5 offers!(source:gamasutra)