一、背景
半年前项目组决定开发一款游戏化的 app。但是组内还没有游戏开发人员。作为一个前端工程师,还算熟悉号称“镇后端”、“镇客户端”的 JavaScript。遂果断跳入游戏开发的坑中。这篇文章从比较 general 的方面对比了前端开发和游戏开发的一些区别,算是这段时间工作的一个总结,希望更多前端小伙伴们也可以尝试下游戏开发。
二、引擎选择
市面上存在的游戏引擎有很多,比如 Unity,Cocos2d-x,Egret 等。最终选择了 Cocos Creator,原因主要有几下几点:
本文以下部分提到的”游戏“均指 Cocos Creator 引擎,其他游戏引擎可能会有所不同。
三、游戏和前端开发的区别 1、共同点 2、不同点(技术方面)
资源(Asset)
游戏的代码仓库里资源占了很大一部分比例,这些资源的组织和使用方式跟前端还是差别很大的。
工程目录结构
游戏中一种比较常用的工程组织结构是按照资源的种类进行划分。比如/imgs,/audios。这种组织方式在比较小的项目中问题不大,但在大的项目中会有如下缺点:
assets
├── foundation
│ ├── common
│ ├── lib
│ ├── protos
│ └── utils
├── modules
│ ├── activity
│ └── roadmap
└── resources
├── activities
├── roadmap
├── sessions
└── start
组件设计
用惯了 React、Vue 之类的前端框架之后,组件就是一个输入数据、输出UI的模块,开发的过程中很少去操作 Component,component 的创建销毁几乎都由框架完成。开发者的工作重心更多的是如何将多个代表组件的元素(Element)拼接起来。他们之间通过 props 或者事件(Vue)来通信就好了。组件的开发和使用都是偏声明(函数)式的,更关注数据的流动。
而在游戏中的组件,只有在其他组件获取到了这个组件的引用并使用组件的方法使之完成某个任务才有意义,是偏面向对象的,更关注逻辑的依赖。
其次。前端框架的组件里需要关注UI的渲染,即输出的(虚拟)DOM结构。而游戏组件只专注逻辑,渲染则需要开发者手动在编辑器中创建节点,游戏引擎通过解析节点树及绑定在节点上的脚本组件来完成的。
举个
游戏脚本组件
class Prarent extends cc.Component {
son: Son = null
letSonRun () {
this.son.run()
}
}
class Son extends cc.Component {
label: cc.Label = null
run () {
this.label.string = 'Running'
}
stop () {
this.label.string = 'Stopped'
}
}
React 组件
class Parent extends React.Component {
letSonRun () {
this.setState({ isSonRun: true })
}
render () {
}
}
class Son extends React.Component {
render () {
return this.props.isRun ? Running : stopped
}
}
样式/适配
测试
前端的测试生态已经很完善了,从单元测试、集成测试、到 E2E 有一整套的工具可以拿来用,不同的框架也会有响应的测试工具包提升写测试用例的效率。但是游戏社区内几乎未找到现成的测试框架、工具。
基于游戏引擎跨平台的特性,我们正在试验一种测试方案:
Git & Code Review
周边工具
游戏的工具链比较长,尚未窥得全貌,这里只说几个平时用的比较多的吧。
3、不同点(非技术层面)
与设计师的合作
通常对于前端来说,设计师给出交互稿和视觉稿就可以动工了。但是对于游戏来说还远远不够。各种粒子特效、帧动画都需要设计师来做。好在游戏编辑器提供了一套对设计师友好的设计工具。设计师可以直接在编辑器中进行设计,设计输出可以推送到仓库中直接给开发使用,避免了开发从设计到开发的重复实现过程。
但是开发和设计师事先规定一套良好的设计规范仍然非常重要。
四、后记
经过将近半年的迭代,我们的项目已经走过了5个版本,迭代也日趋稳定(插播一条广告,各大应用市场搜索“少儿流利说”即可看到我们的产品)。这是一个 Team 团结合作的结果,在这里感谢所有为游戏项目贡献力量的开发小伙伴们:
暂无评论内容