被靠北游戏业钓上来了，来认真发一个技术文...... 不过在这之前，我的主观认定是这样的： * Web 上，Flash 或插件为主的游戏会在接下来两年逐渐消失 * 手机上，主力仍会是无法在 App Store 或 Google Play 上架的游戏 「大作」仍然会遇到各种麻烦的技术限制 （因为这里是讲免上架 HTML5 浏览器游戏，容我跳过 JS + Native 的方案 例如已经成形的 Cordova / PhoneGap, Titanium 还有很有可能窜起的 react-native） 好了，以下技术长文。 大体来说，现在 HTML5 的游戏技术实践 可以先以 Rendering（渲染）和 Scripting（程式）这两方面去作区别 Rendering 可以走 DOM、2D Canvas 或 WebGL 走 DOM 不用多说，手机看很多网页卷动还是超卡，基本上不实际 2D Canvas 或是 WebGL 才是比较理想的解答，其中 2D Canvas 的支援比较理想。 iOS 直到去年的 8.0 才预设开启 WebGL，所以这可以说是比较新的领域。 WebGL 1.0 其实基本上就是整个 OpenGL ES 2.0 API 开个网页用， 用在游戏上「照理说」可以一样的 3D 效果，但问题卡在 Scripting，後述。 Scripting 的部份，很遗憾目前我们还是只有 JavaScript 目前大概就是纯 JS 与 asm.js (Emscripten) 两个方向了 （tl;dr: JIT 加速 / ES6+ -> GC pauses -> 多绪困境 -> asm.js -> WebAssembly） 这几年纯 JavaScript 如同推文说的，慢的问题已经随着 JIT 解决 语法脏的问题已经随着 ES6 / Harmony 的发展走进历史，ES7+ 根本是外星语言 虽然对於写游戏来讲，我觉得 JavaScript 已经足够，用什麽语法只是个人喜好 实务上，像 Chrome 的 V8 都已经作到两段式的 JIT 加速 第一段基础加速，猜测物件型别，在第二段时将瓶颈编译成机器码 所以对於非常简单的 Loop benchmark，现在的 node.js / Chrome / Firefox 都能乐胜 问题在於 JIT 造成的记忆体消耗，以及最大的致命伤，GC Pauses。 JavaScript 必须仰赖 Garbage Collection（垃圾收集简称 GC）作物件清洁 但垃圾清洁就需要时间，这个时间会变成一个定时炸弹 你永远不知道浏览器什麽时候会作 GC，也很难从外界直接干涉 另一个问题大家也讲到了，JavaScript 很难作多序。 JavaScript 一开始就像所有的 UI 框架一样采用单序 Event Loop 的设计 所以到了後来要加上平行运算就只能用像 Web Worker 一样的作法 因为 GC Pauses 与平行运算的限制，WebGL 的 Game Loop 几乎无法作任何复杂运算 但如今产业已经慢慢在克服这个问题，从早期的 asm.js 到现在的 WebAssembly 也许在过几年，我们会慢慢看到不需要插件的复杂 3D 游戏在网页上出现 --- 回到实务上，重新聊回 HTML5 手游。 目前受限於技术、手机效能、手机作业系统支援等等因素， 即便 WebGL + asm.js / WebAssembly 的组合很吸引人， 但短期内这个方案依旧无法在手机上支援纯网页的 3D 游戏。 因此 HTML5 手游短期内的市场还是会以 2D / 2.5D 游戏为主。 所以问题才会回到金流上面：没有官方商城加持，你很难作课金游戏。 所以我的结论就是没办法上架的游戏才会有市场。 而且这个市场说实话到了 Android 5.0 / iOS 8 世代手机才堪称开始。 接下来会走向何方有点难说，但让人拭目以待。 --- 自婊利益揭露：我上一个创业雇主就想做十八禁手游框架，可惜天时地利人和不对... 我猜这个搞不好明年会起飞，只是产业需要花很多时间适应手机玩家习惯 （手游跟 PC Game 玩家的使用习惯真的差太多，你可以边等公车边吃饭边玩手游） --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 111.249.194.67 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/GameDesign/M.1446484479.A.CEA.html