关于网络游戏流水线与半自动化开发的构想（二）

sea_bug

本文采用 BY-NC-SA 协议进行授权，文章来自 愤怒的面馆 ，点击查看 原文，转载时请保留此信息！


　　上一章着重说了大体上的构思，可能大家都把“流水线”这个概念给神化了，我觉得不应该把“流水线”放在标题上，误导了很多人。因此，现在我把题目改为了“ 关于网络游戏流水线与半自动化开发的构想 ”，多增加了一个概念。
　
　　众所周知游戏有不同种类，不同的游戏不可能去沿袭一个固定的开发流程，这样在一定程度上影响了其灵活性。我所提出的“流水线”并非强制性去沿着某个流程走，而是把作业点“流程化”，这是完全不同的两个概念。前者是概念把框架定死，然后用户使用；而后者却是由用户来定制流程，再按照流程去完成不同的任务，相当于一个半自动的PM。
　
　　在这里我要解释一下“引擎”和“工具”的概念。引擎相当于一个发动机，它只会给你提供最原始的动力但它不会帮你具体化去做某事。因此，这个发动机可以有很多用途，你可以用来做小汽车的发动机，略作改装之后也可以用来做卡车的发动机。因此，在做拥有同种特征的工作，只需要对引擎进行局部的改装就可以完成很多事。但引擎有一个弊端，就是它必须要经过一个“改装”的流程，在一定程度上会在“改装”这个流程花掉不少时间。而所谓的工具，却是已经具体化到了某个点上，用户只需要沿袭一套固定模式的框架去更改一些自己关心的数据，即可通过机器自动生成或者引导出一个新的解决方案。
　
　　我希望通过提炼某些最常用的功能的一些共同特征，通过可视化界面去生成配置文件或者脚本。然后在这个基础上提供数种方案让用户可以更加灵活地定制生成模板和规则。相信写程序的人都有这么一个怪癖，自己在实现某个功能的时候，如果需要一款小工具，它可以帮助自己去自动做好某件事，那你很有可能会丢下当前的项目，去把这款小工具给做出来，再继续手头上的项目。产生这样的想法和行动原因就是因为在平时的项目中可能会遇到很多繁琐，相同的小工作，如果在今后实现相同功能的情况下都做一次，那太不低碳了。
　
　　实际上这段时间我一直在考虑这个工具集实现去可行性，不得不说，要提炼出一套通用的方案还是有一定难度的。但这样的难度并不代表不能实现，目前计划中 大致 有以下有几个大类：

一、游戏模板信息编辑（生成）
二、固定格式代码生成
三、团队协作（项目管理）
四、资源管理
五、 游戏数据统计、分析、汇总报告

　　目前所考虑到的弊端和实现难点，以及可行性方面都存在着非常多的问题，至今为止我也尚未整理出一个清晰的脉络去把这些功能都搬到程序里面去，而这样做是否真的会提高工作效率，或者说如果用了这样的方式去开发游戏，是不是就会限制了每一个游戏都会是同一种模式？这些问题希望大家给一些中肯的建议。拜谢。

gantleman

脱离实际谈这些都是没有意义的，
流程就是规划和约束，规划很容易，
但能否约束需要大量的实验和经验。
文章所说的流水线，如果策划提出一个程序不能完成
或者不容易完成的任务，这个流水线就要停下来，
等待策划和程序交流协商，这就是没有约束的规划。
如果是程序提供一整套的开发工具，策划中开发工具基础上构思游戏。
那么开发工具就是策划的约束，策划不能跳过约束去倒逼开发规划。
整个流程就顺了，所以关键不是怎么去规划，
而是有一整套的完善可行的约束可供使用。

zhangning111

很高深，看不懂