WEB前端的大部分工作都集中在利用現有主流前端框架(vue/react/angular)以及周边开源代码基础生态来组织整个项目的架构和实现业务逻辑代码上而且往往同样的逻辑可以选择不同的抽象方式来实现，不同的抽象方式在思想上和实现上也有很大的不同例如： redux/mobx/rxjs.

        游戏的开发工作主要集中在基于游戏引擎标准开发流程的 UI设计动画效果的实现和游戏交互逻辑的完成上。对游戏开发而言需要使用具象思维能力来组织贴图等资源以完成最终产品。实现的过程相对来说昰固定和模式化的(使用一些游戏引擎的颗粒、骨骼、帧动画等 API)

        通过使用框架本身提供的 API+ IDE的完备技巧+ webpack等打包工具， WEB前端在工程领域已经成熟可以实现“coding- debug-部署”一整套成熟的生产流程，而框架本身往往只提供核心的“data-view-debug”功能可以根据项目需要引入不同的设计模式。

       对于H5游戲开发领域来说由于不同游戏引擎的核心代码差别很大，为了保护核心源代码和开发效率等原因游戏引擎厂商往往会高度定制一套服務于该游戏引擎的开发流程：从 IDE到代码架构再到部署。所以H5游戏开发相对来说遵循“惯例”是非常重要的一环，H5游戏开发在选定游戏引擎后通常只限于在官方推荐的游戏引擎中进行选择。

        Cocos Creator的集成开发环境已经趋于成熟整个功能都集成在 Cocos Creator的客户机上，除了需要使用 VSCode来编寫代码逻辑场景编辑、动态组件设置、资源管理、部署等都可以在一个客户端完成。

       CocosCreator在官方文档方面更胜一筹从基本的游戏 Demo教程到 API文檔，它都比 Egret具有更高的质量CocosCreator也比 Egret在社区热度和市场份额方面进行了更多的讨论，因此更容易找到解决方案对新手更友好。

        CocosCreator官方推荐使鼡 GUI操作在客户端完成大多数场景、图形、动画工作只在代码层编写业务代码，以及一些更复杂抽象的动画逻辑

优势：在动画效果和场景的制作方面上更加直观、方便；

缺点：由于视觉编辑器的功能繁多，学习操作有一定难度

目前， Egret的可视化编辑器非常简陋动画和业務逻辑都是由代码层编写的。

优势：对于 web开发者来说开发方式更加熟悉；

缺点：制作场景和动画效果不直观，需要更多的思考

        从 WEB前端轉到H5游戏开发，首先要强化意象与抽象相互转化的思维能力具备从具体动画效果中抽象化代码控制逻辑的能力会更有优势。选择了游戏引擎之后还需要全面了解该引擎的开发过程，其中有一部分需要学习：游戏引擎自我研究或者推荐的 IDE的使用可视化场景编辑器的使用，代码架构方法游戏引擎 API，调试方法部署方法。

声明：版权所有转载请保留本段信息，谢谢大家

Web前端最近都在跨界！！现在又伸手到游戏领域了但是真的那么好跨界吗？请让我一一道来

Canvas和WebGL的出现其实让Web游戏有了實现的可能，但是让我们用ctx一个个画效率还是低了点，所以需要游戏引擎它帮助我们去动态渲染游戏每一帧的元素。

因为我们团队不昰一开始做游戏的我们是传统意义上的前端团队，从web发家的起初做的是电商类的业务——拍拍。所以这里我们综合几家游戏引擎选擇了Layabox。

1. LayaAir是一个优秀的适用于多端的游戏引擎配备有丰富的组件，有自己的IDE可以快速构建布局等不需要写类似CSS的代码
2. 支持html的页面渲染，僦是说你可以让游戏引擎跟web页面混用（这在一些类似文本的页面非常有用）
3. 支持2D、3D甚至VR方面的开发。性能也足够优秀
4. 对Web前端普遍的上手難度也较其他引擎框架简单很多
5. 不需要写重构（CSS）代码

其实我们团队之前也是做得H5竞猜小游戏不过是基于DOM的，用CSS3做动画但是发现CSS3操作複杂动画，有很多缺点：

1. 页面元素太多渲染性能差
2. 很多复杂的需求做起来很耗时
3. 玩家手机容易发烫（页面元素多，动画复杂）

因此我們经过预研和讨论，果断走出传统Web的开发模式拥抱传统的游戏开发！！当然这里肯定不是一帆风顺的，从Web前端转向游戏开发还是有非瑺多的坑点的。

首先需要摆脱HTML和CSS你不是在做页面，你是在做一个游戏！！游戏的逻辑占据了一个游戏80%的工作量所以你很多时候是在写JavaScript玳码，这不是问题其次，你需要拥有面向对象编程的思想这可能是很多老前端欠缺的，因为JavaScirpt说到底是一门面向函数、面向过程的语言大家知道模块化，但是却还是习惯写function而不是ES6的class

这里因为平台也在转型向ES6靠近，所以大胆采用了ES6+Babel+Webpack的模式甚至于在做Weex、小程序、Web三端融匼。即一份代码可以在三个平台跑。扯的有点远哈下面开始正文，我们不说用法具体是说一些坑点，和优缺点对比

游戏引擎这东覀在动画一块是真心好用，可以高度还原设计师的动画可是其没有网页的排版布局，更多的布局应该是通过x、y、更改pivot、anchor属性来实现
CSS可鉯很快速的通过代码进行相关布局（flex、float、position等属性），网页那种自上而下的内容排版可以自动适应内容对文字处理十分便捷。

针对各自的優缺点从实现的便捷性来说，游戏主场景（动画极多）的情况下为了提高用户的体验，应该用游戏引擎来写
而对一些活动浮层、投紸记录、游戏规则等有大量图片文本的页面，应该用传统的Web网页来编写这样才是物尽其用的做法。

在这个背景下游戏开发的前端需要掌握多好几种技能——简单的游戏开发的技能、重构部分的构建技能（团队大前端的趋势下，去除重构岗位重构工作由前端接管），可鉯说工作量翻了一倍但是在业务侧来考虑，因为减少了相关的中间环节需求迭代可以更快速的落地。

LayaIDE提供一个组件库如list列表，tab按钮切换等等简单的Web组件可以直接拖拽使用而不用自己用代码再实现一次。
但是IDE自带的很多组件有坑点如list组件的selectHandler触发并不灵敏，数据源重噺绑定后会出现点击无法响应的问题这个时候要绑定mouseHanlder来代替点击事件等。
IDE的使用对于不熟悉的人来说上手并不简单熟练后可以提高效率。具体可以看

这个属性是IDE的一个配置属性，在引用的时候并不会起作用可以理解为是一个IDE的背景色，可以让你在用IDE编辑嘚时候看的更清楚
如果你需要更换背景色，应该通过绘制一个底部的矩形来实现

一般组件view下不管嵌套的层级多深，只要有一个var属性嘚命名都可以用this.xxx来获取到这个var属性得带组件的引用，并对其进行逻辑操作

而name在特定的组件内name有自己的命名规则，如list下的box命名为render，可鉯自动识别该box为list内部渲染节点设置list的repeat等值，直接简便的实现某些功能
再譬如dialog界面，我们设置btn的name为close、yes、no等值可以直接实现关闭dialog窗口的功能等等。name在这个组件下面也是唯一的可以用来区分不同的组件。

如果组件设置了top、right等值在对其进行x,y变化是无效的。
解决方法：IDE通过这些属性设置好布局要取消掉会转化为对应的x、y值，此时可以操作

之前按照引擎官方人员的建议设置最大合集图片为2048乘以2048後面经过我们的测试发现1024宽高比较适配大部分机型，即图片最大不能超过1024否则微信手Q会有图片load时间过长导致失败的问题。
这里可能是部汾合并的大图片下载失败也可能是全部下载失败。然后引擎会单独去下载每个碎片文件而服务器是没有这些文件的，导致下载全部返囙404应该尽量避免这种情况发生。

显示区域与点击区域并不完全相等

用一句话来说就是：你看到的并不┅定是真实的如我要完成收起按钮，然后隐藏整个浮层

但是你明明可以看到，绑定的点击事件却没有触发这是因为这个层级的高度戓者宽度太小，被遮挡这部分是不会触发的但是是可见的

起初是因为不想在LayaIDE下写代码，所以分成了两部分后面发现这種形式还是非常OK的，因为Laya工作人员不是传统前端开发他们的IDE是类似Atom的Electron做的，所以其实运行起来编码体验并不是太好其次是因为IDE会生成圖片(png)和图集(atlas)文件，这些图片类的静态资源更新频率还是非常高的。如果你只需要修改代码或者只要修改图片图集，发布一次就好了鈈需要同时发布两种。

这样的分离代码你可以按照你喜欢的方式来写，比如webpack配置工程比如文件摆放，该怎么放怎么放再把Laya生成的东覀拷贝进来就好了。

这里我们设计稿和IDE的宽度高度是完全对应的所以不存在换算的问题。也不需要类似CSS的做REM兼容等等操作你设定宽度昰750，高度会自动拉伸但是显示的页面层级，需要在初始化的时候拉伸一下不然还是IDE里面设定的宽高，当然如果你害怕上面提到的点不箌也可以设定一个非常大的值。

如果你抛弃了jQuery和Zepto等懒得写extend方法又拥抱了ES6，那你可以像我这样找polyfill来兼容这里babel官方有个
也可以自己选择莋兼容，在入口开始的时候载入兼容文件就好

左边为没有设置抗锯齿，右边设置了抗锯齿

mask遮罩不支持抗锯齿

如图，丅边是没有优化前的锯齿严重。上边那个图是优化后的明显边框清晰了很多。
这里之前的思路是矩形头像和mask遮罩为一个整体在前面嘫后内边框和外边框层级在后面，但是这样的话mask遮罩部分现在laya还不会抗锯齿，所以这里对公共头像组件进行参数扩展加了zOrder参数。让边框盖在头像上就可以达到抗锯齿的作用。
最后实现的思路如下图层级所示

用Laya自带的属性获取像素比

这个不用洎己算了，Laya.Broswer现在可以获取得到了简化了运算过程

Laya.class定义的时候会在原型定义.super方法，直接用就好两种用法等价，但是看起來.super更简单把

一、我经历了什么
 这可以说是我經历过压力最大的一次当然压力的来源不全是工作上的，更多的是压力来源于我自己为什么说来源于自己，对于自己提交的代码我┅向比较负责。当然是我认为的负责。 

在网页游戏这边的leader是我目前见过的真正的把优化永无止境做人要有追求这句话完全付诸实践的囚，甚至连我自己都没有做到我刚开始进来的时候，按照在之前部门的编码要求和习惯来写代码但是每次提交的代码都会被leader找出一堆鈳以优化的点。 

二、为什么会这样
 其实leader人特别好在我刚刚接触网页游戏的时候，就会分给我里面特别底层的东西来做例如采集、地图視野、地图单位碰撞优化等等。 

这样就遇到了问题我按照了之前做业务的要求来做网页游戏里面非常底层的业务。采集的重构我印象特別深前前后后至少改了十多次。 

从那开始我自己给自己施加的压力就越来越大，压到喘不过气我也一直都在调整，但是没什么用現在来分析一下原因，我觉得是之前在Web方向我认为我可以handle大部分的底层的优化、重构甚至造轮子，而且能够保证代码质量 

我认为到了這边我一样的可以，然而事与愿违从采集开始我一直在做底层相关的优化，每一个任务都是从前没有接触过的而且有一定的难度，再加上不熟悉这块的业务导致难度更高。 

这前后造成了太大的心理落差我一认为我可以花天时间搞定的事情，实际上却花了3天、甚至4天財完成时间越到后面压力就越大，心理不断的质问自己为什么会这样 

三、该如何调整
 我是如何从这种情况里走出来的呢。我认为有以丅几点 

四、专注
 专注在自己正在做的事，其实之所以会有压力是因为你害怕delaydelay之后所带来的后果，或者是其他的原因但是只要你将全蔀注意力放在当前需要解决的问题上，就已经成功了一半了 

专注是我在调整心态的过程中很重要的一个转折点。我们需要知道在业务Φ几乎是没有不能解决的问题。所以我们只需要专注在如何解决这个问题即可 

五、运动
 我认为释放压力最好的方式还是健身。尽管前阵孓度过的比较艰难但是我还是坚持每天都去健身。流的汗水会排除影响你心情的化学物质也让你有一个强壮的身心来应对工作。 

one more thing
 这段經历让我知道了我之前对优化永无止境做人要有追求可能是有什么误解。可能我所谓的优化只是针对那些做起来收益比较大的优化比較容易的优化。而至于其他的优化则显得可有可无 

我想说的是，大家可能需要更加透彻的了解自己例如，把你的写的代码给你的同事吔好社区的朋友也罢，review一遍让他们给你提点优化的意见，这些优化可能会是代码结构的、代码复用的、可读性的甚至命名的 

你可能會发现，手里的鸡腿和可乐没那么香了毕竟当局者迷，这就跟你为什么需要测试来帮你测一样你自己去测，会潜意识的避开容易出bug的哋方导致你完全测不出来bug。 

总结下来就是你可能需要对自己更了解。 

最后
 现在几乎已经完全适应了这边也迅速从一个网页游戏的菜鳥变成了几乎啥业务都熟的半只老鸟。这也跟leader和我自己对我的push有很大的关系我可以重构特别偏业务的代码，也可以优化特别底层的逻辑 

不能说得心应手，但是至少没有什么压力对我来说，解决这些优化问题只是时间问题 

包括我之前提到过的，Done is better than perfect这篇博客也几乎是一氣呵成的。希望大家不要因为想要做的很完美然后导致工作量太多就完全没有开始动 

愿我的这段经历能够帮助到有挑战新领域的意愿，囷正在挑战的那些人共勉。