在坛子里看到讨论,忍不住多说几句.这里整理下.
笔者项目和引擎都做过,经验大体相当.业余在做引擎.
1.引擎和逻辑该如何选择?
如果不写一点逻辑,直接就做引擎的工作,个人感觉不是特别好,除非是在工作前就有大量编码经验积累,有一定设计经验,也就是思路比较清晰的.
即便如此,个人还是觉得应该先接触下项目,多了解一般性的需求.
或者业余时间跟几个美术和策划组队,让他们来提需求.引擎的用户除了程序员以外,还有大量工具是面向美术和策划的,而且要有完整的data pipeline,同时又要足够灵活,能够支撑各种类型的游戏.如果这个做不好,技术再好也基本没戏了.
再或者自己做策划和美术,从策划和美术的角度来提出需求,注意换位思考,面向用户和需求.好的产品都是用户体验很优秀的,通过严格慎重的设计,把技术运用的恰到好处,而不仅仅是追求技术.
2.区别到底在哪儿?
根据个人目前的理解,从技术上讲,引擎同逻辑最大的区别就在于面向的用户不同.
- 引擎面向的用户是程序员,策划和美术. 游戏逻辑的用户是最终的玩家.正因为需求不同,导致设计方法也不一样.
- 引擎在技术上侧重抽象和设计,抽象的越好,代码复用率就越高,灵活性和适配性就越好.
- 优秀的逻辑其实也需要良好的设计, 但是相对来说更具化,一般不需要引擎那样非常强的抽象,而且hack和hardcode有时候更多点.因为逻辑处于开发的中后期枝叶节点,即便有很差的设计或很大的缺陷,产生的蝴蝶效应要比引擎小.
- 引擎的设计要非常非常小心,否则到了后期会有各种问题暴露出来,而这些问题有时候可能是不可调和的,就导致要么重构,要么拆东墙补西墙,要么用各种黑,挖下很多坑,坑到很多人.
3.写引擎需要注意的问题
- 耦合性.引擎在设计时,要注意模块间高聚低藕,接口正交分解.任何一块重构都不应该严重影响到其他模块.这样遇到问题时,最多会有几次局部重构,而不会全部推倒重来.
- 抽象.抓住问题的本质-究竟要做什么,需要什么.只有通过抽象的接口,才能维持一个庞大复杂的系统.同时,在开发过程中遇到一个问题时,不急于只解决眼前的一个问题,而是思考同类的,这一类的问题该如何解决.
- 扩展性和灵活性.因为各种游戏要基于引擎做二次开发,就少不了定制和修改,最理想的定制方式就是在不修改现有任何代码的情况下,通过引擎定义的接口进行扩展.
- 稳定性和可维护性.开发过程中,尽量做到:不修改现有的代码.修改现有的代码会导致其潜在的不稳定性.只添加新的代码,这样维护成本会大大降低.
- 工具.没有工具只有core runtime的引擎其实意义不大.要有完善的工具链和数据流.对于工具的设计,个人倾向于photoshop或者3dsmax的方式,基于插件的,高度可定制.一方面可以有效复用现有的编辑/处理机制和流程,另一方面,一个集成的环境更加方便使用.这样以来,除了引擎自己提供的内置工具集以外,基础编辑/处理框架就可以完全复用, 留给游戏项目的工作就是定制插件了.
举例
上面提到的几点设计问题,在日常生活和硬件设计中比比皆是.比如电源插座和插头的设计标准,就是一个低耦合的正交分解出的接口,它只关心供电,零火地,不关心连接的是什么电器.
一个经典的例子就是电脑主板:
- 耦合性: 主板间各个组件的通信,通过总线和桥,将各个部分耦合性降低.
- 抽象: 主板定义了内存插槽的接口标准,CPU针脚标准,PCI插槽等等标准.只要满足接口特性,不管什么牌子的组件都可以插上.比如只要满足PCI接口规范,不管是显卡还是声卡,都可以插上. 这就是一种接口的抽象, 只要定义了一组接口, 那么基础框架(主板)的灵活性和扩展性就大大提升.
- 稳定性和维护性: 想要修改和扩展特性, 只需要替换添加主板上的可插拔组件即可, 而不是通过修改主板来实现, 试想修改主板的维护成本有多大. 主板的升级相当于引擎(软件)的架构升级,这种情况并不是频繁发生的.
这也是软件和硬件等价性的一种体现. 当然上面这些问题在一般软件开发中也应当注意, 一个小型软件不注意可能问题不大, 而游戏引擎作为一个庞大复杂的综合体,是需要特别注意的.
个人在也业余学习编写引擎的时候,有时为了想出一个好的程序设计方式或者好的编辑操作方式会思考半天,一天甚至几天, 虽然时间有点长, 但是觉得还是值得的.经过思考会有很多收获, 一个人业余就是随便做做嘛, 进度不是问题, 主要是学习技术,经验积累, 顺便培养面向用户的思想, 还有就是学习设计方法和引擎架构, 软件工程这些真的很重要, 引擎这种大东西根基要打好, 否则后期吃力很难下手, 基本做死,有的时候真的是欲速则不达.