游戏角色设计专业
绝技惊呆小伙伴做游戏角色设计师比你想的要简单！
临摹服装服饰贴图
制作游戏基本道具
经典商业案例临摹
制作卡通动物
制作怪物角色模型
制作女性角色服装装备
用就业工资付学费 ，扫清一切学习阻碍不靠父母，为自己成功买单汇众教育阳光助学计划
高薪就是事实，用数据说明一切
其实，我们可以让你工资更高！你的辛勤与头脑+我们的师资与培训方法=秒杀同行的无敌存在
还想继续看着可怜的工资单苦恼吗？实现梦想，so easy！
6个月就想挑战过万月薪？！好吧，行吧，来吧…向你的授课专家学习，做他的"复刻版"。
技术小白到职业专家，这不是奇迹！
游戏角色设计师年薪100000+
必备技能：
游戏道具模型设计
游戏人物模型设计
游戏生物模型设计
各类型材质贴图处理
游戏主美年薪180000+
必备技能：
游戏角色设计师技能
次世代角色模型设计
游戏美术原型设计
雕刻建模技术
赢在职场职业技能
游戏产品总监年薪300000+
必备技能：
游戏主美工作技能
产品原型设计
赢在职场职业技能
就职领域：PC客户端游戏、网页游戏、移动媒体游戏、虚拟现实
游戏角色设计培训精华课程
课程设计源自于企业真实岗位技术规范、流程，全部是干货！
教学方法源自于全球公认的迭代式高效学习法，您一学即会！
教学案例源自热门行业过亿元商业项目，货真价更值！
授课教师源自于一线名企，开发经验五年以上，实战经验牛！
精益求精，这是高薪就业岗位课程
CG艺术基础
了解头部骨骼结构、五官的比例结构，分析人体大的骨骼结构以及人体骨骼的基本形态
从身体躯干的骨骼到四肢的骨骼来具体分析各自的特点
了解肌肉的分布与运动的关系，从主要躯干的肌肉到四肢的肌肉结构分析其特点
面部的结构、皮肤的质感表现
金属材质的表现技法、布料的表现技法
游戏场景道具
道具盾牌的制作:Maya软件的基本界面的认识与基础操作以及建模方法
道具刀的模型制作：3dsMax的基本界面和基础操作、POIY模型的制作方法、游戏道具的制作过程
中式场景制作
卡通动物的低模的创建：UV拆分插件UVLayout的软件应用
写实动物的制作方法：Bodypaint软件的基本知识以及绘制贴图的方法
角色头部建模：讲解头部造型
男性人体的建模以及建模的技巧，分析人体构造
头部UV（学习头部的UV展开方法）
头部贴图的绘制方法以及讲解头部解剖结构
身体贴图的绘制，深入讲解人体结构与人体的表现手法
掌握人物角色服装（装备）的建模方法
学习服装（装备）的UV拆分，已经UV的合理利用
西式场景制作
网游角色商业案例临摹
学会Q版角色的贴图绘制
环境营造和组合场景
根据怪兽的身体特征创建怪兽的模型以及UV的拆分的技巧
Bodypaint: 绘制颜色贴图、通过材质的叠加表现角色的质感
经典模型商业案例临摹
教学与全球接轨，五大国际主流开发软件
美国Adobe专业绘图软件Photoshop
美国Autodesk三维建模软件Maya
美国Autodesk三维建模软件3ds Max
德国Maxon Computer三维绘图软件Bodypaint3d
三维模型UV拆解专用软件UVLayout
三大途径，让学习无处不在!
令你战斗力瞬间飙升！
把课堂装进手机
"微学习"客户端，让你随时随地High翻众人。
你的学习你掌握
"云世界"在线教育系统，独一无二的学习管理数据库。
海量视频伴你行
"云课堂"在线教程，一生无忧学技能。
两大神器，助力成就高薪"真功夫"！
汇众首创&&&&业界唯一
《游戏角色设计学习任务书》——带着任务学习、课课都有目标；由易到难、循序渐进；天天有收获，月月有成就；边学习、边实践。工作经验与技能一举两得！
《游戏美术设计项目开发手册》——模拟企业开发团队，扮演真实岗位角色，完成真实项目开发，把企业搬进校园，实训便在工作。毕业即有开发经验。让您的简历不再空白！
商业案例 全方位透析真实企业开发流程！
商业运营项目做实训，没有比这个更真实了向大师级的作品学习，站在巨人的肩膀上走向成功敢想敢做敢实践，我们看好你
铁"证"如山，职场竞争的杀手锏
国际数字艺术教育市场的行业认证标准
Adobe 指定内容开发合作伙伴
汇众教育成为Adobe创意大学内容开发战略合作伙伴，负责其多个专业方向的教学方案研发、师资培训方案、技能认证体系等内容的建设与开发。
同时汇众教育的全体学员都能通过汇众平台学到国际领先的设计技术、应用经验和创意理念，并且获得Adobe专业认证。
游戏角色设计师认证
动漫游戏开发技能认证的唯一标准
企业入职必备利器
具备专业开发能力的身份象征
助你战胜其他竞争对手
一证在手，职场畅通
国家技能等级资格认证
国家信息技术紧缺人才职业技能证书网络游戏美术设计师（中级）
升职加薪的皇家令牌
专业技术领域的"硕士"文凭
专业开发技术的国家等级认证
工资评级、职位晋升、社会保障、工作居住证都能用到它
更难就业季，5000家名企职等你来
国家级就业创业计划合作企业任你选，数量不多，重在质量给你一个稳定的工作
一流的教学与就业保障，只有在汇众！
全国32家实训基地标准化教学管理模式，无一例外在汇众，所有实训基地的同学都是你的人脉
创造生命，注入灵魂，打造你的虚拟之旅
更多热门课程解析游戏设计文件的类型及其内容要求
发布时间： 11:31:35
作者：Francois Dominic Laramee
天下没有所谓的“标准”游戏设计文件。但是，所有的娱乐形式都有一些相同的特征，并且经过多年的研究，我发现了一个能够维系游戏设计活动并帮助我更好地专注于工作中的方法。本文将简要陈述我如何从想出一个创意并完善它，然后移交给制作者，最终变成一款游戏的过程。
需要注意的是，这些关于电脑游戏设计的理念大部分也适用于桌面，角色扮演及邮递型游戏设计。
game desing document(from lm-crowd.blogspot)
游戏设计的六大简要步骤
根据你所设定的游戏类型以及游戏设想的情况，你可能需要根据创造过程中的不同阶段而拟定6份不同的文件。不要认为这是一项繁琐的工作，当你真正将其落实行动时，你就懂得我的用意了。
所有游戏开发之前都应该明确一个设计说明，如快速讨论你的产品有何独特功能以及你的目标用户是谁等。
然后你便开始进行初步设计，讨论你的游戏规则，内容以及行为等。这份文件应该尽可能广泛地讨论任何可能发生的情境。
最终设计将会重新描述之前的文件内容，而确定产品的功能。
产品规格将详细描写最终设计中所采纳的功能。
图解将最终决定游戏角色，地图，道具等的外观和风格。
如果有的话，互动剧本将包含对话框和故事情节，并在游戏产品中得以体现。
很难判断游戏设计者是否能够编写这些文件。例如，电脑游戏的产品规格需要游戏制作人，主程序员以及美术设计师的协作，而故事剧本的任务则自然落到职业写手身上。然而，作为“游戏理念的守护者”，设计师对于产品拥有最终发言权，并且应该参与整个过程的方方面面。
只要你仍然处在设计过程，那你就有办法终止一个项目。即使你已经完成了最终设计文件，并手握完整的的故事剧本，即将递交给制作人，这时候取消这个项目也只会耗费你总生产预算的10%。除非你公司的所有人（包括工作室成员，销售人员，媒体人员等）都深信这款游戏能够取得成功，要不你就应该立刻终止它。而如果是在六个月后，你已经投入了1百万美元去开发游戏，一切就太迟了。
“设计说明”，也有人称其“设计方案”，“设计大纲”或者“规格单”。
设计说明是关于你想要创造什么样的产品以及你需要做些什么的简短描述（4-8页）。创造这个文件的原因很多：它能够帮助设计者实践一个“创造性理念”，它能够创建一个未来设计作品的框架，它还可以作为一个引起公司主管和发行商兴趣的推广工具。
根据不同的阅读对象的不同，设计说明的确切内容也会有所变化，但是幅度并不大。也许在第一次接触发行商时不适合参入财务信息，但是其它需要包含设计说明中的内容如下：
游戏类型和主要功能。例如，《毁灭战士》的设计方法：基于3D光线投射引擎的第一人称射击游戏。
关于游戏体验的简短描述。游戏带有喜剧效果？惊悚游戏？智力游戏？侧重于技术体验，图像表达还是故事阐述？线性描写？是单人游戏还是多人游戏？适用于局域网还是英特网？游戏设置或者游戏界面的关键因素是什么？
你希望创造什么类型的游戏？是现实的3D模式？卡通类？等距游戏？还是拥有许多错综复杂的移动组合体和秘密空间的游戏？或者是适合于儿童的直接游戏设置？
你要如何构造游戏？关卡式，任务式还是章节式？有几个部分？每个部分的长度？你能提供给玩家何种重玩价值？
你需要什么资源？需要多少人，花多少时间完成游戏？是否需要具有专业3D知识，网络程序设计或者AI相关理念的高级工程师的协助？（你的员工中是否有这类型的人才？如果没有是否考虑雇佣？）
是否需要一个引擎？新的开发工具（如新版本的Softimage 3D软件）？你是打算购买这些工具还是自行开发？
在使用别人的知识产权之前先获得授权，或者你可以创造属于你自己的原创内容。在适当的时间获得适当的授权便意味着你能够“自由”地进行一些额外销售，虽然这种代价可能会很高；并且，你必须确保自己所获得的授权有效期是从现在起的2年内。
你的主要角色/单位/游戏部件是什么？
谁是你的目标用户？益智问答游戏，《芭比娃娃》服装设计类游戏，象棋类游戏以及《Quake》类杀手游戏吸引的是不同类型的玩家。
你的目标平台是什么？第一选择是哪个？你将自己执行游戏的平台推广还是聘请外包人员代工？
你的团队是否有资格发行产品？拥有行业经验和履历的发行商会比较轻松，但是如果你是行业新手，你可能也还有其他的资源优势。举些例子来说，如果你的亲戚是去年温斯顿杯（NASCAR的首要赛事，是当今世界上最具竞争性的赛车项目）的首席机工长，而他答应在你的NASCAR赛车游戏开发中提供咨询与帮助，那么你便赢得了先机。同样地，如果你正在开发一款围绕“十字军东征”的模拟游戏，那么从当地的大学中邀请一名历史学家作为游戏顾问也是个不错的主意。
生产预算和计划的初步估计。在这个阶段，我们能够给出的信息总是较为模糊，就像是“在一个6人小组中，耗费10-12个月时间，开发工具和固定成本约50万到75万”，而这样的表达也就足够了，因为人们总不希望一开始就看到长篇大论的精确预算内容；读者们希望了解到的只是，这个产品到底是经费拮据还是经费充盈。
设计说明就像是你的项目名片，你应该尽可能地保证它的简短，真实且具有代表性。如果你拥有一些初步的图像略图（游戏邦注：例如游戏角色或者场景等），那就将它们用到游戏中去吧！如果你的游戏是基于喜剧性，那么你的文本就必须具有乐趣。除非你有非常中肯的原因，要不就尽可能地将文本压缩在4-5页，可能的话可以添加2-3页的图像。如果你递交给发行商的是上百页的文件，我想他们肯定没有耐心读完这些内容吧。
总之，设计说明不需要投入100至150小时如此长的时间，如果不包含任何图像，那么75个小时便足够。而如果你投入了更多，便只会是浪费时间。如果你只是业余设计者，如此投入对于你来说便不是太大问题，而如果你是一间专业游戏开发工作室的员工，那么100-150小时的投入也意味着你需要花费公司5千至7千美元的开销。而且你的设计说明并不可能带来100%完美的设计。所以如果你的创造性理念仍然存在缺陷，那么请果断地转向其它设计说明。
完成了设计方法后，难道你就以为自己稳坐成功宝座了？
将你的设计方法塞到抽屉里，深吸一口气，去做做其他事，暂时不要想你那伟大的创想。至少是2周的时间。2周后，如果你仍觉得这个设计方法很棒，那么就开始实践它，将其公开在世人面前吧！
如果一家公司只是创造出一些理念，并执行它们，而未停下来观察并思考这些理念是否可行，那么这家公司便很容易因为糟糕的理念而遭殃。作为一家小型电脑游戏发行公司的经理，我发现许多成品或者技术先进的产品都忽略了设计方法这一阶段。我在1997年的中国游戏开发者大会上见过一群充满潜力的年轻人，他们曾经花费了数月的时间开发出一款技术可行，充满视觉效果，且容易操作的游戏，但却因为这款游戏是基于一个糟糕的理念，而最终难以顺利发行，迫使这些年轻人不得不辛苦地找寻愿意帮助他们的发行商。这么做只是在浪费时间。更糟糕的是，从他们的产品价值来看，他们真的是一些很有天赋的人才，仅因为这点就埋没了才能真的很可惜。
广泛地传播你的设计说明，如果获得了不错的响应，你就可以着手进行完整的设计或样本制作了。而你同时也要小心游戏理念被盗的危险，但是你却常常对此束手无策，除非你在寻找发行商之前拥有足够的资金或时间去进行完整的游戏设计和样本制作。而这也是许多开发工作室遭遇失败的第二大原因：他们将所有赌注下在一款产品身上，但最终却找不到能够销售的市场。
游戏开发链
聪明的设计师永远不会被自己的理念所束缚，原因有以下几点：
如果你编写并提交了10个设计方法，也许只有3或4个能够引起受众的注意，并且他们愿意担保你的初步设计，而可能只有2，3个受众愿意支持你的完整设计。
如果你有3个最终设计方案，其中可能有1个是根本没有生产可能性，或者会因为资金紧缺而中途取消生产。
如果你有10款完整的电脑游戏，只有2-3款能够获得广泛的发行，而4-6款只能获得适当的市场覆盖率，甚至有一些根本不可能发行。当发行商遇到财政危机时可能会中途终止合约，而如果你足够幸运，与他们签订了预先付款的条约，那么你便可以利用这笔钱去开发另外一款游戏了。
每一年都会出现款电脑游戏，但是根据估计，只有不到100款的游戏能够勉强维持财政收支相抵，而只有少数一些游戏真正能够赚到钱。
这种情况在掌机游戏市场便稍显乐观，但是你也需要清楚：这里很少出现非常轰动的游戏，而这也不全是因为设计缺陷。即使你拥有足够优秀的理念，也不一定能够创造出畅销的成品，因为发行渠道也是一大关键问题。如果你的团队能够养活自己并开心工作，就应该对此感到满足了，因为这是很多业界人士所期盼但却难以达到的目标。
初步设计文件
初步设计文件可以被当成一张有组织的功能清单。主要罗列你需要表达的游戏设置，技巧，外观等，而不需要详细阐述如何执行。
初步设计也是一种讨论文件，它也有可能需要经历多次迭代。如果你正在设计一款角色扮演游戏或者桌面游戏，你便可以在这个阶段开始进行游戏测试，而以此淘汰一些无效的元素。电脑游戏较为棘手，因为你只有在后来的生产过程中才能真正接触到游戏软件；不过，你能够与公司中的其他设计师，首席美术设计师或者主要编程人员公开讨论设计文件。
初步设计文件的内容主要基于游戏类型，并且我们不需要为此明确一个特定的标准。举个例子来说，以下是我曾经参与编写的一款3D PlayStation游戏的部分清单内容：
技术规格：帧率，纹理分辨率，颜色深度，角色数量，单人或多人模式，摄像机操作等。
幕后故事，包括游戏全动态影像简介的故事脚本。
演员表：玩家的角色以及他们的独特才能，反派角色，他的船只，配角演员组等。
游戏环境列表以及每个环境中需要完成的任务。大约有1-2页关于每个任务特征的一般信息（如滑面，低能见度，怪物的类型，赛跑vs.射击等）。
特殊的弹药，道具，陷阱，炸弹，装备。
怪物，以及能够定义它们的信息，如：忍耐度，攻击可能性，行为类型。
玩家角色的生命，健康，复活等标记。
移动列表，包括在特殊情况下出现的秘密且具有特殊目的的移动。
我曾经看过20页（关于射击者）以及60页（关于战略运动类模拟游戏的细节描述）的初步设计内容。
我们不仅需要确保不会浪费无谓的时间于无尽讨论中，同时也应该深入讨论那些仍有疑问的问题。尽可能缩短设计时间以缩减经费，才能保证你的产品的成功。对于设计师来说，初步设计可能需要花费他们4-10周的时间，而对于那些参加头脑风暴的人来说，他们只需要10-30小时便能够创造出一份初步设计。
最终设计文件
在初步设计的讨论过程中你可能会抛弃一些功能，或不时引入一些新功能。当每个人都认可了你设定的功能时，你便可以将其应用到游戏中了，而这时候的设计文件便是最终设计文件。
一份优秀的最终设计文件会包含许多细节；甚至是那些你可能还在犹豫不决的内容也会出现在这里。最终设计文件中的所有内容都必须具有关联性，因为它们能够帮助你在生产之前更好地审视你的设计，而不用在游戏开发阶段白白浪费大把时间。
最终设计的内容与产品规格其实有一定的重叠性。举个例子来说，如果设计师是一名高级程序员，他将会写下他觉得游戏中应该具有的特殊软件功能的相关公式；而因为是他想出这些内容，所以只有他自己最了解这些内容的运行表现。在最终设计文件应该包含一个优先事项清单：游戏中必须具备哪些功能，拥有哪些功能对游戏更有利，如果还剩一点时间你想添加哪些功能（如果没时间哪些功能会让你想为此延长时间）等。而不争的事实是，很多生产过程常常在这点上迷失方向；游戏产业并不专攻软件工程技术，即使是有组织性的工作室也会因为某些原因而出错。很多事情其实都是可以避免的，只要你能够提前发现并采取适当措施，减少风险；除此之外，你还可以推迟这些“风险”，或者在适当的时候彻底排除它，避免浪费团队的时间和精力。
当最终设计文件敲定后，首席设计师可能已经在此花费了150-400个小时了，甚至更多。最终设计文件可以是75-200页，或者更多。我个人的记录是在169页左右。而带有剧本的互动电影本身就需要300-500页了！
为了让你们更好地了解最终设计文件中应该包含的细节内容，我将以多人运动模拟游戏为例进行说明：
时间长度和赛季（如每年几次，新联赛什么时候开始等）
至关所有团队的联赛等级，以及基于强队和弱队而进行的升级或降级。
创建一个新团队的程序：标准和团队的特定颜色，创造新队员，构造体育场，扩张选拔活动。
关于这些虚拟队员属性和资料：有超过40种属性，包括才能（当前或潜在才能），健康，运气以及个性；系统中将会编辑每个列表统计，并保存成为记录本。
调查过程：资料库中明显展示出的内容是什么（有多明显？），以及隐藏在资料库背后的又是些什么内容。
以下内容将会传达给玩家：内容，布局，频率。
关于数据输入应用界面的细节描述，包括菜单列表和输入框。
经营管理：雇佣或解雇队员，招募一些小联盟，培训，基于裁决机制进行交易（防止单方面交易），调查，票价，工资上限，合同，如何从电视或新闻发布上谋得利益。
游戏管理选择：玩家可以发送什么命令，而玩家在命令中出现的错误要如何处理。
玩家注册后可以收到使用手册。
游戏的模拟器使用方法，包含各种细节
随机事件：意外事故，影响虚拟队员表现的“现实”问题以及嫉妒等情绪。
游戏定义语言：可以用较为紧凑的形式保存游戏，并自动产生实况报道文本。讨论游戏价格，营销策略以及奖品等。
完成设计后，你便需要开始进行前期制作了。在这个阶段，设计师的工作是与制作人，首席美术师以及主程序员合作，确保项目计划的开发完全按照他之前预想的情况发展。
这就意味着你需要和首席美术师坐在一起，观看他如何绘制主角，并花时间与主程序员讨论，确保最合适的运算法则，让非玩家角色也能够产生适当的行为，并确保所有适当的开发工具在适当的时间都能够有序运行等。
产品规格本身就是一个开发过程的蓝图。理论上来讲，当产品规格完成后，设计师便可以功成身退了。但是现实中却不是这么容易，我们不得不采取一切可能的方法去验证这个产品规格是否完整，是否符合现实，因为任何错误都有可能导致产品最终发行的延误，而不得不投入更多成本和时间于游戏中。
产品规格应该包含以下内容：
游戏中所需要的音效和音乐清单。
动画，3D模式，纹理以及其它图像清单，越详细越好。如果你能够列出游戏中主要角色在各个时间点的“动画”，那就做吧。如果不行，你至少需要知道需要几个动画角色。首席艺术家应该评估创造每一个内容元素所需要投入的努力。
一个执行/升级游戏引擎和内部工具的算式清单。程序员应该评估创造每个主要功能所需要投入的努力。
团队必须创造出的其它资料的清单：新闻资料，样本，屏幕截图，设计框，指南等。
一份详细的项目计划和安排表，包括生产团队的每位成员的初步任务清单，管理清单，合理的时间表，以及应变计划。
一份详细的生产预算。知道谁将效力于项目，多久，维系这个团队需要多少经费，制作人需要明确产品的预期成本，并有根据地调整请重。将昂贵而又不重要的功能往后推，兴许在遇到紧急事件时就可以自动忽略这些功能。
制作人应该投入2-4周的时间创造项目的资料清单，再花一周的时间准备初步计划。而设计师需要花费2周的时间去辅助制作人的这些投入。
图解是动画产业一种很常见的工具，而互动娱乐产业巧妙地运用了这一工具。1996年，这种工具首次被引进文件设计。从根本上说，图解是用于定义产品的外观。它包含：
角色和怪物的样式表和配色方案。在这里也许会出现关于每个角色的4-10种不同看法，而因此引导动画家和3D建模者努力维持产品的一致性；而这也允许更多美术人员能够同时致力创造一个相同角色。
主要目标，车辆和道具的样式表。
关卡和环境的地图。这里将包含关卡设计的图像。
简介和任何全动态影像/动画序列情节串联图板。
如果设计师本身就是美术人员，他便能够独立，或者与别人合作创造出图解。而没有美术专业知识的设计师也必须参与，并监督图解的创造过程，以确保游戏的外观与自己的理念相符合。
互动剧本与普通的电影剧本很像，除了不是直线型场景叙述之外，你必须编写一些独立零碎的内容，而在不同序列中发挥作用。这不仅使互动剧本变得更加复杂，同时也拉长了它的长度：2个小时的典型互动电影剧本需要6个小时的资料整理。而编写一部互动电影剧本一般却需要4-6个月的时间，而这也是取决于作者的对媒介精通程度。
据我所知，目前市场中还不存在哪些有益的工具能够更好地优化非线形写作。一些工具包只能简单地维持分支故事之类，而对于那些更加复杂的内容，你就只能够靠自己了。
一旦开始进行产品制作，更新产品规格，追踪项目进程以及重新分配任务等职责便落到制作人肩上了。而设计师的任务便只是确保他们的工作是符合要求的，并且提供给制作人足够的信息以帮助他更好地完成自己的决策。
如果你既是设计师也是制作人，那么事情变简单多了；但是对于这两个身份所要求的技巧却不同，也并非任何人可以同时胜任这两个角色。游戏工作室可以同时聘请一名优秀的设计师和制作人，让他们各自保持自我，相互协作，如此能够推动整个开发团队更好地完成任务。
除非设计师既是制作人，也是首席美术师或者主程序员，要不他根本不需要全程参与项目的整个过程，他便可以利用更多时间去设计团队的下一个项目。
游戏邦注：原文发表于日，所涉事件和数据均以当时为准。
（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）
The Game Design Process
By Francois Dominic Laramee
There is no such thing as a “standard” game design document, and for good reason. It would be insane to try to fit an interactive fiction adventure and a Tetris-like puzzle into the same mold. However, all forms of entertainment do have a certain number of characteristics in common, and over the years, I have developed a methodology which provides structure to my game design activities and help focus my work. This page describes, in a nutshell, how I start with an idea and develop it into a finished product which can be handed over to a producer and turned into a game.
Some of the issues I will talk about here I have learned the hard way (i.e., by discovering late in development that a crucial point had not been thought out well), others I have gleaned from a variety of sources and integrated into my own routine. I have had the chance to work with people who had backgrounds in film, animation, sales and marketing in addition to games, and my design has improved a great deal thanks to them. I recommend that you take the time to look at Digital Arcana’s methodology (which has strong film-making influences) and at Ben Sawyer’s Ultimate Game Developer’s Sourcebook (ISBN: 1--4) for very good discussions of the game design process.
Note that, while I write with computer game design in mind (being that this is what I usually do), many elements also apply to board, role-playing, or play-by-email design.
Game Design in Six Easy Steps
Depending on the type of game you are creating and on how you expect to get it produced, you may want to develop as many as six different documents at various stages of the creative process. If it sounds like a lot of work, then you are beginning to get my point.
All games should begin with a design treatment, i.e., a quick discussion of your product’s unique features and target audience.
Then, you should move to a preliminary design, discussing the game’s rules, content and behaviour in a purely qualitative way. This document should be circulated and discussed as widely as possible given the situation.
A final design is a re-write of the previous document, which etches the product’s features in stone.
The product specification (which only really makes sense for interactive products) details how the features adopted in the final design will be implemented.
The graphic bible determines the look and feel of the game’s characters, maps, props, etc.
The interactive screenplay, if appropriate, contains the dialogs and the storyline implemented into the product.
The game designer may or may not be qualified to write all of these documents. A product specification for a computer game, for example, requires considerable input on the part of the game’s producer, lead programmer and lead artist, while a screenplay should be crafted by a professional writer. However, as “guardian of the vision”, the designer should have final say on what goes into his product, and be involved in all aspects of the process, if only as an overseer.
A word to the wise: as long as you are still in design, it is never too late to cancel a project. Even if you have a final design document and a full screenplay in hand and are ready to turn your creation over to a producer, you have probably spent less than 10% of your total production budget. Unless everyone in the company (studio staff, sales, press relations, everyone) is convinced that the game is going to be a winner, pull the plug now. Six months from now, when you have a million dollars committed, it will be too late.
The Design Treatment
I have seen several different definitions of the “design treatment”, “design proposal”, “game outline” or “spec sheet”. Mine is more or less a middle ground between all of them.
The design treatment is a short (4-8 pages) description of what kind of product you would like to do and what you would need to do it. The document’s purposes are multiple: it helps the designer to structure the “creative spark” into something tangible that can be discussed, it establishes a framework for future design work, and it serves as a marketing tool to generate interest in the product in company executives and/or publishers.
The exact content of a design treatment may vary according to the intended audience, but not by much. Financial information may not be appropriate for a first contact with a publisher, but otherwise, everyone who you will want to submit your treatment to will need to see the following:
The game’s genre and key features. For example, a design treatment for Doom might have read: a shooting game, with a first-person perspective based on a 3D ray-casting engine.
A short description of the experience you want to give to the player. Is the game a comedy? An adrenaline thriller? A puzzle? Will it be a technology showcase, a graphic wonder or a story? Linear or not? Is it single-player or multi-player? Playable over a LAN or the internet? What are the key elements of gameplay and of the interface?
What kind of look-and-feel do you want? A realistic 3D style? Cartoons? Isometric? Lots of intricate move combinations and secret rooms, or straightforward gameplay suitable for children?
How will you structure the game: levels? Missions? Episodes? How many? How long will each be? How will you provide replay value?
What resources will you need? How many people will work on the game, for how long? Do you need senior engineers with knowledge of 3D, of network programming, of Artificial Intelligence? (Do you have them on staff, and if you don’t, can you hire them?)
Will you need an engine? New development tools (i.e., a new version of Softimage 3D)? Will you buy, or develop in-house?
Will you acquire a license to some well-established intellectual property, or create your own? The right license at the right time can mean “free” extra sales, but it can be expensive. And you must buy now a license that will hav Looney Tunes are a safe bet, the Macarena is not.
Who are your major characters/units/game pieces?
Who is your target audience? A trivia game, a Barbie clothing designer, a chess engine and a Quake killer will appeal to very different people.
What platform(s) will you develop for? Which will come first? Will you port the game to other platforms yourself, or hire sub-contractors to do it for you?
How is your team qualified to deliver this product? Industry experience and a track record make publishers relax, but even if you are relative beginners, you may have more to sell than you think. If your brother-in-law is the pit crew chief for last year’s Winston Cup winner and he agrees to consult on your NASCAR racing game, you have a winner. Same thing if you are working on a simulation of the Crusades and you can bring a historian from a local college on board.
A preliminary estimate of the budget and production schedule. At this stage, something as vague as “about 10-12 months, for a team of 6; will cost 500K to 750K with tools and fixed costs” no one expects a precise budget from a five-pager, but the reader will need to know whether this is going to be a tight-budget production or a main-eventer.
As the design treatment is your project’s business card, it should be short, factual and representative. If you have some preliminary sketch art available (i.e., your main characters and a scene or two), by all means, include it. If your game is going to be a comedy, the text should be funny. And unless you have a compelling reason to do otherwise, limit the document’s size to 4-5 pages of text, plus 2-3 pages publishers receive hundreds of these documents, so anything longer may not be read at all.
I have posted a sample design
you can find it here.
All in all, a design treatment should not require more than 100 to 150 person/ 75 if it doesn’t include any graphics. If you put more work than that into it, you are wasting your time. If you are an amateur designing for fun, then it’s no big problem, but if you work for a professional game development house, these 100-150 hours you have already put in probably cost the company 5K to 7K$ in various expenses. Since odds are that your treatment will never lead to a full design (more on that later), it’s enough. If your creative juices are still flowing, go work on another treatment.
A few words of caution
All done? Your treatment is finished, and you believe that you are sitting on a gold mine?
Good. Stay seated for a while.
Stuff your treatment in a drawer, take a deep breath, go bowling, call your aunt Maria in Portugal, and do not think about your great idea for, oh, at least two weeks. Then, if you still think it’s great, go ahead and send it out in the world.
Nothing kills so many game development companies as two-in-the-morning ideas that get implemented just because no one stopped to look them over and realize that they stunk. As an executive for a small computer game publisher, I saw tens of finished or highly advanced products that should never, ever have gone beyond the treatment stage. I remember meeting with a group of young hopefuls at the 1997 CGDC; the game they had worked on for months and months was technically sound, visually adequate and easy enough to play, but it was based on an idea so ludicrously bad that it didn’t deserve a shareware release, much less the million-dollar contract these guys were looking for. There wasn’t five minutes of gameplay in there. They wasted their time. And the worst thing is, their production values showed that t with the right design, they could have made it. I hope they will, someday.
Circulate your design treatment as widely as possible, and if it generates some interest, then (and only then) go on to a full design and a demo. Sure, you run the risk that your i it happens all the time. However, there is not a whole lot you can do about it, unless you have the funds (or the spare time) to work on a complete design and a working demo before you start looking for a publisher. And that is the second most-popular reason why development studios fail: they bet the farm on a product and then find no channel to market. If at all possible, walk in small steps.
Game Development Food Chain
The smart designer never gets too attached to his ideas. The reason why can be summarized as follows:
Out of 10 design treatments written and submitted, maybe 3 or 4 will attract enough interest to warrant a preliminary design, and 2-3, a complete design.
Out of 3 final designs, it is likely that 1 will not be produced at all, or that it’s production will be cancelled midway because of lack of funding.
Out of 10 completed computer games, 2-3 will get wide distribution, 4-6 will get more modest market penetration, and some will never be distributed at all. Publishers break contracts when they run in if you are (very) lucky, the advances they paid will allow you to survive and develop another game.
Out of the 1,200 to 1,600 PC games released every year, it is estimated that fewer than 100 break even financially, and only a few dozen really make significant money.
The situation is a bit rosier in the game console market, but you get the point: smash hits are few and far between, and not necessarily because of flawed designs. Even if you have really great ideas, they may not turn into a best-seller, because of a problem somewhere in the distribution channel. If you and your team make good livings and enjoy your work, that’s more than many of your peers are able to say.
The Preliminary Design Document
A preliminary design document can be thought of as an organized list of features. It describes what you want your product to offer in terms of gameplay, technology and look, without worrying too much about how it will be implemented. (Of course, if you know that something is impossible, save everyone useless aggravation and take it out now!)
The preliminary design is a discussion document, and it may (should?) go through several iterations. If you are writing a role-playing or board game, you can start play-testing at this stage, which will help you weed out elements that don’t work. Computer games are a little trickier, since you have no software to play with until much later in th nevertheless, discussing the design document as openly as possible, with other designers in your company and with lead artists and programmers, will serve much the same purpose.
The content of a PDD depends so heavily on the type of game being considered that it is not even worth trying to define a standard. As an example, here is a partial list of contents for a 3D PlayStation game I once co-wrote:
Technical specifications: frame rate, texture resolution and color depth, number of player characters, single and multi-player modes, camera handling, etc.
Backstory, including a storyboard for the game’s FMV intro.
Cast of characters: the player characters and their unique talents, the villain, his ships, the supporting cast, etc.
List of the game’s environments and the missions taking place in each. About 1-2 pages of general information on the unique characteristics of each mission (i.e., slippery surfaces, low visibility, types of monsters, race vs shooting, etc.)
Special ammunition, power-ups, traps, bombs, equipment.
Monsters and the statistics that define them: endurance, hit potential, type of behavior.
Lives, health, resurrections and tagging between player characters.
List of moves, including the secret and special-purpose moves appearing in specific situations.
I have seen preliminary designs ranging in size between 20 pages (for a shooter) and 60 pages (for a very detailed strategic sports simulation.)
While great care should be taken not to waste time in endless discussions, when in doubt, keep talking. Cutting design time short to save money is a sure-fire way to run a production into a wall. Preliminary design can take anywhere between 4 and 10 weeks for the designer, and 10 to 30 hours for the other people involved in brainstorming.
I have posted the revised design document (an advanced form of the preliminary design) for a pro-wrestling simulation play-by-email game here. Of course, it is a very simple game, and the document for a commercial computer game would be a lot more complicated, but the level of detail and the completeness, given the subject matter, is about right.
The Final Design Document
Discussions on the preliminary design may lead you to drop some features, scale back others, and introduce new ones. Once everyone agrees on the functionality the game is going to implement, the design document is ready to go Final.
A good final design document goes into as much detail as possible. If you are in doubt as to whether a certain bit of information should be in there, then it should. EVERYTHING that you can put in is relevant, because it forces you to think your design through before production begins, and nothing helps smooth a two-year development cycle as much as a design which leaves no (or few) crucial decisions to make midway.
There can be a certain amount of overlap between the contents of a final design and those of a product specification. If the designer happens to be a senior programmer, for example, he should write down the algorithms for some of the unique software features
after all, he thought of them, and no one else knows what behavior he wants the software to exhibit more than he does. Something that definitely should be in the FDD (although I have rarely seen it) is a list of priorities: what features the game can not live without, what would be really great to have, and what will be added at the last minute if there is time to spare (or delayed until the sequel if there is not). It is a fact of life that some
the game industry is not very strong on software engineering techniques, and even highly organized studios can get in trouble if key people leave at the wrong time. A lot of trouble can be avoided if you know in advance what should be cut if you risk not being able to deliver in time for C besides, such “risky” stuff can be scheduled for later, so that if it needs to be taken out, it won’t have wasted your team’s time and effort.
By the time the Final design document is deposed, the lead designer can have spent 150 to 400 hours on his product, or even more. Final design documents can range in size between 75 pages (for simple action games, when most of the level design is written down in a Graphic Bible or handled informally) and 200 pages or more. My personal record is around 160. Interactive movies have screenplays that occupy 300-500 pages by themselves!
All the Final design documents I have ever written are either subject to non-disclosure agreements from former employers and clients, or lost in the dawn of time. Therefore, I can not post any here. However, just to give you an idea of how much detail you should put in, here is a partial table of contents for a typical play-by-mail multi-player sports simulations:
The length and timing of seasons (how many per year, when do new leagues open their doors, etc.)
The hierarchy of leagues necessary to support thousands of teams, with promotions/demotions between leagues of different levels for strong/weak teams.
The procedure to create a new team: standard and custom team colors, creation of new players, stadium building, expansion draft.
The database of fantasy player attributes and statistics: over 40 attributes covering talent (current and potential), health,
a list of every statistic which will be compiled by the system and of the record books which will be maintained.
Scouting process: what is visible to the players (and how clearly), and what remains hidden in the database.
The reports which will be sent to players: contents, layouts, frequency.
Detailed description of the data-entry application’s interface, including a list of menus and dialog boxes.
Franchise management: hiring and firing players, recruiting minor leaguers, training, trades and trade adjudication mechanism (to prevent one-sided trades from boosting a team unduly), scouting, ticket prices, salary cap, contract offers, how to generate revenue from TV and from press releases, etc.
Game management options: what orders the player will be able to send, and how mistakes in player commands will be handled.
The manual which will be sent to players at registration.
The game’s simulator algorithms, in great detail (including the effects of weather, fatigue, injuries, etc.)
Random events: accidents, “real-life” problems influencing fantasy player performance, grudges, etc.
Game Definition Language: allows to store games in compact form and to enerate play-by-play text (or audio) files automatically.
A discussion of game pricing, marketing strategy, and prizes.
The Product Specification
Once the design itself is over, it is time to move to pre-production. In this step, the designer’s job is to work with the producer, the lead artist and the lead programmer to ensure that the project plan being developed will support his vision for the product.
This may mean sitting down with the lead artist to sketch the main characters, spending time with the lead programmer to make sure that the algorithm which manages transfer of information between non-player characters will produce the appropriate behavior (i.e., let some characters place variable levels of trust in what they hear from others), making sure that the proper development tools will be ordered at the appropriate time, etc.
The product specification itself is a blueprint for the development process. In theory, the designer could leave the team once the product spec is written, and everything would be fine. Although things are never this simple in reality, every effort should be made to ensure that the product specification is as thorough and realistic as possible, because any mistake can result in a delay of final delivery, extra costs, and extra overtime in the last months of production.
The product spec should contain the following:
A list of the sound effects and music tracks required in the game.
A list of the animations, 3D models, textures and other graphics which need to be produced, in as much detail as possible. If you can list the exact “idle animations” which will be attached to your main character at various points in the game, do it. If not, at least decide how many there will be. The lead artist should estimate the amount of effort required for each element of content.
A list of the algorithms which must be developed to implement/upgrade the game engine and in-house tools. The lead programmer should estimate the effort required for each major feature.
A list of all other materials which must be produced by the team: press materials, demos, screen shots, box art, manual, etc.
A detailed project plan and schedule, including a preliminary assignment list for each member of the production team, a list of dependencies (i.e., a Pert chart), reasonable milestones, and contingency plans.
A detailed production budget. Knowing who will work on the project for how long and what expenses must be made to equip the team, the producer is now in a position to pinpoint the expected cost of the product, and to re-arrange priorities accordingly. Very expensive subsidiary features can be assigned lower priority, so that they can be dropped (before being spent upon) in case of an emergency.
A producer should devote 2-4 weeks to building the list of materials for a project, and another week to prepare a preliminary schedule. The designer should be ready to spend the equivalent of 2 weeks of his time supporting this effort.
The Graphic Bible
The graphic bible is a common animation industry tool which the interactive entertainment world would be wise to adopt. When we started introducing graphic bibles into our design document packages and submitting them to publishers, back in 1996, they were considered a novelty and attracted quite a few compliments. Basically, a graphic bible defines the look of your product. It contains the following:
Style sheets and color schemes (i.e., pantone) for your characters and monsters. These may specify 4-10 different views of each character, which will guide animators and 3D modelers in maintaining consistency th they allow you to let more than one artist work on the same character at the same time if necessary.
Style sheets for the major objects, vehicles and props.
Maps of the levels and environments. This may include the graphical part of level design.
Background drawings.
A storyboard for the intro and for any other FMV/animation sequences in the product.
A designer who happens to be an artist can produce the graphic bible, alone or in collaboration with others. (It is a lot of work.) Designers without an artistic background should still collaborate and supervise this effort, so as to ensure that the look of the game will be consistent with their vision.
The Screenplay
An interactive screenplay is just like an ordinary movie screenplay, except that instead of a linear list of scenes, you (or the writer you hire) will have to write independent bits and pieces which can be played in a potentially large variety of sequences. Not only does this make interactive screenwriting very complicated (as it is both imperative and excruciating to ensure consistency), it also makes it long: a typical screenplay for a two-hour interactive movie contains about six hours of material. Writing an interactive movie typically requires 4 to 6 months of work, depending on the author’s level of expertise with the medium.
As far as I know, there are still no good tools on the market to facilitate non-linear writing. Some packages support simple branching stories, but that’s it. For anything more complicated than that, you are on your own.
Not very many people can write a convincing interactive screenplay, or explain how to do it. I recommend you look up Lee Sheldon’s writings on Gamasutra or his CGDC tutorials if you are inte he is one of very few masters of the genre.
During Production
Once production is under way, it will be the producer’s responsibility to update the product spec during development, to keep track of the project’s progress, re-assign duties to meet important deadlines, etc. The designer’s job will be to make sure that what gets done is satisfactory, and that the producer has all the appropriate information to make his decisions.
Of course, this is a lot easier if the designer and the producer
however, the skills required for the two positions are quite different, and not everyone can excel at both. While a good designer/producer may be the single most effective person a game studio can hire, a good team can perform just as well, assuming that both members can keep their egos in check and work collaboratively.
Unless the designer is also the producer, lead artist or lead programmer, he should not be busy full-time on a project which is in production. This should leave him with plenty of time to start working on the team’s next project!（）
CopyRight Since 2010 GamerBoom All rights reserved &&闽ICP备&号-1