【游戏开发】配表在程序与策划的沟通中极为重要 V1.0

序

成为一名游戏程序有较长一段时间了，自认为还是有进步，虽然感觉太慢了点。一直想写一些东西，总拿不出东西来写。从这里开始吧。

在第一个失败项目中，策划会在出策划案之时或之后不久给出配表。

习惯了这种模式，在第二个项目中，策划不配表，甚至开始都不怎么管配表（测试测完后一段时间才检查配表），遇到了一些麻烦。

听说在游戏的开发中配表并非都是策划来配，也有程序配的没能再说什么。游戏开发的流程也确实是测试先验收、策划再验收。

但在此过程中，自己也一直在思考。但根据自己的理解，自认为配表在沟通中极为重要的内容，是功能模块实现前应该最先确定，最先验收的东西。

配表的重要作用

配表是游戏程序的组成部分，是策划控制游戏实际运行的重要工具。是连接策划和程序的桥梁。程序代码是否符合策划的需求，首先就体现在配表上。

程序所配表不能实现策划控制游戏运行的功能需求，那使用该配表的程序代码就一定不符合策划需求，程序和策划之间对功能需求的理解就一定有不一致，进一步沟通。

程序所配表配表能满足策划控制游戏运行的功能需求，但实践上不便于填表使用不方便，那使用该配表的程序代码也一定不符合策划需求。这在程序和策划间对功能需求的理解上或有或没有偏差，但一定需要进一步沟通，代码一定会改。

程序一定会第一时间看配表，从已经完成的配表中结合策划案可以更精确了解策划对游戏运行的实际需求。有配表的辅助，策划案的许多地方都不再需要写或讲解到那么清晰。

策划不知道怎么配表的地方，策划所配表让程序认为有问题的地方。要么策划案中必然不会清楚描述游戏该怎么运行，要么游戏运行的控制相对复杂，需要特别小心。这恰好就是程序需要特别关注，或许与策划理解有偏差的地方。

策划与程序间传达功能需求的三个层次工具

策划向程序传递功能需求，最明显的两个工具就是策划案和口头交流。

策划案适合表达框架性、基础性、概念性的东西。这些内容较为抽象不易用口头语言表达，较为基础可能需要经常查阅。

口头表达适合细节的，需要特别注意的关键点。这些或者内容用文本表达冗长、繁琐，或者需要双方相互交流，一开始无法明确要传递的内容重点。

要提高效率，在准确传达需求的前提下需要：（1）减少花在策划案上的时间。（2）减少口头交流的时间。这需要：提升工作能力，比如更快更好地写出策划案，更快更准地理解策划案的意思；更好的口头交流技巧； 提升了解，包括对对方本身及工作内容的了解、对共同事业的了解。这些都是职业素养相关的内容，需要长期积累、不断提升。

有没有一种工具能够直接提升沟通效率呢？我认为就是游戏配表。

游戏的各功能模块或多或少受配表驱动，其运行框架很多部分就体现在配表中，配表最终是要被程序代码读取的需要足够精确，包含有足够多的细节。

配表是游戏程序中最终一定要有东西，如果更早确定。那么部分的策划案内容就不要了，甚至本身就可以作为策划案的一部分；许多口头交流也避免了，因为配表中已提供最精确的信息。

把策划案和口头交流作为策划和程序交流功能需求的两个层次，策划案就是极佳的中间层次。虽然其形成需要一定的思考和交流，但这些代价无法避免。而如果作为一种交流工具来看，本身能够对交流起到极大的促进作用，减少花在策划案和口头交流的时间。

程序或策划负责配表的优点与缺点

策划最先、最准确知道游戏功能需求，配的表自然符合自己控制游戏运行及使用方便的两大需求。

策划配的表，可能不利于程序读取，甚至有些功能，有些策划不知道怎样配表来控制游戏。

程序配的表，一定能让程序代码读取以实现相应功能。

程序配表可能因为一开始对功能需求理解不清楚而无从下手、理解偏差而配错，还有可能不便于策划填表使用。

谁应该负责配表？

根据自己的经验和思考，自认为无论谁负责配表都可以，但策划和程序都应该参与，都应该才第一时间检查配表的合理性。可以按照以下步骤：

（1）策划在编写策划案时，应编写一定的基础表：可以是完整表（策划负责配表）；可以留下不会的给程序；可以把自认为程序能直接补全的部分给程序（程序负责配表）。这个基础表作为策划案的部分或补充。

（2) 程序在看过策划案，开过需求会后，在理解模块需求的第一时间把配表的剩余部分补全，把表中不便于代码处理的部分进行修改，有疑问无法补全的，或者自认为可能补错的地方标出。然后反馈给策划，并可以作为找策划口头沟通的工具。

（3）程序和在策划的进一步沟通中完成并确认配表。

这一过程起码要在测试开始测之前完成。当配表完成时最终完成时，结合之前的策划案，口头交流。大部分的游戏功能模块需求在程序和策划之间基本就比较一致了。