(window.slotbydup=window.slotbydup || []).push({
id: '2014386',
container: s,
size: '234,60',
display: 'inlay-fix'
&&|&&0次下载&&|&&总4页&&|
您的计算机尚未安装Flash，点击安装&
阅读已结束，如需下载到电脑，请使用积分（）
下载：2积分
相关分类推荐
0人评价2页
0人评价18页
0人评价4页
0人评价6页
0人评价5页
所需积分：（友情提示：大部分文档均可免费预览！下载之前请务必先预览阅读，以免误下载造成积分浪费！）
（多个标签用逗号分隔）
文不对题，内容与标题介绍不符
广告内容或内容过于简单
文档乱码或无法正常显示
文档内容侵权
已存在相同文档
不属于经济管理类文档
源文档损坏或加密
若此文档涉嫌侵害了您的权利，请参照说明。
我要评价：
下载：2积分网吧自动更新游戏系统如何更好的设计
热门关键字：
网吧自动更新游戏系统如何更好的设计
点击: 869次
　　网吧游戏自动更新是现在的热点，对于网吧管理员来说，网吧游戏能够达到自动更新减少了网吧很多的繁重工作，网吧自动更新游戏系统还是比较多的，但是具体的操作，有些网吧管理员的做法却不一样，我们来看下一个更好的操作设计。
　　网吧自动更新游戏系统如何更好的设计，以下是详细的步骤：
　　首先在E盘做了个批处理update.bat更新程序，批处理的内容如下：
　　@echooff
　　call\\share\server\\gengxin.bat//*用这条命令来调用服务器上的更新文件
　　测试过后将update.bat复制一份到\share\server\下
　　由于E盘是不受保护的，所以在C盘的根目录下建个批处理文件up.bat，并将其加入启动项中，用来检测E盘的update.bat是否存在。
　　@echooff
　　ifexiste:\update.batgotoend
　　xcopy\\share\server\update.bate:\//*如果E盘的update.bat文件被删,用这条命令将share\server\update.bat复制过来
　　e:\update.bat//*调用E盘的update.bat文件
　　如果你想要提高执行速度,可以用bat2com将上面两个bat文件转成com文件.
　　应用实例:
　　1、更新采用自解压文件的方式；
　　2、在share机器上开个共享server，用来存放更新文件；
　　3、在server共享目录下按照日期建立更新目录；
　　比如，我在日做好了这两个批处理，在server目录下就建个目录，如果在9月24日有更新了，我就将更新文件放到这个目录中，我可以在最后一个更新包里放一个update.bat文件，这个文件同上面的update.bat内容相近，只是把目录改成，然后在server目录下新建一个的目录，里面放一个gengxin.bat就行了。
　　在我开机后或重启后，系统就会自动运行c:\up.bat，然后调用e:\update.bat，update.bat又会调用 share\server\\gengxin.bat，这个gengxin.bat文件中调用share\server\目录中的压缩包，等所有压缩包都解完后，在E的update.bat就被替换成新的文件，里面调用的就不再是//share\server\\gengxin.bat，而是share\server\\gengxin.bat，以后的更新文件就放到目录下，以此类推。
　　如果e:\update.bat文件被删了，系统会自动将share\server\update.bat文件恢复过来，然后再执行该文件。
　　share\server\update.bat文件可以过一段时间后更换成一个比较新的版本，这样就不用担心万一被删又要从最初开始更新了。
　　以上的网吧自动更新游戏系统设计，是一个比较好的创新，如果其他的网吧管理员也想实现这样的游戏更新，就按照以上的步骤来做，一定会帮你们减少很多工作量的，仅供参考啊。
以上内容整理自互联网，如有侵权，请立即与小编联系，小编将及时处理。转载或引用本网版权所有之内容请注明来源，感谢您对本站的支持！
联系QQ： 欢迎加入网吧业主 交流群：（已满）(可加)
点击排行榜
时间：08-25仅限参考，如何有效编写一份游戏设计文件 - GameRes游资网 - 微信公众号文章
&仅限参考，如何有效编写一份游戏设计文件
仅限参考，如何有效编写一份游戏设计文件
日11时03分来源：
当我们几个月前在Reddit上分享这篇文章时我们看到了一些具有有建设性且充满激情的讨论（我们也因为这些讨论而变成了更出色的游戏设计师）。
我们发现其中有些反复出现的要点，所以在你们继续阅读本文前我想先声明以下内容是错误的：
1、使用游戏设计文件（GDD）过时了。
2、当你在编写GDD时你需要直接去描述游戏机制。
之后我可能会写篇文章去讨论每个主题，不过现在我打算先讨论以下内容：
1、与其它产业一样，游戏产业也不断发展着，或许昨天还很好用的技术在今天看来就过时了。特别是在年轻的产业中，即仍在发展着过程，参数等等的产业中。这时候最重要的便是在真正投入生产前你需要使用GDD（或者Wiki，黑板等方式）等方式去描述你的游戏项目（或任何其它项目）。
以下便是我们所谓的GDD的一些使用技巧，我们同样也会使用黑板去管理任务，并尝试着将我们的项目分成两周。
我们并未使用在开发过程中不断发展的完整GDD，相反地我们使用的是能够让团队了解项目全新情况的文件。然后我们会做出一些调整去适应游戏设计阶段我们所收到的反馈内容或者团队的新想法等。
一旦开始投入生产，我们便不会再更新GDD，反而我们会将所有新理念记录在黑板上，有些理念会被优先挑选出来（即会出现优先次序1至3的内容，也就是必须做的事1，将要做的事2，以及做了也不错的事3），并将其中一些理念归到“理念”栏中留到之后再进行评估。
总之不管你使用的是GDD还是其它方式，我们都会建议游戏设计师开始考虑将自己的理念记录在某种类型的文件中让其他人能够阅读并理解这些内容。
2、如果你的游戏是像《俄罗斯方块》或《太空入侵者》或《Asteroids》那样，也就是游戏故事是科幻的并且对游戏机制不会产生任何影响，那么我便会建议你直接进入第四章节的模板中。
对于我们在这个例子中所使用的游戏，它将能够基于特定背景自然地描述角色，他们可能做的事以及这么做的原因。
不过最终这都是取决于你的游戏和游戏设计类型。你可以考虑添加一个介绍部分并在这里简短描述整体机制，而添加这部分内容的目的便是让阅读该文件的人能够马上了解你的游戏类型和游戏机制。
所以我该如何使用文件去记录我想在游戏中执行的内容？
这便是当我拥有一个能够帮我致富的优秀理念时第一个涌现出来的问题。那时候我还不知道自己想要进行游戏设计，所以我需要先创造一份游戏设计文件（简短的GDD）。
在进行一些研究后我认识了GDD，但是我却找不到其它产业标准或模板去帮助我开始执行这一过程。
在阅读了一些游戏设计书籍并浏览了网上一些相关内容后，我便开始创造自己的第一份GDD。而经过几年的迭代后它最终变成了下面的模板，这也是我们每次开始创造新游戏时所使用的模板。
以下便是关于GDD中每个部分的描述。
总结游戏是关于什么，不要讨论过多有关游戏机制之类的内容的细节。你必须让人们在阅读了项目描述后清楚你尝试着去创造的游戏风格（游戏邦注：是社交的，休闲的，还是硬核的）和类型（是益智游戏，RPG还是FPS）。当然了你也可以添加更多与游戏相关的信息。
你最好确保这一部分只有1或2段内容。千万不要超过1页。
这一游戏设计文件描述了一款带有创新游戏机制，故事和角色的多平台触屏2D益智游戏的相关细节。
游戏玩起来像三消游戏，但同时也包含了一些创造性内容
游戏名字待定，但已经有些候选名字了。
我们先从角色开始是因为你需要在故事前先介绍他们。如果你的游戏没有角色或故事，你便可以直接跳到游戏玩法那部分，即舍弃第1至第3部分。
角色描述例子：
Gnumies是这款游戏的主角。这些生物都很活泼且很富有，但却并不贪婪。他们之所以富有是因为他们的祖先与金钱有关，所以他们的名字才叫Gnumies。他们毛很多且具有各种颜色。
红色Gnumies充满热情且喜欢打碎各种东西。黄色Gnumies喜欢跳上跳下。绿色Gnumies很安静，毫不拘谨且很好相处。蓝色Gnumies有点阴郁且脾气较差。
Gnumies同时也拥有许多手臂，即在1至4之间，他们手臂都带有手。他们会在握手的时候结合在一起。Gnumies喜欢粗野的游戏方式，所以可能导致所有的一切变得很混乱。
你也可以在这里添加一些角色图像。
“故事叙述的一个重要部分便是创造能够轻松将观众带入其中的角色，如果越多观众能够与角色形成共鸣，那么这些角色所参与的事件便会变得更有趣。”—-Jesse Schell
在介绍了角色后，你便可以开始阐述发生于游戏中的故事了。
Gnumies愉快地在城堡中游戏并搞了恶作剧。Butler发疯了，但所有人还是照常游玩着。
小丑在开玩笑。
德国人待在家中看电视而他的母亲不断烦他。所以他便出门去侦察Gnumies。外面在下雨而德国人羡慕地看着窗内，他已经被淋湿了。
一个奇怪的人给了他一把钥匙，他可以使用钥匙进入后门。他带着自己的军队进入了后门，绑架并监禁了女性Gnumies和小孩Gnumies，并将所有人赶出了这座岛屿。
“具有能够形成共鸣的主题可以将你的作品从工艺变成艺术。美术师可以将你带到你之前从未到过的地方，而主题便是他所借助的交通工具。”—-Jesse Schell
当别人在阅读你的设计时，这部分非常重要。总之主题必须能够表达出你想要讲述的故事类型：它是喜剧，还是反应真实生活的，亦或者是科幻的？
这款游戏的基调是悲伤的。这里会有动作场面和愉快的时刻，但在每个章节间故事将阐述Gnumies的悲伤，因为他们丢了钱。而这同样也带有一些幽默感。
如果你认为这与你的游戏无关便可以选择略过这一步。
3、故事进程
所以你拥有一个故事了，但游戏该如何将玩家带进故事中呢。
“你的游戏世界是一个拥有不同组成部分的内容。你的游戏是将人们带往只存在于玩家想象中的奇幻世界的大门。”—-Jesse Schell
游戏将从一个简短的介绍场景开始，在这里Gnumies将被踢出自己的家园。然后他们将来到一座岛屿，第一章节便从此拉开了序幕。
第一章节是引言。这是可以略过的内容。Butler将在这里向用户介绍游戏机制。
一旦玩家完成了教程他便可以进入第一个世界（森林世界）。
当玩家完成在森林世界的任务后他便能够获得第一把钥匙并选择去开启火山世界或冰山世界。一旦他们完成了这些世界中的任务……
创造一个能够同时出现在多个故事中的世界非常重要。这能为之后的续集和商品开发做铺垫。
4、游戏玩法
“游戏是从一个理念开始的。”—-Jesse Schell
这是GDD中最重要的部分（在99%的游戏中）。在这里你可以描述你的游戏玩法会是怎样的。
因为这部分会变得较大，所以我们将其分解成一些小节内容。当然了这也是一个非常主观的观点，即适合我们的东西不一定适合你。
简而言之，为什么玩家要玩你的游戏呢？你可以添加这一信息到一个独立的部分中如此你便不需要在浏览整个GDD的时候进行猜测。
从整体来看（长期）：帮助Gnumies回家
游戏玩法（短期）：打败敌人，前进到下一个关卡等等
4.2、用户技能
这并非最直观的部分，但当你在考虑玩家需要精通怎样的技能才能玩游戏的时候这部分能够帮助你缩小范围。相信我们，编写这列内容能够帮助你找出游戏设计中的问题所在。例如你可能尝试着为孩子们创造一款游戏，而你可能会意识到你要求他们做的事太超前不符合他们的年纪，或者某些输入内容适合手机而不适合拥有操纵杆的主机。同样地，如果你的游戏将带有Custom HW，那么这列内容将帮你明确你需要执行的组件。
重新安排组件
4.3、游戏机制
在这里你将描述你的游戏机制。当你在向团队成员传阅GDD时，你必须尽可能避免他们对于游戏玩法的疑虑。在这部分中你可以添加一些有关游戏原型的图像或截图（我们会事先创造机制原型并在投入资源于游戏中前测试它们是否有趣）。
你可以找到许多有关如何描述游戏机制的书籍和网站，所以我们便不在这里进行详细说明了。
4.4、道具和升级道具
我们使用这一部分详细介绍了游戏机制。为了避免将所有内容集中在同一部分，我们在上部分中描述了核心机制并在这部分中讨论了为提高游戏乐趣而添加的一些内容。
如果你的游戏是一款三消游戏，那么在之前的部分中你便需要描述一款三消游戏是如何运行的。
在这部分中你则需要添加玩家可以使用/购买的每一个升级道具和道具以及它们将如何影响核心游戏玩法。
当闯完一个世界时，你可以获得与这个世界相关的升级道具。例如你战胜了火山世界，你便能够获得一个可以让红色Gnumies变得更加强大的道具。可能是一条围巾或其它他们可以穿在身上的东西，而你将在之后的游戏中看到这些道具。你可以使用游戏内部的货币去升级道具，或使用真钱去获取游戏内部的货币包。
4.5、进程和挑战
这也是一个很主观的部分，可能适合你的设计也有可能不适合。关于这一部分我们的理念是精确描述难度在游戏中是如何提升的并确保提供给玩家能够追赶难度的工具。
难度将让敌人变得更加难对付。为了应对不断提升的难度，玩家需要变得更擅长游戏，升级Gnumies并使用道具（同时也要升级道具）。
同样地我们也可以在这里谈论玩家开启全新关卡和任务的方法。
每个boss会丢下一个衔有代表所处世界颜色的宝石。玩家可以基于不同顺序去处理不同世界。当玩家战胜每个世界并获得所有钥匙后，他便可以按照自己的方式前往最后的世界。玩家可以基于不同顺序进入不同世界。最终世界的boss将丢下一把能够让玩家开启不同世界的钥匙。一旦玩家使用了某种道具，它便会永远消失。如此玩家必须在开启下一个世界前先战胜他所选择的世界。在这里世界的难度是设定好的。
失败的条件是什么呢？时间，生命值，还是所有的这一切？在这部分中你可以描述玩家是因为什么才到达“游戏结束”页面。
这些都是失败的条件：耗尽了时间，耗尽了生命值，不存在可行的结合。
当玩家失败时，必须出现一个显示Gnumies受伤的图像。也许他们会掉了毛发，而你将能看到他们的皮肤。
5、美术风格
这部分是不言而喻的：在这里你可以描述游戏外观的相关想法。因为一张图可以等同于数千个单词，所以这便是你添加概念图像的地方。
这是一款2D等距游戏，具有高质量的2D精灵。角色设计就跟吉卜力工作室所设计的一样。
所有的一切都必须具有鲜艳的色彩且足够生动，并带有动画场景和分层的背景。
6、音乐和声音
“音乐是灵魂的语言，正因为如此它将从更深层面向玩家传递某种内容。”—-Jesse Schell
在这里你能够描述你的音乐和声音。基于音乐与声音对于你的游戏的重要性，你可以将其分解成一些较小的内容。
音乐应该是复古风格，能够让人回想起8位体的游戏时代，但同时也必须具有较高音质。
你必须在玩家做得不错的时候呈现出赞扬的声音。这必须是直接且正面的反馈。
当时间不够时，你可以添加一些让玩家紧张起来的声音。
悲伤的场景可以伴随着手风琴/小提琴演奏的音乐，就像悲伤的探戈那样。
对于游戏中的音乐，你也可以使用一些欢快的曲调并随着关卡的前进而加快速度。而当玩家进入山洞时声音最好显得模糊些。
7、技术说明
在这里你可以描述你将面向哪个平台发行游戏以及你将使用怎样的工具。这并不是有关技术细节的描述，毕竟那是属于技术设计文件（TDD）的范畴。在这里我们将只是传达一些表面上的内容。
最初游戏将是跨平台手机游戏，即面向以下平台发行：
Windows Phone
紧跟着将发行PC单机版和Facebook版本。
在未来也有可能添加Mac或主机支持。
我们所考虑的引擎包括：Marmalade，Unity 3D，Unreal Engine 4、
对于项目管理我们会使用JIRA。并使用Perforce去储存代码和资产。
TBD非常适合技术设计文件。
8、市场营销和融资
这是一个可选择的部分，但你最好在当下记下自己的想法以防之后忘记。你必须考虑如何去营销自己的游戏—-甚至是在投入开发之前。你必须清楚该从哪里筹集制作游戏的经费。
“计划是货真价实的。”—-Jesse Schell
创建第一个关卡的原型，然后进行Kickstarter活动去呈现该原型
尝试着达成一个发行协议。
寻找是否存在可申请的政府资助。
创造一份新闻稿并将其发送到游戏新闻网站。
创建YouTube Channel并在上面发布开发日记视频。
8.1、目标用户群体
你必须清楚你将面向哪些用户群体，这将被融入到游戏设计中。如果你瞄准的是15至25岁的男性，你的主角就不应该是一只粉色小马。
年龄：12至50岁
性别：所有人
主要是休闲玩家
8.2、平台和盈利
你可以添加更多有关如何面向不同平台发行游戏的细节。
最初：作为一款带有游戏内部广告的免费Android应用，以及没有广告的付费版本。
带有广告的免费iOS应用。没有广告的付费iOS版本。
游戏内部购买。
考虑：Windows 8，Windows Phone 8，XBOX live和任天堂e-shop。
8.3、本土化
考虑你将支持的语言。添加任何你所想到的内容，这可能会是你到后来才考虑的内容。
最初是英语/西班牙语。
之后更新：意大利语，法语，德语等等。
考虑和亚洲发行商合作向亚洲市扩展，他们将帮助你进行本土化。
9、其它想法
这也是一个可选择的部分。如果你拥有一个你不确定是否适合游戏的想法，你可以将其添加到这里以防自己忘记。
关卡设计师
能够为其他用户所创造的关卡评级
游戏是否应该拥有多人模式？
“通常情况下，比起单人游戏，创造多人在线游戏所需要的精力和经费将增加4倍。”
“通常情况下当你完成一个可行的版本后你将需要花费6个月的时间去平衡游戏。”—-Jesse Schell
我们真心希望这一模板也能够帮到其他游戏开发者。
游戏邦编译如何以及为何要编写一份游戏设计文件
发布时间： 16:38:20
Tags：,,,,
作者：Alex Sayenko
每个独立开发者或团队都会问自己如何最有效地管理开发过程。使用详尽的文件是否必要，如传说中的游戏设计文件（GDD）？最常见的问题是什么？该如何避免这些问题？
对于那些已经寻找过这些问题的答案的人，我想要在此分享我们团队在创造自己的GDD的经验。
为什么你需要一份GDD？
优秀的文件是必须的
许多游戏设计师都忽视了创造设计文件与组织理念的过程。我不能想象当这些设计师在面对故障代码，占位符图像和破损的机制的同时还要努力回忆为什么会出现这些情况时的情形。
通常在这种情况下出色的游戏设计文件总是能够成为你的支柱。它将帮助你看清楚那些推动自己在开始创造游戏时夜以继日坚持下去的出色理念，或者更重要的是帮助你看到那些需要从游戏中删除从而让自己的工作变得更简单的内容，再或者是帮你决定是否需要重新创造某些内容以对得起自己之前的努力。
GDD能够帮助游戏设计与开发
一份游戏设计文件能够作为连接游戏每一面的中心点。它将包含书面描述，图像，图表以及与开发每个部分相关的信息，并且它总是由游戏中的功能以及这些功能之间的联系所构成。
创造一份GDD能够帮助你的团队设计师更好地理解游戏中的必要元素并规划其主导游戏世界和游戏玩法的范围。再加上拥有一份包含所有游戏元素的文件还能够帮助设计师更轻松地向其余团队成员传达自己的看法，并更有效地找出游戏的缺陷或者遗漏的组件。
我们应该将GDD当成主要清单。它将是你在完成游戏的所有部分的庆祝空挡所创造出的文件。
document(from frbiz)
GDD将在其它领域提供帮助
创造并跟随游戏设计文件就像播撒种子并看着它在开发过程中成长成一棵苍天大树一样。你将拥有从初步准备，成长阶段到最终的辛苦收获的过程。
这里的一个常见问题是并未提供给所有团队成员适当的“园艺工具”去创造你的游戏。GDD能够帮助你确保所有人的相互协作，但也因此当你的程序员和美术师切断了他们所站立的树枝时你将全然不知。
常见的问题
尝试着马上描述出所有内容
在初稿中详细列出所有功能和机制是不必要的。这对于在一支小团队中致力于一款复杂游戏来说是不可能的事。列出游戏玩法和核心元素的主要节点能够帮助你明确需要完成什么，同时你也需要一步一步去实现它们，不可操之过急。
没有设定截止期限
似乎有些开发者都不愿为游戏目标设定截止期限。截止期限是无聊的朝九晚五生活方式中的一部分，所以很多人都不喜欢它。
然而设定截止期限能够帮你确保游戏是否完成了并避免你的计算机里永远都会躺着一份未完成的文件夹。这类型目标便是你在前进道路上的里程碑，而通过它们也预示着你完成了某些事。这些都是值得庆祝的事。
截止期限是能够帮助你判断团队和自己绩效的基本排程。它能够帮助你判断决策的制定是否现实，并最终创造出对团队整体以及里面的个体有益的势头。
假设每个人都知道该添加什么
GDD中存在一个包含游戏玩法，故事线和主要编程任务的基本描述。在开发过程中你将添加更多细节到这些部分中。而在创造并测试游戏的同时，你也会在每次执行或改变一个功能时添加或更新一些特定的技术细节。基于这种方式，你可以在GDD中找到各种之前的元素，并且能够创造一些遗漏的理念，代码或图像链接。这对于添加有关执行特定任务的难度，它们是否能够完全整合到游戏中或者是否需要额外调整等信息也很有帮助。
经过这一过程，你最初的理念将逐渐延伸到你的功能所包含的每一面的细节描述中。这将帮助你更轻松地了解所有特定里程碑的起源与终点。
因为GDD将继续发展并不断完善，所以保持更新也非常重要。这能够解决团队成员不知道自己为什么要花大把时间去做某事的情况。
就我个人来讲，我非常厌恶被一大堆印刷文件所淹没。如果我将之前每支团队成员的GDD都保留着的话这对我来说将是一场真实的噩梦。
为什么在数字科技时代我们还要如此折磨自己？现在的我们拥有许多像谷歌Docs或Trellp等免费的在线服务能够帮助你保存所有改变并实时检查所有团队成员的评价。
如何编写一份有效的GDD
按阶段进行编写
当开始编写GDD时，我们通常都会埋头于概念中。像背景，介绍以及关键描述都能够帮助我们具体呈现出游戏轮廓。当你开始测试并执行功能时，这些概念将变得更加完善，具体。当你的GDD变得更加重要且完整时，维持适当的结构便变得更加重要。
从概念阶段开始，这时候你们可以使用头脑风暴会议去讨论理念并将其记在纸上。这是非常让人兴奋的事！这将变成你的路标并避免你在发展过程中忘记最初的目标与观点。当一些特定游戏元素失去魅力或将你带向下坡路时，你便需要调整最初的理念并确保自己能够到达一个让人满意的终点线上。
在开发的冲刺阶段，你的游戏设计文件将保存一些让你受挫与心痛的时刻。当你接近发行阶段时，你的GDD将慢慢变成碑碣一般的存在，即更加可靠的游戏架构带有功能，机制，图像以及多个迭代去满足文件的规格。这份文件应该能够确保整支团队以现实的眼光去交付游戏，
接受游戏开发期间的改变
在整个开发过程中你将不得不改变部分GDD内容，有时候甚至是在发行前最后几天需要做出调整。如果你的内容不能达到平衡的话它将变成一个灾难区。如果你不想删除一些过时的文本，那就将其剪切黏贴到一个附录文件中。这能够保持你的GDD主题与当前的开发状态相匹配，而不存在一些不相干的内容。
不要阻止团队成员继续提出新理念。理念创造是开发中最有益的部分之一，这是我们应该一直倡导的部分。你的团队成员应该深入开发过程并了解各种将被删除并且永远不会被带进游戏中的概念，但前提是这不会阻止他们继续幻想！一开始没人会知道哪个理念能够创造出最棒的效果，所以你应该将创造全新且具有创造性的理念当成是讨论与庆祝的主要对象。
只安排一个人去管理它
你最好只安排一名团队成员去管理GDD。他们将审查需要关注的关键理念并删减不那么重要的理念。
鼓励积极反馈非常重要，因为其他团队成员往往没什么机会直接将自己的理念添加到文件中。
大多数开发问题都是由带有坚硬外壳的误解与不了解如何纠正它们的本质所组成。而如何能够有效维护GDD并保持文件的清晰整洁， 你便能够有效缓解这些障碍，而如果有一个人能够担负起这项责任，你们便能够更有效地做到这点。
专注于可读性
确保语言足够清晰
保持GDD中的语言更简单且更清晰的话，你的团队便能够更轻松地理解它。
你必须确保编写内容足够清楚且简单，你的团队也需要积极地提供给你有关GDD表达的反馈。如此来回的动态交流将帮助你们创造出更具有凝结力的开发体验，即包含了明确的美术风格，较少的交流问题以及较轻松的文件制定与工作任务。
但是最重要的还是，GDD应该反应出你的团队文化，即基于你们能够最有效工作且最能够吸引你与团队成员的工作模式。
使用视觉帮助
没有人会说因为GDD中缺少参考对象而导致自己不理解某些内容或者未能正确做好某事。
视觉材料与参考内容在传达理念的过程中扮演着一个关键角色。即基于像图表和概念艺术等视觉帮助，我们可以使用更少时间去解释一些复杂的理念。这也能够保证每位团队成员能够更轻松地理解那些自己所接收到的信息，并帮助他们更快速地完成开发任务。
投入一些热情
你不应该只局限于这些干巴巴的文本内容。（如此你便需要等待很长时间才能让所有人真正理解你的主要理念！）你可以尝试着描述游戏可能集大发玩家情感以及玩家体验。
确保你的GDD听起来够专业，并且你应该真正倾注自己的心血于其中。将你的情感与激情投入于此。想象自己希望玩家有什么感受，并在描述功能的过程中记录下所有的这些灵感。这能够培养你们团队有关游戏想要传达给玩家的内容的集体意识—-我们必须牢记，如果你希望所有人能够理解你想要传达的某种情感，那么这种情感便必须具有热情！
使用它去引导别人
设定任务和功能的优先顺序，记下它们的截止期限，并控制它们的执行。你不可能去开发你和团队想开发的所有理念，所以你便需要为它们设定先后顺序，至少需要规划它们的执行时间。
一份整洁的GDD有助于你罗列出团队需要执行的任务先后列表。并非GDD中的所有功能都能被添加到最终游戏中。牢记这点后你便需要决定哪些功能先于其它功能执行，并制定它们的执行与测试时间。
仔细思考什么内容对你的游戏最重要，并且是否能够提供给你的团队相关技能，然后使用这一信息去引导生产过程。
一份有效的GDD同时也能够吸引全新团队成员加入项目中，并让他们对你所做的事感兴趣。
在GDD中分配你的团队成员任务将使得这份文件变得更强大并确保所有人都处于同样的节奏上。任何进入该文件的人都能看到你们团队完成了什么内容，他们以及团队面对着怎样的任务以及为什么他们要致力于当前的任务中。
持续进行设计讨论
在分享性的GDD中编写某些内容并不等于减少与团队间的对话，它将进一步推动团队间的讨论并完善你的交流方式。你必须确保所有人都能够理解你对于游戏中每个功能的设想。
删减理念是很困难的事，但这却是创造游戏的特定过程。保证开放自由的讨论是开发的组成部分，并且能够缓解一些内在的紧张感且推动团队成员更大地发挥创造性。
在脑子里玩游戏
在创造游戏之前或创造游戏过程中我都会在脑子里尝试着设想一些不错的想法。当然了这并不能保证这些理念在开发和测试过程中便会扎根于游戏中，特别是在早前阶段，这其实是一种有效的头脑风暴方式。
树立一些现实的目标
尽管培养团队间的兴奋氛围很重要，但是你也必须确保你们的游戏目标始终具有现实性。在书面上，机制，复杂的敌人和关卡行为总是看起来很不错，但现实总是会基于某种方式去吞噬特定的游戏元素，你应该想到这点。
利用免费在线工具
我们的团队成员来自不同国家。我们生活在不同国家，不同时区，所以我们不可能使用印刷版本的文件，并且我们也很难进行实时会议。所以使用像Skye，Google Drive，Google Docs和FlockDraw等免费工具能够帮助我们更好地进行解释与讨论。
如果你发现自己对维护一份GDD对于游戏制作是否必要保持中立态度，你便可以仔细着眼于自己的想象开发过程。当然了。现实生活和自己的全职工作有可能阻碍到你的游戏创造，或者你会遇到功能和机制未能如期有效运行等情况。
在波涛汹涌的游戏开发过程中，一份有效的GDD就是一艘坚实可靠的船只，有时候甚至能够充当救生艇的角色。这是关于你的努力和胜利的详细记录，这是你在艰难时期能够回顾的所有想法集合。你可能会发现对于GDD的完善将影响到剩下的开发过程。这是推动团队讨论并生成全新且更出色理念的坚实核心。同时它也能够确保这些理念足够现实。
也许从个体看来这些效能的好处并不大，但在整个开发过程中它们将逐渐创造出一个巨大的势头。最终，这类型文件将推动你和团队去完成你们在一开始所决定创造的内容。你也将看到你的游戏拥有一个能够实现的规划。
当你完成游戏时，你的GDD将作为你的所有付出与努力的证明，这也是所有人所体验到的内容的幕后花絮。
（本文为游戏邦/编译，拒绝任何不保留版权的转发，如需转载请联系：游戏邦）
How (and Why) to Write a Great Game Design Document
by Alex Sayenko
Every indie developer or team has asked themselves how best to manage the development process. Is it obligatory to use detailed documentation, such as the legendary game design document (GDD)? What are the most common mistakes, and how can they be avoided?
For those who have searched for answers to these questions, I want to share our team’s experience of creating our GDD.
Why You Need a GDD
Good Documentation is a Must
Many game designers abstain from cultivating design documents and organizing ideas. I can’t imagine how these developers get through those times that they are hampered by malfunctioning code, placeholder art, and clashing mechanics, all while trying to remember why it was that they first subjected yourself to making a game in the first place.
Having a well thought out game design document can act as your crutch in these times. It will let you see the awesome ideas and concepts that kept you up all night long when you first started on your game, and, perhaps more importantly, which ones need to be cut from the game to make your life easier, or reworked to make your efforts worthwhile.
A GDD Aids Game Design and Development
A game design document acts as a nexus and hub to connect and list every aspect of a game. It consists of written descriptions, images, graphs, charts and lists of information pertinent to each segment of development, and is often organized by what features will be in the game, and clearly lays out how they will all fit together.
Creating a GDD will aid your team’s designer in understanding what the essence of the game is and the planned scope of its overarching world and gameplay. Plus, having all the game elements in one well-organized document will help the designer easily convey their vision to the rest of the team, while also helping to pinpoint weaknesses or missing components that the game may require.
The GDD should serve as your master checklist. It will be the document you toss up in the air in celebration upon completing all its sections and finishing your game.
A GDD Helps in Other Areas, Too
Since a GDD is full of descriptions, it is an ideal resource for all PR and marketing fronts, with concepts that convey the game’s aesthetic and appeal already written up and ready to copy and paste.
Prospective employees’ skills can be quickly assessed as qualified or not by looking at their credentials alongside their positions’ corresponding sections in the document.
If fundraising is in the cards for your team, it will be crucial to have a well put together GDD for investors to look over and determine the risks of your development, as well as your ability to deliver on your promises.
A GDD Keeps Everyone on the Same Page
Creating and adhering to a game design document is like planting a seed and watching it grow into a tree over the course of development. You have your initial preparation, cultivation, and ultimately the gruesome and backbreaking toil of the harvest.
A common mistake is not handing all your team members the proper gardening tools to make your game a reality. The GDD will help make sure everyone is working together, so that you don’t find your programmer and artist cutting off the branch they are standing on.
Common Mistakes
Trying to Describe Everything at Once
It is not necessary to list every feature and mechanic in detail in the first draft. This is impossible when working on a complex game with a small team. Outlining the major nodes of gameplay and core elements will help give you perspective on what needs to get done, but you should expect to fill them in one by one, over time.
Not Setting Deadlines
Setting game goals with deadlines may seem off-putting to some developers. Deadlines are a part of the boring 9-to-5 lifestyle, so many people have a natural aversion to them.
However, setting deadlines is how you ensure that your game will get made and not sit forever unfinished in a folder on your desktop. These types of goals are milestones on the road to progress, and passing them one by one is a clear indication that you are doing something right. Each is a cause for celebration.
Deadlines are a basic component of scheduling that helps you monitor the performance of your team and yourself. It aids in decision making that is rooted in reality, and eventually builds up a momentum and ethic that is healthy for the team as a whole and the individuals within it.
Assuming Everyone Knows What to Add
There is room in the GDD for basic descriptions that cover gameplay, storylines, and major coding tasks. As development progresses, you add more details to these sections. While creating and testing the game, you should add or update specific technical details every time a feature is implemented or changed. This way, you’ll never have a build with elements that you can’t trace back to the GDD, creating missing links of ideas, code or art. It can also be helpful to add information about the difficulty of implementing certain tasks, and whether they have been fully integrated into the game or may require further revision.
Throughout this process, your initial concepts should be trickling down into ever more detailed descriptions of each facet your features contain. This helps make concrete milestones that are easy to navigate and backtrack to see where they originated and where they need to go.
As the GDD continues to grow and become more finalized it is still important to keep it up to date. This eliminates situations where team members do something without being able to justify why they spent time doing them, which is crucial come crunch time.
Printing the GDD
Personally, I have an unexplained primal fear of drowning in a heap of printed documentation. This would become a real nightmare if I had to keep all old versions of our GDD for every team member.
Why should we torture ourselves like this in the age of digital technology? There are plenty of free online services like Google Docs or Trello that let you save all changes and see all your team’s comments in real time.
How to Write an Effective GDD
Write It in Stages
When starting the GDD, it is normal to get wrapped up in concepts. Backgrounds, introductions, and key descriptions help to flesh out the game and give it shape. As you begin to test and implement features, these concepts should become more refined, specified and detailed. Maintaining proper organization will become more and more critical as your GDD gains weight and density.
Start in the concept phase, where you brainstorm your ideas and get them all down on paper. This should be exciting! It will also serve as a roadmap so you don’t lose track of your goals and vision along the way. When the appeal of certain game elements lose their lustre or lead you into a ditch, it may be time to rework your initial concept to make sure you reach a satisfying finish line.
Towards the middle of development, once you have a gung-ho team on board, discussions and game builds will help sculpt and organize the document into an easy to use and hefty guide for everyone. There’s still room for experimenting with new concepts and ideas at this point, but they should be kept in check with some of your initial documentation.
The home stretch of development is where your game design document will save you hours of frustration and heartache. As you close in on release your GDD should slowly start turning into a stone tablet, with features and mechanics set in more permanent game builds all held together by art that was surely crafted over multiple iterations to match the document’s specifications. The document should help keep all the team’s wheels on the ground, with a good line of sight on realistic expectations on delivering the game.
It is not necessary to have an absolutely complete GDD before starting development. But the GDD must be complete for the next 10 days or two weeks beyond your team’s current work—and the relevant parts of the document must be as detailed as possible.
Allow Changes During Your Game’s Development
Parts of the GDD will have to be changed and modified throughout the entire development process, sometimes even in the final days before release. It can start to resemble a disaster zone if the content is not trimmed properly. If you are afraid of deleting text that is outdated, cut and paste it into an addendum or separate document. This will leave the main body of the GDD relevant to the current state of development, without all the distractions of previous iterations.
Don’t ever stop team members submitting new ideas. Idea creation is one of the most rewarding parts of development, and should be encouraged at all times. Your team members should head into development knowing that many of these concepts will be cut and never make it into the game, but this shouldn’t stop them from dreaming! No one knows what ideas will produce the best results at first, so generating new and innovative ideas should be a staple of your discussions and celebrated accordingly.
Put Just One Person in Control of It
Supervision of the GDD must be performed only by one team member. They will identify the key ideas that must be focused on, and cut the less important ideas.
Encouraging active feedback is important, then, because other team members do not have the chance to add their ideas to the document directly.
Most development issues are comprised of a hard outer shell of miscommunication and a soft interior of not knowing how to compensate and correct them. These barriers can be eliminated with vigilant maintenance of the GDD and clear, concise documentation, and this can best be achieved if one person takes on that responsibility.
Focus on Readability
Be consistent with font styles and using uniform headers and indentations, punctuation, and formatting. Creating a legend or key to explain what specific colored highlights mean can go a long way toward reducing confusion and cutting down on the time it takes to convey the stages of different features’ implementation.
Keep the Language Clear
The simpler and clearer you keep the language in the GDD, the better your team will understand it.
It’s important to keep the writing clear and concise, and your team should actively give you feedback about the presentation and clarity of the GDD. A back-and-forth dynamic will result in a more cohesive development experience, with overarching benefits including a defined art style, fewer communication errors, and less stressful documentation and office work.
But most importantly, the GDD should be a reflection of your team culture, created in whatever format you find works best and is most appealing to you and those you work with.
Use Visual Aids
No one should ever be able to say that they haven’t understood something, or done something correctly, due to a lack of reference material in the GDD.
Visual materials and references play a key role in the process of conveying ideas. Some difficult concepts can be explained in less time with visual aids like graphs and concept art. This will help ensure every team member understands the information that is conveyed to them, which in return will help them to complete development tasks faster.
Put Some Passion Into It
You should not restrict yourself to dry text. (If you do, you’ll be waiting a long time for everyone to get engaged and understand the main ideas!) Try to describe the players’ emotions and the experiences that the game might cultivate.
Keeping a GDD may sound technical, but you shouldn’t be afraid to tear your heart out and throw it at the document. Let your emotion and passion bleed into it. Imagine how you want to make the player feel, and write those aspirations down alongside the descriptions of your features. This helps to cultivate a collective consciousness in your team about what your game is trying to convey to the player—and, let’s face it, feelings should have enthusiasm behind them if you want them to be understood by anyone else.
Use It to Keep People on Track
Set the priorities of tasks and features, document their deadlines, and control their execution. You can’t develop absolutely all the ideas which your team and your mind will propose, so (after you’ve cut some of them), you need to set their priorities and at least approximate a schedule for their implementation.
A well-groomed GDD makes for an excellent, prioritized list of tasks that need to be completed by your team. Not all the features in a GDD will make it into the final game. With this in mind, you must decide which features take precedence over others, and you should schedule them for implementation and testing before those others.
Think hard about what is critical for your game, and what is possible given your team’s skill level, and use that information to guide your production.
A solid GDD can also help ease new team members into the project, and get them just as excited about it as you are.
Since a fully outlined GDD may result in what seems like an excessively daunting game to make, it is good to remember that more than one person will be fleshing out its specifics. Assigning your team members tasks in the GDD will help it to become more robust while keeping everyone on the same page. Anyone can jump in to the document and see what has been completed, what tasks lay before them and the rest of the team, and why they are working on their current task.
Continue Having Design Discussions
Writing something in a shared GDD shouldn’t minimize or eliminate discussion with the team, it should serve to increase team discussion and improve your communication dynamics. It’s important that everyone clearly understands how you (and the other team members) imagine each feature of the game.
Cutting ideas can be difficult and unnerving, but it is a process innate to creating games. Making sure that open, free discussion is a part of development will help ease the inherent tensions here, without dissuading members from being creative.
Play the Game In Your Mind
I found many good ideas virtually playing the game in my mind, both before and during the game’s creation. Of course, this doesn’t give any guarantee that those ideas will take roots in the game during development and testing but, especially in the early stages, it’s a good method of brainstorming.
Set Realistic Goals
While it is good to foster an air of excitement within a team, it is equally important to keep your game goals embedded in reality. Mechanics and complex enemy and level behaviors always look great on paper, but reality has a way of corroding the grandeur of certain game elements, and this should be expected.
Consequences of updates and changes are almost impossible to foresee ahead of time in some situations, so just remember it is your job to try and limit the amount of remodelling that needs to be done when changes arise. If you make it common practice to play through new ideas in your mind before putting them down on paper, you stand a greater chance of keeping development goals rooted in realistic expectations.
Make Use of Free Online Tools
Our team is multinational. We live around the world, in different time-zones, and this makes it impossible to use print versions of documents for everyone, and difficult to have real-time conversations. Using tools such as Skype (for conversations), Google Drive (for sharing files), Google Docs (for collaborating on documents, and sharing the GDD), and FlockDraw (for digital drawings) can really help with explanations and discussions.
Conclusion
If you find yourself on the fence about whether maintaining a GDD is necessary for your game’s production, you should take a good, hard look at how you envision development. There are almost certainly times where real life and full time jobs will get in the way of game making, or your implementation of features and mechanics simply does not work out.
On the stormy seas of game development, a healthy GDD can serve as a sturdy and solid vessel, and even a lifeboat at times. It is a detailed journal of your struggles and triumphs, a collection of thoughts and ideas for you to fall back on during hard times. You might find that improving the quality of the GDD trickles down into the rest of development as well, raising the bar across the board for your team. It should serve as a sturdy hub to facilitate team discussion and generate new, even greater ideas. At the same time, it can keep these concepts in realistic check.
The benefits of this type of efficiency may seem small when looked at individually, but over the long course of development, it builds up a wonderful kind of momentum. Ultimately, this type of document should propel, compel, and inspire you and your team to finish what you started. It should show you that your game has a plan that can be realized.
And after you have finished your game, your GDD will stand as a testament to all of your hard work and efforts, the behind-the-scenes of an elaborate experience to be enjoyed by all.（）
CopyRight Since 2010 GamerBoom All rights reserved &&闽ICP备&号-1