游戏开发的过程中,有各个不同岗位角色,常见的包括程序、策划、美术、运营。每个角色对产品的思考角度都是不同的。

而程序作为一款软件产品的基础设计起到至关重要的作用,开发的各个环节都应该尽可能的考虑到其它角色的工作便利性。

KSFramework适合中大型团队、多角色共同协作。对于小型团队,KSFramework中很多功能设计可能十分多余。因此,了解KSFramework设计过程中的假定角色需求,才能更好的理解框架部分功能设计的初衷。

假定角色需求

策划

策划人员在游戏开发中最多的事务操作,是操纵Excel表。他们希望游戏配置表是可注释、可理解的、甚至可视化,而不是让人看上去布满看不懂的英文和数字。同时,Excel表格是二进制格式的,不方便进行版本差异比较,他们希望可以使用版本管理管理自己的工作。

在KSFramework中,使用Excel表格编译成TSV(Tab Sperated Values,类似CSV),在Excel表中,可以加入注释列、注释行、图表、多个工作表、条件式编译,基于这些,可以把文档和游戏具体配置表整合在一起。

在编译成TSV格式后,纯文本格式,上传SVN或Git版本管理,可以方便的进行差异化比较。

美术

美术人员的工作最好与程序人员的工作脱离关系。在美术设计的过程中,他们喜欢用自己习惯的方式舒服的创作,譬如就算它们使用Unity进行特效、UI的编辑,都会自己另外开辟一个个人目录来做。

在KSFramework中,推荐美术Unity工程和代码Unity工程分离。在美术Unity工程中,美术人员按照自己喜欢的思路,摆放自己的美术资源。唯一的一点要求就是:制作完成后的最终产出,放到要求的目录。

运营

运营的过程中,节奏是很快的,运营人员总是希望软件产品能针对运营行为迅速的作出的反应。软件产品的静默更新,是运营人员最想看到的——用户无知觉地使用到最新的产品。其中,代码方面的热重载是程序设计方面的重点,并且尽可能多的功能控制,交给外部如http服务器处理。

程序

做程序的最怕就是出BUG。为什么?因为要改。改吧,改起来麻烦。改完了,还要来回地测。热重载可以尽可能的缩短改-测得这个过程。

当然,更稳健的解决方案是单元测试。因此在KSFramework中,SLua是可以编辑器模式运行的,方便做Lua方面的单元测试。


KSFramework的假定的角色需求,并非普遍的需求。如果您认为有不对或需要补充的,欢迎提出,虚心求教。