作者：Sean Soria

我们刚成立Gamezee的时候，行业中许多人都对HTML5抱有成见，就算是一些对其较为乐观的人士也只是说，HTML5将是未来发展潮流，但目前还不够成熟和稳定，无法制作出当前主导社交游戏领域的Ville类型Flash游戏。

当时我们准备使用HTML5制作一款可同时运行于PC端的Facebook，以及所有iOS设备和Android手机平台移动网络的大型等视距游戏。

这款出自单个团队之手，并且基于HTML5/node.JS的游戏《Skyscraper City》仅运行一个代码库，它是我们这家工作室的开山之作。

《Skyscraper City》这款城建游戏现在已经入驻Facebook及iOS、Android手机平台，结合了社交建设玩法，含有乐高积木风格的元素。玩家可以堆叠任何一种城市单位以建设高塔，或者装饰建筑等。

开发这款游戏并非易事，以下是我们所总结的一些经验：

1）移动设备的玩家数量多于我们的预期。

我们想制作跨平台HTML5游戏的原因之一就是，我们自己也是游戏玩家。我玩过《CityVille》，并希望外出时也能在手机上玩到这款游戏。Zynga虽然推出移动版《CityVille Hometown》，我也可以在iPhone或Android手机下载这款游戏，但它与原版《CityVille》并不相同，它是另一座城市。而我们的游戏却能提供真正的跨平台体验，你可以在PC电脑、平板电脑、移动设备上玩游戏，并且实现游戏进程在所有设备上的同步。

我们认为多数用户的想法也是如此——他们多数时候在电脑上玩游戏，然后在其他场所时就拿出平板电脑或手机继续体验游戏。但在iPid Touch或iPad上玩游戏的用户要多于在Mac平台，而Android手机游戏玩家又会多于这些苹果游戏用户。

如果我们一开始就清楚这一点，就会花更多时间针对移动设备而非Mac浏览器优化游戏体验。虽然我们设计之初就考虑到移动设备，但我们却只是将其视为次级游戏环境。我们建议其他开发者将优质的手机游戏体验作为首要考虑目标。

2）必须进行多次试验。

我们一开始就有使用Canvas渲染游戏的念头。这在桌面电脑平台上十分管用——完全不存在运行效果的问题。但在iPhone 3GS平台，运行效果很糟糕（我们制作游戏时的每秒渲染画面不足5帧，但iOS 5.0发布之后情况大有好转）。

所以我们只好接二连三地创建一个又一个渲染引擎，直到创建出目前使用的DOM渲染器为止（它适用于多数设备）。这个DOM渲染器使用CSS动画，支持我们在2D图像上使用伪3D CSS变换以触发移动设备上的硬件加速功能（这可以略微提升运行效果）。

3）HTML5仍存在一些难以攻克的软肋。

HTML5上的音效仍然很有问题。游戏开发需考虑的是植入多种声音以响应游戏提示信息及玩家输入操作。但尽管我们进行了多次试验，仍然无法在多数移动设备上实现较理想的音效（游戏邦注：例如，无法让声音即时响应游戏内容或玩家操作），也难以让游戏同时播放响声和音乐。所以我们就选择在电脑版本的游戏中同时保留声音及音乐内容，但移动网页版本仅保留音乐。

在DOM上提升运行效果的一个类似做法是在CSS上进行伪3D变换。这可以在多数移动设备上触发硬件加速，使其获得比Canvas更出色的运行效果。

出于某种原因，有些Android设备（例如三星Galaxy S21）并不支持这种操作，所以你无法针对它们提升游戏运行性能。

以下是我们用来触发3D变换的代码：

/******************************/

/* Makes screen non-selectable and prevents text cursor from displaying */

/******************************/

div {

margin: 0;

padding: 0;

-moz-user-select: -moz-none;

-khtml-user-select: none;

-webkit-user-select: none;

/*3D transform */

-webkit-transform: scale3d(1, 1, 1);

-o-user-select: none;

user-select: none;

}

4）在设计之初就要有跨平台理念。

我们希望手机版本与电脑网页版本的游戏体验更为相近，这意味着我们需要关闭手机版中的缩放功能，在网页版游戏中移除道具拾取的翻转效果，并想法在手机版游戏中植入翻转（我们的想法是通过一个按扭激活或使用手指按压目标道具来实现这一点）。

像《CityVille》这类游戏设计如果不进行重大调整，根本就不适用于手机平台，因为它一开始就并非瞄准移动设备。它的菜单太大太复杂了，游戏中的东西多得无法在小小的iPhone屏幕中呈现（游戏邦注：所以Zynga才需要针对iOS、Android发布独立版本的《CityVille Hometown》，而非添加一些元素直接将原版游戏移植到手机平台）。

5）不要采用大量堆叠操作。

我们游戏的一大特色就是上文提到的堆叠操作。在城市中创建一个巨型机器人或者建设一个由四根细柱支撑的倒金字塔确实很有趣，但在手机平台上的堆叠操作却问题百出。如果用户的手指不够纤细，有时候就难以准确选中他们想点击的物品。另外，与Flash一样，如果你在屏幕上拖动的对象越多，渲染时间就会越长。

玩家在这款游戏中一开始拥有10 X 10的城市方格，最高可以建设11层楼。如果每一格都建设这么高的楼，那需要渲染的建筑内容就多了（如果玩家的可玩区域扩展4倍后，那么渲染的工作量就更大了）。

所以，虽然堆叠很好玩，但对于扩建后的城市来说却十分不利于玩家操作，它会延长游戏的加载时间（在某些移动设备上的加载时间超过一分钟，在桌面电脑就没有这么明显）。我们现在正在优化游戏渲染大量对象的运行性能，但如果我们提前知道这一点，可能就会不会采用这种棘手的堆叠玩法了。

6）善于运用CSS知识

你最好很擅长CSS技术，因为让游戏在桌面电脑平台、Android手机及所有iOS设备的主流浏览器流畅运行，需要用到大量的CSS知识。我们有一个网页开发者的任务就是处理与CSS相关的工作，针对多种移动设备创建可动态变换尺寸的菜单。在电子游戏设计中，有50％的工作用于创建菜单。而HTML5跨平台游戏开发中有50％属于与CSS相关的工作。

以下是我们在这个开发过程中的一些体会：

*我们的实践证明，开发者可以使用HTML5制作出很棒的跨平台等视距游戏。

*如果玩家可以在一个设备上玩某款游戏，多数人就会想在手机或平板电脑上继续体验该游戏。

*制作HTML5跨平台游戏需进行大量试验。

*虽然HTML5很强大，但仍有一些不甚完善之处。

*跨平台游戏体验意味着，游戏设计之初就要考虑到用户在不同设备上的体验。

*不可在手机游戏中植入需进行大量堆叠或过度拖动的操作。

*最好很精通CSS技能。

以下是我们在Facebook平台开发跨平台HTML5游戏的一些极有帮助的参考资料：

1）viewporter.  https://github.com/zynga/viewporter. 这个Zynga开源代码允许你获取任何设备的屏幕尺寸，并针对这些屏幕调整游戏大小。它比你自己从头编写代码更省时间（我们用过Viewporter，也自己写过代码，所以才会知道这一点。）

2）Weinre.http://phonegap.github.com/weinre/. 这个远程调试器工作原理类似于Web Inspector，但它运行于移动设备。它有助于追踪iPhone和iPad等设备上的控制台错误信息。

3）JQuery.  http://jquery.com/ 你可以利用这个库中现成的代码，省下自己写代码的时间。它对文本动画处理极有用处，我们进行了一些修改并推出了JQuery Mobile，它更适用于移动设备平台。

4）node.JS.  http://nodejs.org/ 在你使用Javascript编写内容时，它可以让你省时省力地使客户端代码及服务器相适配。在作为游戏服务器时，node.JS的扩展性能也十分理想。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Making A Speedy HTML5 Game

by Sean Soria

Back when we started Gamzee, a lot of people in the game industry were down on HTML5. The hopeful ones said that HTML5 was the wave of the future, but it just wasn’t stable or fast enough to make the big sort of ‘Ville-type Flash games that dominate social gaming today.

So what did we do?  We set out to make a big, isometric game in HTML5.  And not only would it run on Facebook on desktop Web, but it would also run on mobile Web, utilizing Facebook Platform.  On all iOS devices and Android phones.

Pretty unambitious, right?  Well, it’s what we did in making Skyscraper City — an HTML5/node.JS game that runs on a single codebase and was built by a single team.  As our first game as a new company, no less.

In case you don’t want to read the rest of this blog post, the results of all that work is here (apps.facebook.com/skyscrapercity).  And you can, indeed, play it on Facebook on the Web or on mobile on your iOS device or Android phone.  Skyscraper City is a city-building game that combines the gameplay of social builders with the fun of Lego-style blocks.  You can stack almost any city unit on top of any other to build towers, elaborate structures, or whatever you want.

Was it easy to make?  Heck no.

What did we learn?  Here are the highlights.

1) Way more people play the game on mobile devices than we expected.

One of the reasons we wanted to make a cross-platform HTML5 game is because we’re all gamers.  I play Cityville, and I want to check into my city on my phone while I’m out and about.  Zynga did put out Cityville Hometown, and I can download that if I’ve got an iPhone or and Android phone, but it’s not the same game, and it’s not the same city.  Our game is truly cross-platform; you can play on your computer, your tablet, and your mobile device and maintain your progress on all those devices.

That’s how we thought most people would play the game, too — mostly playing on a computer, then continuing on a tablet or phone while they’re not at their computers.  But there are more people playing the game on the iPod Touch or the iPad than there are on a Mac, for example.  And way more Android phone users playing than any of those devices combined.

Had we known that at the start, we could have spent more time optimizing mobile and less on Mac browsers.  While we built with mobile in mind, we envisioned mobile as a secondary play environment.  We recommend that game developers making cross-platform focus on delivering a great mobile experience as their primary goal.

2) You have to do a lot of experimentation.

We started with the idea that we’d use Canvas (yay, HTML5) to render our game.  That worked great on desktops — no performance issues.  But on an iPhone 3GS, the performance was horrid (rendering less than 5 frames per second when we were working on the game; performance has improved a lot with the release of iOS 5.0).

So we had to create another render engine.  And another one.  And another one.  Until we have the one we use now (a DOM renderer), that works pretty well on most devices.  The DOM renderer uses CSS animations, creating and animating in divs.  It also allows us to use a little kludge, using fake 3D CSS transforms on our 2D images in order to trigger hardware acceleration on mobile (which gives us a little boost in performance).

3) Some things you’re just not going to be able to do well.

Sound performance in HTML5 is still pretty iffy.  The expectation in game development is that you’ll have mutliple sounds that can play in response to cues in the game and gamer inputs.  Despite a lot of experimentation, it’s hard to get low-latency cued up sound (i.e. a sound that reliably plays in response to a game or user action) and impossible to get multitracking (sound and music playing at the same time, for example) on most mobile devices.  So we opted for sound and music on desktop and just music on mobile Web.

Similarly, a simple trick to speed up performance on the DOM is fake 3D transforms on your CSS.  That triggers hardware acceleration on most mobile devices, resulting in better performance than Canvas, for example.

For some reason, this doesn’t work on some Android phones, like Samsung’s Galaxy S2.  As a result, you don’t get a performance boost there.

Here’s code that we used to trigger 3D transforms.  And, as a bonus, we’re also showing you how we prevent the user from selecting big chunks of text/graphics inadvertently and how we prevent the game from displaying the text cursor occasionally (both fixes help make the game feel more like a native app than a Web app).

/******************************/

/* Makes screen non-selectable and prevents text cursor from displaying */

/******************************/

div {

margin: 0;

padding: 0;

-moz-user-select: -moz-none;

-khtml-user-select: none;

-webkit-user-select: none;

/*3D transform */

-webkit-transform: scale3d(1, 1, 1);

-o-user-select: none;

user-select: none;

}

4) If you’re going cross-platform, you have to design that from the ground up.

We wanted to achieve as close to 1:1 parity as we could on the mobile experience as the desktop Web experience.  So that meant turning off pinch to zoom on phones, not having rollover item/drop pickups on the Web version of the game, and figuring out ways to implement rollovers on mobile (ours are either activated off of a button or by holding down your finger on the item in question).

Something like Cityville wouldn’t work on mobile, at least not without substantially changing the game experience, because it wasn’t designed around mobile screens.  The menus are too large and complicated, and there’s too much going on in a city to easily show on a (relatively) tiny iPhone screen (hence the separate app Cityville Hometown for iOS and Android rather than an integrated experience).

5) Don’t do stacking(!)

One of the cool features of our game is that ability to stack I mentioned earlier.  It’s really fun to make a giant robot in your city or construct an odd, stepped reverse pyramid supported by four thin columns.

Unfortunately, stacking presents a host of issues on mobile.  People with less than slender fingers sometimes have a hard time accurately picking what they want to click on.  And, like Flash, render times increase the more objects you’re drawing on screen.

We start our players out with a 10×10 city grid.  You can get that up to 11 stories tall.  If you slapped down 1-tile buildings that high, that’s 1,100 buildings.  That’s a lot of buildings to render.  (And that’s before the expansions we just added that let you quadruple the size of your grid).

So while stacking is very neat, it can bite you in the butt with a very large city, making the game take a while to load (up to a minute-plus on some mobile devices; the problem isn’t noticeable on desktop due to larger processing power).  We’re making optimzations to how the game renders large amounts of objects. But we would have been better served by realizing this in advance and coming up with another gameplay feature instead of stacking.

6) Love CSS

You’d better be good at CSS, because getting a game working on all major browsers on desktop Web and Android phones and all iOS devices requires a lot of the stuff.  We have one Web Developer  whose whole job is focusing on that, building out menus that will dynamically size for various mobile devices and master versions for Web and tablet.  One of the axioms of video game design is that it’s 50% menu work.  HTML5 cross-platform games are probably 50% CSS work.

So what did we take away from our experience?

•We validated that you can make a cool, rich isometric game in HTML5 and have it be cross-platform.

•We learned that if people can play a game on any device, a lot of them are going to do it primarily on mobile or tablet.

•We learned that HTML5 cross-platform games require a lot of experimentation.

•We learned that as great as HTML5 is, some things still aren’t quite there yet;

•That designing a cross-platform experience means you need to think about the user experience on all devices from the ground up (in your game design);

•That you shouldn’t have a game on mobile that does a lot of stacking or overdrawing;

•And that you’d better love CSS and be good at it.

Hopefully you learned something, and hopefully you’ll enjoy our game.

And for those of you who read through to the end, here are a few things that made our lives easier as we developed a cross-platform HTML5 game on Facebook Platform.

1) Viewporter.  https://github.com/zynga/viewporter.  Zynga’s open-source code allows you to get screen size on any device and to scale your game to match.  It saves a lot of time from writing it yourself (we know because we’ve used Viewporter and written our own).

2) Weinre.  http://phonegap.github.com/weinre/.  A remote debugger that works like Web Inspector, but on mobile devices.  A real lifesaver when it comes to tracking down console errors on devices like iPhones and iPads.

3) JQuery.  http://jquery.com/  Why write your own code if you can leverage a library?  For things like text animations, JQuery’s very solid.  We’ve made a few modifications, and JQuery Mobile now exists, which is better optimized for mobile devices, but JQuery gave us a huge headstart.

4) node.JS.  http://nodejs.org/  When you’re working in Javascript, it saves a lot of time and effort when you can have your client code and server code match as closely as possible.  node.JS also scales remarkably well when acting as a game server.（source:gamasutra）