作者：Christopher Brousseau

背景

我是Chris，就职于Big Viking Games这家移动/社交游戏开发工作室。我们目前正面向iOS制作一款HTML5游戏，并计划向Facebook、Android平台发布游戏。Big Viking致力于成为当代领先的HTML5游戏开发商，我原先是设计师，后来升任制作人职位，负责监管整个游戏制作流程。

我已经在PC端看到一些令人印象深刻的HTML5内容，但使用UIWebView在iOS移动平台环境中开发这种游戏要面临更大挑战。以下将列出一些HTML5的技术局限性，并分享克服这些障碍以传递出色游戏体验的创意方法。

HTML5的技术局限性

那些没有技术背景的人如何制作HTML5游戏？我个人并非团队中最佳技术达人，但我之前已经有了一些编程经验（多为C#）。我相信你之前已经看过网站，虽然网站是由许多模块组成，但它的主要成份还是图片和文本，对吗？

HTML5也是由这些元素组成，因此当你在制作游戏的时候，你就会受限于图片和文本。区别就在于，你在网站上点击一个按钮时，另一个页面就会开始加载，当前页面会发生一些变化。而在游戏中，当你点击某物时，它是通过动画或声音形式来呈现变化——这一切都是完整的客户端/服务器组件之间的对话。

因为我们是用Javascript制作动画，这非常棘手，因为在移动设备的CPU上，即使是很简单的动画也需要大量加载。更复杂的是，iOS 6引进了一个取消一些GPU卸载工作的漏洞，这严重阻碍了我们的操作计划。

当你玩《Mech Force》并进入一场战役，门砰地关上，东西开始旋转。当我找到开发团队时，提出了在该页面添加一些爆炸效果的建议，程序员惊讶地盯着我，好像我脸上有什么异常。因为添加爆炸效果可能让游戏从每秒60帧变成20帧！

enter a battle(from gamasutra)

在以上图片中，每个重甲战士（Mechs)都是由14个独立图片组成，而门则是5个图片，因为中间的圆圈采用了旋转动画和重叠文本。每个窗口都是2张图片，除此之外上面还有一些命值条和文本。每个动画都只是一个精灵表，我们循环播放并依次展示这些图片，使其呈现动画外观。无需赘述，大家都看得出来这个截图中已经有太多需要运行的东西，所以若是添加一个简单的爆炸效果就会让游戏在iPhone 4S上严重延迟运行。虽然iPhone 5可能会支持这种效果，但我们认为最好让这款游戏同时兼容于iPhone 4S和iPhone 5。

内存是我们在HTML5开发过程中遇到的另一个问题。在屏幕上同时运行这么多图片需要许多内存，而这又会导致游戏随时崩溃。iOS设备在内存不足的情况下最先出现问题的是声音。这意味着《Mech Force》中的音乐会时不时中断，这会极大影响用户体验。

游戏+HTML5

那么如何让HTML5运用于游戏领域呢？游戏当然有可能采用HTML5，只是这种游戏不可以对画面要求太高。最适合采用HTML5的游戏应该是基于文本或卡牌游戏。使用HTML5开发游戏好比是针对SNES开发游戏。游戏的发展变化创造了人们的更高期望——例如粒子效果、动画图片和声音！

想象一下！早在SNES时代人们就对此寄以期望。然而，今天的画面效果更好，能够在小型设备（例如iPad 3）上以更高分辨率运行。另一个选择就是让游戏尽量少用动画。记信，移动平台很容易出现内存问题，经常难以在屏幕上一次性运行太多图片。

但对于我们另一款正在发开中的HTML5游戏《Tiny Kingdom》，我们根据从《Mech Force》中汲取的经验重建了我们的游戏引擎。我们希望在屏幕上同时兼容四比四的战役，这似乎是最为可行的选择。但我们实际上用了一些非常愚蠢，并且毫无意义的小技巧去实现这一点。例如，如果你在动画前将不透明度设置为100%，然后在动画之后将其调至100%，你就会遇到每秒仅运行20帧的问题。

所以，RPG很适用于HTML5——你可以制作巨大的“世界”和一款极为出众的游戏，但在动画效果上的表现未必会很出色。HTML5游戏的第二种理想选择是卡牌游戏。或者可以说，只需要创造内容，无需过多动画的游戏都很适合采用HTML5。《Kingdoms of Camelot》就是一个可以轻松地用HTML5开发，并且质量毫不逊色的游戏典型。另一方面，《愤怒的小鸟》这类游戏并非HTML5的理想。任何需要让某物作出快速反应的动作类游戏都不宜选择HTML5。因此，第一人称射击游戏和平台跳跃游戏也要回避HTML5。HTML5游戏选择就这么多，就看你要创造什么内容了。

HTML5和创意设计决策

根据我最近的制作经历，我遇到了许多需要返功以便优化HTML5功能的创意障碍。

尤其是在《Mech Force》中，我们在打算将原来的理念运用于HTML5时遇到了许多棘手问题。例如，在创造史诗般的重甲战士的战役之前，我们只能选择在幕后模拟战役。

模拟战役要求我们重新调整原来的计划，并添加额外选项。我们对《Mech Force》战役的原计划是在玩家挑选对手时，向其呈现自己的作战对象。但是，我们在向玩家呈现这些内容之前，得加载14张图片并对其重新着色，这就需要花费1.2秒的加载时间。所以我们没有选择呈现令人抓狂的加载条，而是创造了一个动画，让Mechs瞬间移动。

teleportation(from gamasutra)

第二个挑战是解决Mechs如何在整款游戏中穿行。我们发现自己无法让Mechs按原计划那样移动，因为这在技术上无法实现。我们聚到一块想出了瞬间传送的方法，让Mechs以一种很棒的方式瞬间移动。

我目前的创意挑战在于设计一种允许玩家突袭其他基地的功能。为了让玩家看到自己所有的战舰都出兵作战，我不得不考虑这种效果所需要的图片数量，我得想出一个让玩家无需看到这些内容就能想象出战斗场景的创意方式。

转向《Tiny Kingdom》项目，我们计划让角色受到攻击时闪现一种不同的颜色。但这需要大量计算处理能力，因此我们无法采用这种设计。为此，我们针对游戏中的每一个敌人制作了一种攻击动画。这种做法更费工时，但为了实现目标我们只能如此妥协。为了保持游戏质量，一些小小的让步无疑更具进步意义。

小型UI

创造智能的UI或许是我们在HTML5开发过程中遇到的最大挑战，尤其是当我们还是针对iPhone 4S开发内容之时。创造智能而有效的UI迫使我们重新考虑如何让游戏在不同设备上加载。用户体验极依赖响应时间，如果加载时间太长，游戏就会让人觉得不舒服或不具可玩性。《Mech Force》在一定程度上就是如此设计，以便一切事物都能同时运行，并且只有在所有环节都准备就绪时才会呈现。但是，这会让游戏在得各个章节中花费更多秒进行加载。从一个任务切换到另一个任务可能需要3.5秒，我们认为这种设置实在让人难以接受。

这让《Mech Force》团队花费大量时间学习如何开发和部署理想的UI。例如，游戏中任何事物都是3片或9片。这意味着这些事物是由3或9张小图片构成，这些图片会延展和重复以便呈现一个更大的外观。这为了我们节省了一些内存，只是想出这个方法颇费了些功夫。

为了创造用户友好型界面，我们从苹果设计师的做法中汲取灵感。如果你有iPhone，请打开通用设置，或者Facebook，你会最先注意到其出现的框架。

为什么？

它的设计方式就是让用户一摁下按钮，就会发生一些情况——你马上就会获得反馈！即使你想到看到的并不是空屏，它也还是会给你一种快速响应的感觉（或者幻觉）。使用这种模式，我们重新回头重构了每个屏幕，令其以这种方式呈现。当你玩《Mech Force》的时候，你会看到所有屏幕加载特定的UI成份，其余内容也会紧随其后快速跟上。

步骤1：在摁下按钮时就加载背景画面。

background images(from gamasutra)

步骤2：淡入其余内容。

fade in the rest(from gamasutra)

以这种方式制作UI当然并非最有趣的选择，但有趣并非制作原代码的必要选择，因为这里的所有内容都需要比原来快100倍。然而，因为你是在自己的设备上的一个网站中体验整款游戏，我们并不想以HTML5作为游戏运行表现不佳的借口，所以投入了许多时间和精力，以便让这看起来不像是一款典型的HTML5游戏。

未来发展

展望未来，随着硬件技术的发展，我们已经看到iPhone 4S和iPhone 5之间双倍提升的性能，这有助于我们制作出外观更出色的HTML5游戏。但我们所获取的UI知识和创意技巧，可以让我们制作看似运行更为快速的游戏。在这个过程中，我也学到了许多游戏设计知识，这不只是关于制作有趣的游戏，更重要的是整体用户体验。

技术局限性不成为我们制作出想象中游戏的障碍，而应该是迫使你去寻找创意解决方案以达到理想效果的动力。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Producing a Game in HTML5

by Christopher Brousseau

The following blog was, unless otherwise noted, independently written by a member of Gamasutra’s game development community. The thoughts and opinions expressed here are not necessarily those of Gamasutra or its parent company.

Want to write your own blog post on Gamasutra? It’s easy! Click here to get started. Your post could be featured on Gamasutra’s home page, right alongside our award-winning articles and news stories.

Producing a Game in HTML5

Background

My name is Chris and I work at Big Viking Games, a mobile and social game development studio. We are currently working on HTML5 games for the iOS, with plans to make these titles available through Facebook, and eventually Android devices. Big Viking is committed to becoming the leading HTML5 game makers of this generation, and we plan on going all-in with this crazy adventure, and believe me, it’s been crazy! I started off as a Designer and have moved into the role of a Producer, where I work at the high-level of design and oversee the entire process of development.

I’ve seen some pretty impressive content created in HTML5 on the PC, but the greater challenge is getting it to work in a mobile environment on iOS with UIWebView. This blog post will outline a few of the technical limitations of HTML5, while showcasing creative ways of overcoming these barriers in order to deliver an exceptional game experience.

Technical Limitations of HTML5

How do I begin to explain creating a game in HTML5 to those with no technical background? I personally am not the most technically adept person around, however I do have previous programming experience (mostly in C#). I’m sure you have seen a website before. Although there are many parts to it, it essentially is made up of images and text, right?

Well, HTML5 is also just made up of these components, and therefore when you are making a game, you are limited to images and text. The difference is, on a website when you click a button, another page loads, or some sort of change is made to the current page. In games when you hit something, a change is made through animation or sound – all while having an entire client/server component talking to each other.

Because we are creating animations in Javascript, they are difficult to come by due to the fact that even simple animations cause a large amount of load on a mobile device’s CPU. Further compounding the problem, iOS6 introduced a bug which negated the ability to offload some of the work to the GPU, which has severely hindered what we were able to do.

When you play Mech Force and enter a battle, doors slam, things spin and Mechs engage in a Western staredown. When I approached the Dev Team with the suggestion to add an explosion in there, the programmers looked at me as if I had spawned a second head. Adding in an explosion would cause the game to go from 60 frames per second, to 20. Wooooo!!!!

(Look at them staring lovingly into each other’s eyes!)

Referring to the image above, each Mech is made up of 14 individual images, the door alone is 5 because the circle image in the middle is animated with spins and overlaying text.  The windows are 2 images each, and in addition there are moving health bars and text. Any animation is just a spritesheet where we loop through all the images and shown them in order, giving the animated appearance.  Needless to say, there’s a lot going on in this screen. In fact, there is so much going on, that one single explosion would have caused it to lag like crazy on an iPhone4s. It would be supported on an iPhone 5, but we found it important to make this title equally compatible on both the 4s and 5.

Memory is another issue we ran into throughout our HTML5 development experience. With all of these images on screen simultaneously, a lot of memory is required which will often cause the game to randomly crash. The first thing iOS will kill when it starts to run out of memory is sound. This means the music in Mech Force would just randomly stop from time to time, which of course creates a great user experience! [*eye roll*]

Games + HTML5 = ???

So how does HTML5 fit into the gaming world? Games are certainly possible in HTML5, they just can’t be overly graphic intensive. The best games for HTML5 are actually text based games or card games, which is what the game Rage of Bahumut did. Developing a game in HTML5 is almost like developing a game for the SNES. The being that the evolution of games has subsequently created expectations – such as ParticleEffects, animated images, and sound!

Imagine that! Actually, all of that was expected back on the SNES, as well. However, these days the graphics need to be better, made for high def, and run on small devices with crazy high resolutions, such as the iPad3. The other option would be for games to have little to no animations. Remember, mobile platforms create issues for memory and make it difficult to have many images on the screen at once.

However for Tiny Kingdom, which is another of our HTML5 games in development, we re-built our game engine with lessons from Mech Force. Knowing that we wanted to accommodate 4 VS 4 battles on the screen at once, it seemed like the most viable option. We are actually able to do it using some really terrible, silly tricks which really don’t make any sense at all. For example, if you set opacity to 100% before the animation, and then set it to 100% after the animation, you will get a 20 frame per second speed bump! Figure that one out…

So, RPG’s are a good fit for HTML5 – you can make huge “worlds” and a generally awesome game, while not being expected to have crazy amounts of animations. The second most desirable option would be card games. Further, games where you can simply build things, so long as they are not animated, would also be a great fit in HTML5. Kingdoms of Camelot is a perfect example of a game which can be built in HTML5 easily, without compromising quality. On the other hand, games like Angry Birds are not ideal. Any real action game where you need things to react quickly are no good. Therefore, first-person shooters and platformers should probably be avoided. The options are there, you just have to be smart about what you build.

HTML5 and Creative Design Decisions

In my recent Production experience, I have come across many creative obstables which needed to be reworked in order to optimize functionality in HTML5.

Most notably, in Mech Force we had a lot of wrenches thrown our way design-wise, as our original plans impeded on the functional capacity of HTML5. As an example, rather than being able to create epic Mech battles, we had to settle for simulating them behind the scenes.

Simulating battles required us to reconsider our original plan and come up with additional options. Our original plan with Mech Force battles was to show  players who they were fighting when they were picking an opponent. However, we had to load 14 images and recolour them before we could show the player, and this took 1.2 seconds to load. So instead of just showing a loading bar which is frustrating, we created an animation and made the Mechs teleport in.

A second challenge was figuring out how the Mechs were going to travel throughout the game. We realized we could not have the Mechs walking around the way we originally wanted, as it’s technically not possible. We put our heads together and came up with the idea of teleportation and made the Mechs teleport around in a really cool way.

My current creative struggle lies in designing a feature which allows players to raid other bases. As cool as it would be to see all your ships fighting other ships, I have to take into consideration the amound of images that would require. Keeping in mind the memory limitations, I am tasked with coming up with a creative way for players to visualize the battle without actually seeing it.

Shifting gears to Tiny Kingdom, we planned on having characters flash a different colour when they get hit. Well, that is computationally expensive and therefore, out of the question. In exchange, we went through and made a hit animation for every single one of our enemies in the game. In terms of man time it costs us much more, but this is one of the sacrifices we have to make. Small sacrifices always take precedent when it is a matter of game quality!

Smart UI

Creating a smart User Interface was perhaps the biggest challenge we faced with HTML5, especially because we are still developing with the iPhone 4s in mind. Creating an intelligent and efficient UI forced us to consider how the game would be loaded on various devices. User experience heavily relies on response time, and if loading times are too long, the game could be deemed undesireable or unplayable. Mech Force was, at one point, designed so that everything ran concurrently and would not be shown until all parts were ready to be displayed. However, this cause the game to take multiple seconds to load between each section of the game. Moving from one task to another could take up to 3.5 seconds and we ruled this as totally unacceptable.

It took the Mech Force team a considerable amount of time to learn how to develop and implement ideal UI. As an example, everything in the game is a 3-slice or a 9-slice. This means it is made up of just 3 or 9 little images that are streatched and repeated to give the appearance of big screens. This ultimately saved us a bit in terms of memory, but took some time to figure out.

Looking to create a user-friendly interface, we looked to the big guys at Apple for inspiration. If you have an iPhone, go and open up General Settings, or even Facebook, and you’ll notice the frames will come up before anything else.

But why???

It is designed in such a way that as soon as you press a button, something happens – you get feedback instantly! Even though a blank screen is clearly not what you are after, it gives the appearance (or illusion) of reacting quickly. Using this model, we went back through and re-constructed every single screen to behave this way. When you play Mech Force, you will see that all of the screens load certain portions of the UI, and the remaining content follows shortly after.

Step 1: Load the background images as soon as the button is hit.

Step 2: Fade in the rest

Making UI this way is certainly not the most fun, and it’s not necessary when doing native code, as everything is about 100x faster. However, because you are playing an entire game within a website on your device, and we don’t want to use HTML5 as an excuse for performance, we put a lot of time and effort into making it not seem like a typical HTML5 game.

Going Forward

Moving forward, with hardware getting better, we’ve already seen a 2x improvement from the iPhone 4s and the 5. This should allow use to make better and cooler games in HTML5. However, the knowledge we gained in regards to UI and creative tricks will allow us to create seemingly faster games in general. Throughout this process, I also learned alot about game design in general – it is much more than just making fun games, there should be a focus on overall user experience.

Technical limitations should never stop you from creating the game you want to make. Instead, it should force you into thinking about creative solitions to these obstacles in order to achieve the same effect you are after. You actually CAN have your cake and eat it too, you just might need to add some funky ingredients! （source：gamasutra）