所以2014年，他创办Layabox，专做H5引擎开发，并获得了合力投资天使轮1000万元投资。目前，公司正在进行A轮融资。

谢成鸿说，成功的游戏有相似的成功轨迹，失败的游戏却有各自不同的失败原因。这么多年的创业经历，给予他的，无非是宝贵的成功经历，和更宝贵的失败经验。

layaair 网页游戏

然而，2012年时，单个用户的营销成本已经涨到200元了，在这种成本面前基本怎么做怎么亏。对游戏来说，一旦失去了最好的市场机遇，其实是逆势的斗争，等待自己的只能是苦涩。

谢成鸿的团队曾经开发过一款叫《猎刃》的游戏，看起来和《怪物猎人》很像。07年获得投资，08年发布，却到了12年才正式上线。

当最后一款3D端游《猎刃》推出失败后，投资人撤资、被迫裁员平板电脑三国游戏单机，300多人的团队，裁减到几十人。面对大笔遣散费，谢成鸿没有选择破产，他卖掉了自己的房子。

有一天，他看到一个外国人用网页写了超级玛丽，当时就很惊讶，HTML技术竟然可以达到这样的效果。后来他就自己琢磨HTML技术，开了公司做了几款小游戏。他和新浪合作，3个月赚了300万。

1988年，还在读大学一年级的时候，喜欢玩游戏的谢成鸿就想着自己去编写一个游戏玩。1996年，他用RPG的形式做了一款游戏教育软件，引起了很大反响。

就腾讯给出的H5游戏转化率来看，比起App高出不少，这其实是对于H5游戏的利好消息。而能够达到这一点，主要出于H5游戏的几个优势：

同时，开发者使用最新的LayaAir引擎编写完游戏，可以同时发布H5、App以及Flash页游三个版本。H5最难搞的兼容问题，就这么解决了。

直到App出现后，其势头才渐渐变弱。如果H5能够提供一种兼容Flash和App的开发语言，特别是对于游戏开发者来讲会省去很多力气。

Layabox在经过这几年的不断调试之后，特别Laya Air引擎采用C++实现H5通用加速器，性能上已经基本媲美原生App。

近期，PC端流水超6亿的《醉西游》，通过Layabox的引擎改为HTML5在QQ浏览器内首次删档封测，FPS数据达到60帧，已经接近App体验。

创始人兼CEO谢成鸿是和陈天桥等游戏人一代的资深从业者，并且精于技术开发。1999年，凭借HTML游戏年入百万，也是2000年全球最大的页游平台“可乐吧”创始人。2011年开始，投身HTML5引擎的研发之中，先后使用自家Laya引擎推出了休闲游戏《疯狂雪球》、卡牌游戏《三国喵喵传》、动作游戏《猎刃2》。

他们主打的Laya Air引擎，支持使用AS3、TypeScript、JavaScript三种语言开发HTML5，主要用于游戏，也可用于营销、教育等场景，核心库为100K左右。

Layabox是一家HTML5引擎技术的提供商与游戏发行商，也是国内为数不多专注于为大型HTML5游戏开发引擎的技术型公司，旗下有LayaAir，LayaPlayer和LayaOpen等产品。

推荐全网最火的6款前端开源游戏引擎！

跨平台：Egret 本身是用来开发 HTML5 页面游戏的，但 Egret 引擎早考虑了原生游戏的需求，因此提供了 Android Support 和 iOS Support，使得原本只能在 HTML5 环境运行的游戏可以通过简单的步骤生成原生游戏

Egret Engine 是一个 HTML5 游戏引擎，它提供模块来处理常见的游戏开发任务，例如 2D 和 3D 渲染、GUI 系统以及音频和资源管理。 Egret 引擎非常灵活，适用于 2D 或 3D 项目， 它允许开发人员在编码时不必担心底层浏览器实现、HTML5 性能或碎片化问题。

开发者可以克隆 GitHub Repo 并按照自述文件中的步骤进行操作，也可以在下载页面上作为 Cocos 包的一部分进行下载。 无论选择使用 C++、JavaScript 还是 Lua 进行开发，所有内容都打包在一个包里。 Cocos 系列产品有几个不同的组成部分。

需要注意的是，引擎中很多适配模式，都是画布全屏适配。这个时候，设置画布的对齐没有意义。只有画布不能全屏的时候，例如showall和noscale模式才有这个需求。

需要注意的是，浏览器中运行的时候，引擎的自动横屏和自动竖屏，只能对画布进行旋转，如果用户的手机锁屏了，虽然游戏自动旋转过来了，但是浏览器没有旋转过来，会导致输入法依然按浏览器的方向弹出，此时，可能会导致输入法与浏览器的显示呈90度。如果在小游戏平台中运行，由于有横屏还是竖屏的配置，不会出现这个问题。

LayaAirIDE的UI组件中提供了基于父容器的相对布局属性，如top、bottom、left、right。我们可以把需要特别处理的按钮都统一放到一个容器组件中，例如box。然后，我们在场景Runtime类的onAwake生命周期中，控制这个容器的相对布局属性，就可以实现在刘海屏下进行特殊的位置处理了。

目前市面上的机型，虽然分辨率碎片化严重，但是仔细总结一下，可以发现一个规律，那就是分辨率的宽高比就那么几个。至少，全面屏的机型，宽高比肯定是大于2。所以，我们可以获取屏幕分辨率的宽高，然后计算出宽高比。大于2的，就当成刘海屏进行适配处理。

自从推出iPhoneX全面屏手机以来，全面屏手机越来越多，但实际上绝大多数机型做不到真正的全面，所以就有了凹凸屏，刘海屏，水滴屏等叫法，这就给我们适配带来了麻烦。但找到规律之后，其实也并不是太复杂。下面分享一种常见的处理思路，大家根据这种适配思路来具体调节适配。

虽然说该模式，通过相对布局二次适配，也可以让被裁剪的按钮等回归到屏幕内容之中，但二次适配的方式要更加复杂。所以不推荐使用该模式。

另外，该模式画布与舞台宽高会保持与设计宽高相同，所以全屏适配全靠对画布的缩放，没有使用视网膜模式的情况下，物理分辨率远超设计分辨率的时候，会因拉伸产生模糊。

noboder的适配规则与showall，恰恰相反，是取物理宽高与设计宽高比的最大值进行缩放。会导致当分辨率宽高比与设计宽高比不同的屏幕上，设计效果一定会超出屏幕，被裁切掉一部分。所以也就无法留出画布或者舞台的底边了。

showall模式由于画布宽高已经进行了缩放改变，本身就是高清的适配模式，所以这种模式无需使用视网膜画布模式（useRetinalCanvas），用了之后，画布采用了物理分辨率，反而不好。

但也并非没有好处，好处就是都不需要用相对布局二次适配了，设计效果什么样就一定是什么样，肯定是全部显示，不变形，不被裁切。而且由于改变了画布的大小，在物理分辨率差异比较大的屏幕上，也不会因为设计分辨率小了而导致模糊，仍然是高清的。坏处就是做不到手机全屏适配，所以该模式，通常不会被用到手机适配上，在PC浏览器运行的横屏页游，推荐使用该模式。

showall模式的适配结果与fixedauto非常像，也是保障设计宽高一定会在屏幕内全部显示，但区别和问题是，showall模式的画布和舞台并未做到所有分辨率下的全屏适配，只是按物理宽高与设计宽高比的最小值，进行等比缩放，并且改变了舞台和画布大小。因此，留下的空白部分，就是舞台无法控制的部分，导致在与设计宽高比例不同的手机上，就真正的无法全屏适配了。

这种模式，其实最终采用的是fixedwidth或者fixedheight，是通过物理宽高比和设计宽高比进行对比判断。物理宽高比小于设计宽高比的采用fixedwidth模式，否则就采用fixedheight。

在这个模式下，画布和舞台宽会等于设计宽。但画布高和舞台高会按物理宽与设计宽的比例进行缩放后改变，不采用我们配置的设计高。所以，当改变后的画布和舞台高大于原来的设计高，底部就会露出画布背景色。如果改变后的画布和舞台高小于原来的设计高，那就会被裁剪掉多出的部分。

在移动端，我们通常会需要保持设计宽高等比缩放的全屏适配方案。而以下几种模式正是我们推荐开发者优先采用的适配模式。如果是3D游戏，建议开启视网膜画布（useRetinalCanvas）模式。

该模式是所有适配模式中，唯一不需要开发者作额外的适配调整，就能保障在任何机型下都可以全屏显示、不留空白、不被裁切的适配模式，缺点也很明显，就是当物理宽高比例与设计宽高比例不同时，会产生拉伸变形，适用于对界面产生形变没有严格要求的开发者。

拉伸至物理宽高全屏，所以除非是设计宽高与物理宽高相等，否则就会有一些因拉伸产业的变形。不同机型的宽高比例差距越大，变形的越明显。

exactfit是一种不等比的全屏拉伸适配模式，画布宽高与舞台宽高会等于游戏设计宽高 。然后完全不考虑比例强行缩放至逻辑宽高全屏。所以除非是设计宽高与物理宽高相等，否则就会有一些因拉伸产业的变形。屏幕分辨率宽高比与设计宽高比差距越大的，变形的越明显。

特别说明一下，背景屏幕颜色为黑色的是画布默认背景色，不是stage背景色。通过Laya.stage.bgColor可以改变默认的画布背景色。在noscale模式下的白屏背景那是浏览器默认的，说明画布就那么大，画布没覆盖到的地方就是白屏背景。

full模式表示着画布宽高和舞台宽高一定是完整的全屏状态，但和noscale模式一样，并没有对设计宽高做缩放处理。在full模式下，画布大小直接取值物理分辨率，物理宽高是多少，画布就有多大，该模式下设计宽高参数的设置无意义，直接设置0,0即可。

noscale模式是引擎默认的模式。该模式下，在任何屏幕都会始终保持设计时的物理分辨率原样效果，相当于将不缩放的设计宽高画布直接贴在屏幕上。物理宽高和设计宽高相等的屏幕会全屏显示，物理宽高低于设计宽高的会显示不全，物理宽高超过设计宽高的会留出屏幕背景（白屏）。

在适配对比的机型选择方面，iPhone4的640 × 960代表老旧机型，宽高比为1.5，只是为了对比适配效果。iPhone8的750 × 1334是我们为设计宽高选定的机型，宽高比约为1.78，无论哪个模式都是完美的1：1适配。iPhone8 Plus代表着同样约为1.78宽高比，但物理分辨率和DPR都与iPhone8不同的同比例机型。iPhoneX代表着宽高比大于2的各种全面屏机型。

LayaAir引擎的适配模式有8种，为了让大家真正理解各适配模式的适配策略，以便更好的进行屏幕适配。本节以LayaAirIDE创建的2D示例项目为例，将设计宽高调整为750×1334的竖屏界面，分别就各个适配模式对比不同机型进行讲解。

所以解决办法就是使用物理分辨率的适配模式，或者在当前适配模式的基础上，开启视网膜画布模式，将画布强行按物理分辨率进行设置。

在图10左侧，是画布物理宽高一致的情况下，画布像素与物理像素是重合的。图10右侧，当画布宽高小于物理宽高时，被适配规则将画布拉伸至全屏后，导致的画布像素与物理像素产生偏差错位。这就是加重边缘锯齿的根本原因，导致引擎抗锯齿功能也很难完全消除过于明显的锯齿现象。

如果抗锯齿在开启状态下，发现仍然是无效的。那就需要检查是不是使用了相机的HDR或者后期处理。webGL 1.0不支持renderTarget有抗锯齿，所以想避免锯齿感的，要在Unity里导出资源时，不要勾选HDR相关选项。或者直接在引擎里，创建相机后关闭HDR。示例代码如下：

另外，3D模型的基础构成是三角面组成的多边形网格网页三国游戏论坛贴吧最新，绘制3D多边形构成的模型，这和我们矢量画斜线、画曲线、画圆，是一样的道理。所以非矩形的矢量图形和3D模型，产生锯齿这是正常的。当然LayaAir引擎内置了抗锯齿方法，并且在3D库中默认开启了，2D想开启的话可以在init()之前加入Config.isAntialias =true;。

我们屏幕的像素点，是由行与列的矩阵序列组成。也就是说屏幕中是不存在斜线的。基于像素绘图的画布，要是画横竖的直线，那绝对是相当的平滑。可是画曲线和斜线怎么办。只能是由两个相邻的像素点不断重复延申组成，如果这句话不好理解，我们想象一下楼梯，从侧面去看，大概就是这个样子。

更何况，可以通过判断机型或分辨率，进行动态控制视网膜画布模式的开关。也有的开发者，在一些压力比较大的页面上关闭视网膜画布模式，其它页面开启视网膜画布模式。

一旦开启视网膜画布模式后，有的开发者会比较担心性能问题，毕竟采用物理分辨率作为画布宽高后，代表着画布上的像素可能会比原有设计宽高要多，这的确会对性能产生影响。但绝对没有想象中差距那么大，尤其是越高分辨率的机型，通常硬件条件也会更好一些。根据我的推荐，一些开发者调整之后，事实上也没有太大的影响。

默认情况下，stage宽高直接等于设计宽高。在full、fixedwidth、fixedheight、fixedauto的适配模式下，stage宽高会根据适配规则产生变化。

在不同的屏幕分辨率比例下，总会有适配规则不能覆盖到，难以做到既想等比缩放，又想在各种屏幕下都做到游戏内容满屏显示。但其实上，只要舞台宽高可以占满全屏，那就一定可以做到各屏幕全屏显示。因为，游戏的显示与控制就是基于舞台的，舞台全屏就有了在适配的基础上调整显示的空间，毕竟不可能超出舞台来显示游戏内容。

基于以上种种，我们需要了解适配宽高这个概念，适配宽高才是适配规则处理后的最终效果宽高，会直接影响通过DPR还原后的最终效果。

由于Canvas是基于位图像素绘图的，画布宽高对画面质量及性能有影响，又或者诸如plus特殊的分辨率等问题。所以不能通过直接改变画布宽高来适配，否则会出来一些适配问题。在LayaAir引擎中会根据不同的适配模式规则，计算出适配宽高需要缩放的比例，然后通过transform的matrix（矩阵）来对画布缩放至逻辑分辨率范围内，再通过viewport与DPR机制缩放还原。