HTML5中的Atari Arcade移动化





5.00/5 (1投票)
HTML5中的Atari Arcade移动化
本文最近出现在Atari Arcade开发者中心,这是gskinner.com、Atari和Internet Explorer团队合作的成果。

选择目标
通过在第一个版本中限制在桌面和设备上,我们极大地缩小了范围,并能够提供一个半响应式布局,且只有一个游戏尺寸。我们的覆盖范围包括大多数标准分辨率的显示器,以及Surface和iPad等平板电脑形态。
但我们很快意识到,不针对数量庞大的移动设备用户,我们会错过很多东西。这是一个巨大的市场,现在占全球互联网流量的大约12%,涵盖各种尺寸、分辨率和处理器。我们的下一个任务是确定一种方法,将街机带入移动Web。我们希望支持各种分辨率,包括Windows Phone 8和iPhone 5等新设备上的高DPI。
本文讨论了将街机移动化的目标,以及一些方法、我们遇到的问题,以及我们发现有价值的一些技巧和窍门。
瞄准
我们花费了大量时间来确定不同平台上的可行性,以建立一个适合移动设备的功能集。
我们的目标是构建一个网站,该网站
- 能够重用我们已经构建的大部分网站框架
- 在任何分辨率下都能出色地缩放
- 在新设备上表现出色
- 通过触摸直观地导航
- 能够在发布时包含我们的一些游戏,并在不久后包含我们所有的游戏
- 可以扩展到第三方开发者!
有了这个计划,我们开始重新设计网站的前端,并使游戏具有弹性,以支持我们所需的分辨率。
什么可行?
第一个任务:淘汰不可行的平台。考虑到手机的平台和型号种类繁多,我们对以下几点进行了重点测试
- 技术。有些设备不支持Canvas、JavaScript、CSS或HTML。
- 触摸功能。所有游戏都已支持触摸,因此我们排除了仅支持单点触摸的候选者。
- 足够的分辨率。旧版浏览器在移动设备上会添加大量的浏览器装饰,而我们需要足够的空间让我们的游戏看起来很棒,并在需要时显示触摸控件。
- 性能。一旦它看起来不错且功能正常,我们就专注于性能并监控帧率。
我们测试了许多设备——主要目标是微软的Windows 8设备(以突出平台的技??能),以及iPhone(以触达最广泛的市场)。我们还在许多Android手机上进行了测试,看看我们能支持哪些。
结果令人惊讶。并非所有手机都一样,但街机在我们测试的大部分设备上运行得相当不错。
- 我们在Windows Phone 8上获得了惊人的性能。它拥有最高的帧率,网站如预期般渲染,多点触摸效果也很好。不幸的是,在发布时我们只能拿到WVGA设备(800x480),但我们预计WXGA和720p设备不会有问题。
- 网站和游戏在新iPhone上的表现很棒,但从一开始就很明显,Mobile Safari的浏览器装饰占用了太多空间。为了支持Mobile Safari中的iOS5,需要将街机固定到主屏幕以全屏运行。然后我们发现iOS5及更低版本在固定站点模式下没有硬件支持,所以虽然我们可以支持它,但并非所有游戏都能很好地运行。
- 我们在测试的各种Android设备(包括手机和Nexus 7平板电脑)上获得了混合结果。网站和游戏大部分都能运行,但由于时间紧迫以及Android设备的广泛差异,我们决定先专注于其他平台。
有趣的是,除音频出现小故障外,所有设备在加载和显示我们的游戏方面都没有遇到任何问题。我们对跨各种移动浏览器的一致支持印象深刻。
适应环境
技术尘埃落定后,我们开始了网站重新设计。
为了在一个生产周期内触达我们的目标设备,我们采用了响应式和自适应方法,这些方法可以响应移动访问者,并加载可扩展、灵活的百分比街机版本。它将所有内容都包含在视口内,无论尺寸或横向纵向比例如何。不需要媒体查询。
查看Windows Phone 8(左)和iPhone(右)的比较。



我们尽可能在桌面和移动网站之间保持DOM的一致性。这让我们能够利用大部分现有的网站HTML和CSS结构——这两者都需要相对较小的编辑来支持新的视图。我们实现了一种基于滑动的移动导航,这使我们将艺术作品推到最前面,并使手指更容易、更快地进入游戏。
现在,街机可以响应用户代理,并提供固定尺寸的桌面版本、自适应移动版本,或为不受支持的浏览器和设备提供适当的消息。
初步发现
要在移动浏览器中获得最佳游戏体验,我们必须实现全屏,或者至少尽可能接近全屏。
Windows Phone效果很好
WP8几乎做到了:它在横向和纵向模式下都有一个持久的浏览器栏在屏幕底部(很容易意外触碰),但有足够大的屏幕空间提供沉浸式浏览器内游戏体验。
iOS 6全屏。
效果相当好,但有一些有趣的问题。全屏模式很容易退出,并且导航按钮会覆盖底部区域,如果触碰正确甚至可以滚动屏幕。值得注意的是,Mobile Safari中的全屏功能仅适用于横向模式,这对我们来说很合适。
iOS 5回退
iOS5通过用户主屏幕上的“固定站点”功能接近全屏。如果没有此解决方法,Mobile Safari的浏览器装饰会将视口高度减少近50%。但请注意:固定站点在iOS5上没有硬件支持。某些内容会运行缓慢。
原生滚动和缩放
移动浏览器原生包含直观的页面滚动、过滚动和缩放。这对于查看网页来说很棒——但对于游戏来说不是。幸运的是,我们可以几乎完全阻止它。此方法在Windows Phone 7上不起作用,这也是我们选择不支持它的另一个原因。要阻止原生缩放,我们使用这些meta标签。
<!-- Define the viewport -->
<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1, maximum-scale=1, user-scalable=0, target-densitydpi=device-dpi">
<!-- iOS helper -->
<meta name="apple-mobile-web-app-capable" content="yes" />
为防止滚动,我们包含这个简单的JavaScript。
document.addEventListener(
"touchstart",
function() { return false; },
false
);
自适应液体布局
在第一个版本中,我们选择了一个分辨率来简化游戏开发,并选择了在大多数显示器上都能工作并且仍然能够容纳在Surface或iPad视口内的尺寸。
对于移动端,我们必须重新思考我们的方法,并想出方法使游戏在小屏幕上的效果与在大屏幕上一样好。我们不能简单地缩放游戏,或仅仅在液体布局中浮动我们的资产。我们需要一种混合方法,让我们的游戏既能扩展又能缩放。
使其适合
第一步是缩放Canvas。这带来了独特的挑战,因为每英寸像素数更高的移动设备(如Windows Phone和iPhone 4+)会自动缩放内容以使其更易读。通过一系列测试,我们确定
- Windows Phone 7和8(在撰写本文时仅在WVGA上测试)将内容缩放到1.666倍。在此处阅读更多信息here,以及在此处here。
- iPhone将内容缩放到2倍。这可以通过检查CSS属性
window.devicePixelRatio
来确定,该属性是实际像素数除以设备像素数或“dips”。
这意味着我们必须抵消缩放我们的内容,以便在每个设备上正确显示。为此,我们将大多数HTML元素(如容器iframe)的尺寸乘以缩放因数的倒数(WP为0.6,iPhone为1/window.devicePixelRatio)。在此处阅读有关devicePixelRatio的更多信息。
var factor = 1;
if (iOS) {
// devicePixelRatio evaluates to "2" on iPhone 4+
factor = 1 / window.devicePixelRatio;
} else if (wp7 || wp8) {
factor = 0.6;
}
var frame = document.createElement("iframe");
frame.width = 1024 * factor;
frame.height = 622 * factor;
但是,在我们的游戏Canvas上,我们希望看到像素,而不是将游戏缩小然后让设备将其放大。所以我们改用了CSS缩放。当你通过CSS更改HTML Canvas的尺寸时,内容会被缩放,而不仅仅是更改视口大小并依赖浏览器重新计算。这使我们在屏幕上的像素比例几乎为1:1,在小型高分辨率设备上看起来效果很好。
var factor = 1;
if (iOS) {
// devicePixelRatio evaluates to "2" on iPhone 4+
factor = 1 / window.devicePixelRatio;
} else if (wp7 || wp8) {
factor = 0.6;
}
var canvas = document.createElement("canvas");
canvas.style.width = canvas.width * factor;
canvas.style.height = canvas.height * factor;
结果(未缩放)的游戏尺寸被传递到`GameInfo`类中的游戏中,游戏可以像往常一样渲染所有内容。
// In game code
function startGame() {
var btn = new createjs.Shape(btnGraphics);
// Position on the bottom right
btn.x = this.gameInfo.width - btn.width - 10;
btn.y = this.gameInfo.height - btn.height - 10;
}
重排游戏
在设置好新的视口后,我们仍然面临一些挑战。
1.内容对齐
由于游戏是针对单一用例开发的,当Canvas改变大小时,资产的定位需要进行调整。
大多数时候UI和游戏元素已经锚定在边缘或居中,但并非总是如此。这提醒我们,应该从一开始就尽可能使用边缘对齐或基于百分比的定位。

2.内容缩放
有些重排并不那么简单。在Super Breakout中,砖块精灵被设计成正好适合标准视口大小的13列。为了支持更小的屏幕,我们开始将所有内容缩小。幸运的是,位图在较小的尺寸下渲染得很好,但在小屏幕上,我们有13块非常小的砖块。
这促使我们在开发者SDK中包含一个简单的内置方法,该方法可以确定我们正在处理的分辨率类型,以便内容可以适应。我们没有提供类似DPI的东西,而是选择了一种简单的模式:低、普通和高分辨率。此属性现在在Atari Arcade SDK的有用的GameInfo类中公开。
// On a tiny device, scale down
if (gameInfo.quality == GameLibs.GameInfo.QUALITY_LOW) {
myBtn.scaleX = myBtn.scaleY = 0.5;
// On a high-resolution device, scale up
} else if (gameInfo.quality == GameLibs.GameInfo.QUALITY_HIGH) {
myBtn.scaleX = myBtn.scaleY = 1;
}
在高分辨率设备上,图像和UI元素会按比例放大。在一个极端的例子中,WXGA和720p的Windows Phone的分辨率几乎是其WVGA对应设备的近两倍——所以我们可以将精灵尺寸翻倍,以获得可比的游戏。
在新的移动版本中,我们只包含10列,资产会缩放到适应可用空间。幸运的是,EaselJS使缩放智能且简单。您可以缩放单个资产、具有多个子级的容器,甚至提供备用图像源在??高分辨率环境中进行交换。
function startGame() {
// In high-resolution, scale the entire HUD
if (this.gameInfo.quality == GameLibs.GameInfo.QUALITY_HIGH) {
this.gameHud.scaleX = this.gameHud.scaleY = 0.6;
}
}
屏幕控件
在更改形态时,某些方面可能不会很好地转换。
当我们构思计划时,我们的一个关键担忧是玩家的手。在Surface等设备上,在触摸模式下,用户的手只遮挡了下部角落的一小部分。在手机大小的设备上,这个区域会显著增大。
我们不能像处理游戏其他部分一样简单地缩小UI控件——我们需要它们足够大,以便用户能够进行充分控制。我们最初的计划是只推出3款游戏,即不需要UI控件的游戏:《Super Breakout》、《Pong》和《Missile Command》。然而,在进行了一些快速测试后,我们确信《Asteroids》也能正常工作。
事实确实如此!控件需要缩小约60%,但游戏仍然 playable and fun。

我们希望很快能为开发者提供街机的其余部分以及任何由开发者提交的新游戏,并在移动网站上提供。
更多的测试
设备测试可能很麻烦。模拟器可以让你走一半的路,但没有任何东西可以替代实际设备进行测试。我们有一个庞大的设备缓存,我们会定期使用。

但有很多很酷的事情可以让你更容易地调试和测试。
- IE10中的兼容性测试提供了对以前IE版本的出色测试,而无需老旧的测试机。
- 浏览器中的设备欺骗允许测试用户代理和视口大小。Chrome和Safari有很好的工具。

- 要测试响应式界面,只需缩放浏览器窗口。
- 使用Wienre进行远程调试提供了出色的DOM检查。
- 使用iOS6和Lion进行远程调试,只需插入设备即可进行全面的Web检查。只需在iOS Safari首选项中启用检查器,然后通过桌面上的Safari“开发”菜单访问它。
- iOS 5用户仍然有一个基本的控制台,可以在iOS Safari首选项中打开。
- 运行像MAMP或XAMPP这样的Web服务器,设备可以通过内部网络访问开发版本。
- Atari Arcade SDK中包含的新Test Harness HTML页面提供了一些在游戏中欺骗移动分辨率和触摸交互的选项。试试吧!
解决性能问题
作为该项目的一部分,我们花了很多时间与微软工程师和布道师交流,这非常有启发性。我们不仅对微软的优秀团队产生了极大的尊重,还学到了一些宝贵的技巧、窍门和最佳实践,这些都被应用到了Atari网站、Atari Arcade SDK以及CreateJS套件的下一版本中。
我们中的大多数人在速度极快的四核(或更多)机器上开发,拥有出色的GPU和比我们需要的更多的算力。对于街机的这个阶段,我们不得不仔细审视性能,并确保街机能够转移到低功耗设备上,包括刚刚发布的基于ARM的Microsoft Surface。
以下是一些我们学到的技巧:
- 保持DOM不变。JavaScript -> DOM通信非常昂贵。即使是像添加/删除DOM中的音频这样的小事,也会导致巨大的性能下降。
- 减少DOM中的复杂性和嵌套。
- 学习使用CSS变换而不是`top`和`left`等定位属性。CSS变换是硬件加速的,速度非常快。通过CSS更改位置非常慢。请注意,许多浏览器仍使用带有前缀的变换,因此方法更复杂——但结果是值得的!
// Old way
div.style.top = "100px";
// New way
var props = ["transform", "msTransform", "webkitTransform", "oTransform", "mozTransform"];
var found = false;
for (var i=0; i < props.length; i++) {
if (props[i] in div.styles) {
div.styles[props[i]] = "translateY(100px)";
found = true;
break;
}
}
if (!found) {
div.style.top = "100px";
}
有趣的事实:IE10同时支持带前缀和不带前缀的变换,所以如果你想获得额外的性能提升,你只会想应用其中一个。
- 在元素上使用CSS类,而不是注入JavaScript来操作样式。
- Canvas上的像素访问非常昂贵,因为它需要访问视频缓冲区。尽可能避免。因此,EaselJS除非你明确启用,否则不会跟踪mouseover手势。
// Create a stage
var stage = new createjs.Stage(canvasElement);
// Enable the mouseOver with a frequency
// whic is the maximum number of checks per second.
stage.enableMouseOver(10);
- 触摸事件非常昂贵。避免由触摸输入引起的复杂操作,而是缓存触摸坐标,并在游戏tick时或使用某种形式的失效来执行操作。
并且,**总是**直接在目标机器上测试。上述许多技巧在桌面上或从桌面模拟时无法区分。一旦它掌握在你手中,你就会真正感受到变化。
下一步?
Atari希望很快为希望使用Atari Arcade SDK构建移动游戏并将其提交到街机的开发者打开大门。随着SDK的最新版本,所有必要的钩子、方法和测试环境都已可用,可以立即开始构建和测试移动游戏。希望在不久的将来,提交过程也能扩展到移动端。
所以,查看下面的资源,克隆Atari Arcade GitHub仓库,玩得开心!
资源
购买这些很棒的书。它们已经出版几年了,但非常有帮助,并且是gskinner.com上所有从事HTML的开发者和设计师的必读材料。
这里有一些额外的 HTML5 游戏开发资源和参考资料。
- CreateJS
了解更多关于 CreateJS
社区论坛和反馈
GitHub 上的 CreateJS - 在gskinner.com和gBlog上获取更多HTML5和Flash内容。
- Microsoft //Build/ 2012的50个性能技巧。
- 面向开发者的 Internet Explorer 10 指南
- HTML5 实验室
- W3C
- 使用 Compat Inspector 移除旧版 IE 标记
- HTML5 功能检测
- IE 博客
- MSDN IE 开发中心
- IETestDrive
- Windows 8 / Internet Explorer 10:触摸友好
- Windows 8 / Internet Explorer 10:无插件
- Windows 8 / Internet Explorer 10:固定站点
关于作者

Lanny McNie、Michael Graves和Chris Caldwell是gskinner.com的高级职员,该机构专注于构建前沿的交互式和创意内容,并为平台所有者、开发者和最终用户带来价值。我们通过成功案例展示和增强技术平台。我们最近与Atari合作,利用HTML5、CSS3和WebSockets等Web标准,重新构想了Atari Arcade。