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

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

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的假定的角色需求，并非普遍的需求。如果您认为有不对或需要补充的，欢迎提出，虚心求教。