规范化与非规范化（ZT）
本帖最后由 呆呆星人 于 2011-4-15 22:43 编辑规范化与非规范化
哪些文档是有必要，或者必须规范化的，哪些文档是大家需要自定规则的呢？
这种规范，那位说了，应该统一 ,这是不可能的。
因为各公司各自有自己的管理方式，要想让大家都必须和你一样，那是不可能，也没有意义的。所以今天我们要说的，就是如何制定自己所在公司的规范。
PS：本着大家是主策划，或者项目负责而给大家说这个，如果立志于做执行策划的朋友，可以不用往下看了。
“文档编写标准化”
这个在软件业都是非常重要的。在游戏开发中，更是非常之重要。
它对应在游戏软件开发过程中，每一个环节，所谓工欲成其事，必先利其器，就是这个道理。
在游戏开发公司中，首先是项目内部的服务器目录组建 。
这个大家看到了，这种规范化，包括每个目录中也许会有说明。这是为了大家都能方便的工作，而决定采用的最合理的方式。不是我说给大家看的，是最合理的，但做为项目主要负责人员，要不断的摸索最好，最方便的工作方式，这才是王道，这个规范就是这个目的。
这个目录架构，通常我到一家公司，第一件事，就是把这个做好。良好的工作模式，决定工作效率。
而大家即使一开始不在重职，也要勤于努力就提高工作效率方面的事
PS：这就是我去一家公司，从来不会等人安排我工作，常能做很多建设性的工作，而轻易得到领导的信任 一般我首先下手的就是工作方式：）
另外在文档名上，也颇多讲究，从两个方面走，一个是文档命名，二是游戏资源命名。
1、文档命名，为了大家使用方便，而且还需要有同步性，尽可能使用不易名的文档，同时在文档每更新后，要做注释 。
这个与程序部门的／／注释差不多，在各文档中，都有的。这个是为了所有同部门人员可以非常清楚的每个文档的具体情况。
2、另外要说的是游戏资料命名，大前天已经告诉大家了，这个通常是设计与程序两个部分的负责一起完成这个的。在这里，大家会问，游戏资源什么样比较合理？
大家也许打开过，日本光荣游戏公司的游戏的安装后的目录过，也打开魔兽游戏安装后的目录过。会发现，日式游戏资源的命名，一般都是：
T0001.??
T0002.??
T0003.??
T0004.??
T0005.??
T0006.??
而美式游戏的资源命名，往往是：
oldman.??
oldman2.??
women.??
women2.??
women3.??
这两种方式其实各有千秋，视公司内部情况而定。
第一种，文件排序方便，但需要对照说明书（表），才清楚，什么是什么。
第二种，一目了然，但排序不便，且英文或是拼音不好的同事，就不好搞了。大部分国内公司都是采用第一种，但在资源分类上的略有不同。
如道具：
id
Item1_01_001
Item1_01_002
Item1_01_003
Item1_01_004
Item1_01_005
Item1_01_006
NPC：
NPC001 - NPC甲
NPC002 - NPC乙
NPC003 - NPC丙
NPC004 - NPC丁
NPC005 - NPC戊
以道具为例，01可能是武器，02可能是防具，03可能是消耗品，……
问：国内用第一种做什么的序？
答：第一种是
NPC1001
NPC1002
NPC1003……
如果是其它NPC类型就
NPC2001
NPC2002
……
问：是不是为了以后做数据库方便调用才这么设定的呢？
答：不全是，由于欧美游戏公司用这种命名是因为那是其母语，而国内都用拼音非常不正规，是故大多订一个资源命名规则，这样做也是为了，从命题就可以看出其类型，在数据调用时，比较方便，而不用建太多目录放这些资源
“可行性分析报告”
这个作用上节课告诉大家了，这个不需要非常规范的模式的 。
但，有几个重要一定要把握 ！
重点 ：为什么要做你的东西，这样做有什么好处，什么缺点，打算怎么解决（这个非常重要），对应市场有什么不合理的地方打算怎么搞，有什么竞争对手。
这个往往是老板与市场分析人员最关心的，而往往是大家最不去想的。
另外，我拍着胸脯告诉老板或是市场人员，我做这个游戏会好，为什么？要分析归纳出理由，充足的理由。这个不需要明白的规范，视游戏具体内容而定 ，但这种文档，要做的漂亮：） 。流程图，表，之类的东西，说的越清楚，画的越正规越好。
“项目开发计划”
他的用户是团队内部与老板。
对团队内部人员来说，应该标准化的内容，一般用Excel或是project。
而给投资人的那个计划，就有多种选择了 ，如果你的投资人是内行，就上述方法足矣； 但如果是外行，他们不一定可以看懂你的表可是时间安排，对他们来说，你写的那可以完成XX系统，对他们完全没有概念，这怎么办呢？
这时，需要一种，称之为感观描述的方式，和完成百分度的方式，来交给他们
举个例子：
标题：对于“玩家上手性”的完成度
内容：
1、我们会在X年X月X日版本，做完新手帮助，玩家上手度+20%
2、我们会在上版本，做完F1新手指导，玩家上手+10%
3、我们会在上版本，做完玩家新手辅导员系统，玩家上手度+12%
与总终版比较，此版本，我们已经完成此主题的62%
对于主题亮点“国战”的完成度
对于美术直接感觉的完成度
对于……
……
这是完成百分度。
如果你的上司，对游戏开发一点都不懂，恭喜你，可以用更有趣的写法告诉他，一个版本是什么样子的。
如：现在我要安装这个游戏了，打开XXX文件夹，点击XXX.exe后，我开始安装
打开登录时，我有？个角色可以选择。（选A我可以进到B点，选C我可以进到D点）
进入游戏后，我可以拜，EFG几个NPC为师……我还可以做这个，那个？
这个的目的，是为了让你的读者更明白你的开发计划，就是某版本的状态。
“软件需求说明书”
这个其实在游戏立项和可行性分析时，就要做这个。
玩家有什么属性？NPC有什么属性？物品有什么属性？场景有什么属性，这些属性分别是性质？——“全整数？字符串？”
这些属性的采用什么多少进制？上限是多少？这些一定要优先确定的 。
比如：玩家呢称，字符串，上限16字节（八个字）
所有游戏中涉及的元素，全部要这样数字化，这个需要大家对数据库有一定的概念。
这个，大家不明白的地方，下去自己学一下，其它有什么问题吗？
要求对一款游戏每个值，都有这样的数据库分析能力，不过份吧？
这个虽然很少公司游戏设计部达到这个种需求分析能力，但这样的要求大家，我希望大家可以达到
问：场景的属性怎么用数字？
答：场景ID：自动排序，不可重复，如可生成场景，给出场景生成自命名规则
场景名：字符串，上限16字节
场景天气属性：可变10种，上限16种
场景当前天气，1种，默认
场景类型：8种，上限16种
不过，大概可以这样说的，也就是你的游戏设计需要什么样的架构，什么样的数据结构，在这里要描述清楚，不需要规范，前提是与你合作的部门可以看懂。
几种计算机数据方式，要搞明白，为什么一般游戏中，常用255这个数字，一定要搞清楚。数据结构，优先了解，大家都是这样的。
“概要设计说明”
这个，就是我们设计要写的总案，是给内部大家做路灯的东西。不用公式，但要非常清楚的每个功能的实现状态，如何制作的具体方式。
这个由主设计师来写。
做为游戏的主设计师，在任何时候必须非常清楚的可以告诉大家，每个细节 ，这个细节又必须与游戏主玩点不相违。
这个不是象大家曾抱着自己的案子，在没有程序支持情况下的现讲现解释。
这个方案，就是公司暨定的，与立项报告相符的，每一个细节，大家都必须清楚的知道。
例如：当有人问你，大佬，我们的结婚系统，在结婚时，可不可以先PK一下再结？这时，你就要告诉问你这个问题的策划，结果是为了男女玩家之间的幸福，而PK与之相违，是不好的。
不用规范，但要大家都明白，而且开发人员内部都认可的明白。
问：就是说对于整个系统整体要把握是吗？但是如果在开发中想要加入新的因素呢？
答：可以的，但你至少应该自己可以判断，哪些可以加，哪些不能加，为什么？
当你的游戏定位在休闲时，有人提出，我们可以随便PK，而且损失特别的重时，这时，大家应该可以判断，这个定位是相违的，这样的PK系统，大家人人都紧张，还休闲个P啊！
PS： 在对项目伙伴及同事说话时，一定要注意语气，不能象我刚才那样“这样的PK系统，大家人人都紧张，还休闲个P啊”这个P，就坏了大事了
“详细设计说明书”
这个，大家做为游戏设计部负责人，要天天看的东西，大家刚去一家公司做不到负责人，要天天写的东西。
一般情况，各公司是有规范的 ，但也没有没有的。
我一般是比较注重这个的，这个道理是这样的，你的用户是程序部门，他们就是看你这个的，一次不明白，会来问你，你习惯性清晰的多次这样写，他们就成为习惯；如果你是负责人，要制定这个规落。
就象我制定，大家交作业给我是一样的，天天都收到不一样的文件格式，有的模式我根本不知道用什么打开，然后为了看大家的作业我要以大家的习惯不停的装软件，大家说我会不会很郁闷呢？
这个规则是一样的，给程序部门，先是让他们熟悉，知道这样的好处，慢慢磨合：）这样，以后在工作交流中，就省去很多解释的事情。
这个是要有规范的，但要自己多摸索，我会提供一些模本，但主要靠自己摸索的。
“用户操作手册”
对内的，是规范吗？答案是本公司的员工，是要规范的，这个工作是各项目负责人要做的。
如目录下文档说明，导读。
这个不用详说，大家都应该知道了，原因在上节课也告诉大家了。
对外，不说也罢，让玩家在浏览主页时，要知道你的游戏怎么玩，这个的重要性不言则喻。
“测试计划”
在游戏开发过程中，每个测试都应该是有目的性的。
每次测试，都应该明确是为了什么。
这个计划，应该标明，测试人数，测试目的，测试方法，测试结果评估，修改办法等等。
比如说，这次的测试，我们的计划要200人，目的是测试等级之间差与国战的效果，测试方式是时间一到大家到国战场景开打（一次，不可再入），测试结果评估是国战持续时间可能会于3分钟~7分钟（时间太少，不符要求）；修改办法：……略。
这样的计划，不是漫无目的测试，而是针对每个玩点有主题的组织大家测试。
“测试分析报告”
这个有必要有规范。
在测试后，哪些问题是属于哪个部门，由谁来负责，提出者是谁，时间，这个BUG的优级是多少，已经过了多少天没有解决了？
这个用处就是使当解决的部门去完成这些东西，不用按统一规范去做，但不论是Excel还是内部的局域网CGI或是ASP工具，都应该提供这方面的功能。
主要是针对测试者的提交，回应的向映，反馈结果，结果时间等等。
带可以加上再犯的机率，同一个问题多次提出，这个肯定是有问题的。
“项目开发总结报告”
这个如果有公司安排这个，按自己习惯的方案方式，去写吧，或者按公司的要求一样的，说清事情，是应用文的王道。
“软件维护手册 ”
强调一下的是： GM管理工具，玩家BUG提交工具，玩家外挂举报工具等等，如果需要都应该搞好。 另外GM在游戏中应该的命令，GM权限设定，都是游戏设计部门应该做的。
“软件问题报告”
这个其它的网络游戏公司做的并不好 ，网易值得学习。
就是用户最直接的反馈，而开发团队的回应情况。
这个不用说的了，参考大话项目做的一些活动，自己理解。
“软件修改报告”
这个不用规范，有一些朋友对这个不清楚是干什么的。
上一个是报告，这个是解决办法，是相辅相乘的。
举个例子，当我们设计了一个系统，玩家可以在四小时之内，等级达到了50级，很可怕吧 ？这时，GM就要向游戏设计部门，递交软件问题报告，要详细说明情况
这时，游戏设计部门负责，在准备好被老板罚钱的心理状态下，开始修改策划案，再提交程序部门。（这个过程是属于前面我说过的"详细设计说明书" 的修正），但这时候，当老板要你说明这个事是怎么回事时，你要给老板的就是这个报告，同时有承担的觉悟 。如果在运营后，发生设计上非常重大的失误，会有一些主设计师应该承担的责任的。
问：如果是程序没写对 那应该是由程序部门来写吧？
答：程序部门没有写对，你应该可以测试出来问题的，测试后还认为没有问题，就推向用户，责任在你。
问：要是出先外挂什么的~也是我的问题？
答：那个不算，但在报告中，要述清原因，说明如何解决。
如果出现了问题，最关键的就是如何去解决问题了，主设计师重要的能力就是，应该知道该怎么去解决，遇到任何事情，都能冷静判断后，得出结果。
需要大家具有这样的能力。
有错要分析错在哪，有BUG，要分析BUG根本在什么地方，并做相应的弥补。 愿风指引你的道路 愿阳光照耀着你
楼主辛苦了 分享是快乐的
页:
[1]