网络游戏开发-基本设计

Baste

作者：老九—技术大黍
联系方式：qq群(197542621)
原文：Developing Games in Java
社交：知乎
公众号：老九学堂（新人有惊喜）
特别声明：原创不易，未经授权不得转载或抄袭，如需转载可联系笔者授权

网络游戏开发团队


网络游戏开发团队是一个怪异的团队，因为他们需要”乌托邦式的梦想 ”(pie-in-the-sky)创造力和扎实(down-to-earth)的技术相结合。这要求这个团队个体相异，但却需要产生有效性。比如A是一个有趣的人、有创造性的人，所以他可以设计出非常复杂、优雅的游戏；而B是比较无趣的，以结果为导向的人，他喜欢敲代码和讨论技术细节。二者之间有会矛盾，大多数情况下A会胜出，虽然B应该是正确的—这是一个古老的问题：理论与实践的问题！

团队中个性问题会贯穿整个开发过程，包括设计人员、编码人员、美工和网络管理员。让这两种人和谐是管理这个团队的核心，比如A类人扮演创造引擎的舵；B类扮演让A类想法从理论回到现实。这种管理工作花费的精力是巨大的；因为很少遇到脑残的开发团队，一般都很难驾驭开发团队，管理这个团队的总体步骤是：计划(planned)、排工(tasked)、编码(coded)、绘画(drawn)和测试(tested). 这些责任最终落到生产者和PM角色来实现。

理论与实践原则


下面我们主要讨论理论(设计)和实践(开发)的关系，主要是给出一些原则。

• 不要长期性的构建，也就是不试图让代码非常具有扩展性和维护性，如果开发运注意这点，那么会减少游戏的财政风险。
  
• 我们不能关注所有的服务质量，特别是MTBF (平均无故障时间)。比如服务器故障会拒绝几千成用户，而客户端故障会刺激玩家，增加混乱。
  
• 不要低估任务复杂性。移动部分会导致复杂的非线性性，MMP游戏有诸多移动部分。简而言之，MMP游戏是标准游戏的三倍，它的复杂度是标准游戏的10倍。
  
• 不要低估测试和并发处理
  
• 高估游戏初始部分内容，以及玩家消费时间
  
• 花太多的时间在游戏机制而不是游戏社会机制，这会让玩家很难查找和让玩家彼此之间的游戏，从而不能留住玩家
  
• 不要忘记CS (客服)与设计和开发一样重要，客户满意低会让游戏运行成本增加
  
• 只是认为是创建一个游戏，而不考虑游戏发生的社会场所
  
• 有信心非常重要，但是实施控制更重要：因为网络游戏是非常庞大工程，很容易缺乏监督，因此不要相信任何承诺，你只需要追踪所有事情就OK
  
• 问题不会自己解决：个性矛盾必须快速解决，不准接受差别性的纠缠行为。如果解决好，矛盾是非常有价值的。紧张性是非常好的手段，如果运用恰当的话。当然这都取决团队的成熟度。记住：苔癣不会长在滚动石头上！
  
• Everything moves. 因为游戏中所有的东西都是变动的，所以需要小心hard-code
  
• 不断对自己重复：”Tools! Tools! And more Tools”. 我们需要大量的工具和库代码。花钱开发非常炫酷的工具，来创建更有效的GUI界面，并且强迫编码人员使用这些工具。
  
• 如果我们关注游戏性(游戏机制)而不是参与机制(社区机制)，那么玩家在每周20小时游戏之后发现我们的很枯燥无聊。只有社区机制才能留住玩家
  

设计


大多数网络游戏开发过程如下：

• 一个小团队拿一个项目找发行商
  
• 发行商看一下基本的表格，以及开发时间表之后同意该项目
  
• 这个小团队开始设计文档
  
• 在设计文档还没有完成时，团队开始编码
  
• 设计文档还没有完成，但是程序员已经超过了设计人员，所以设计人员只好修改原来的设计。
  
• 大约一年了，设计文档还没有完成，但是程序员已经作出来阿尔法版本游戏世界，以及数据已经完成，所有人都参与构造行为。因为这个比设计更有趣的行为
  
• 大约一年半之后，一些人意识到大多数的游戏机制没有按照规范实现，而直接写到程序中去，但是设计文档还没有完成。这时不断有非常cool的开机画面，以及基本的”walk and talk”演示程序给高级管理人员交差。
  
• 大约21个月到30个月才会达到前三个月的Beta设计要求。此时团队意识到严重延迟计划，但是人们还在设计战斗机制(魔法、打斗、围城、贸易技巧等)，以及成千上万了对象，比如地图片、建筑物、武器、盔甲等数据库项。于是开发团队决定向管理层汇报该项什delay了—我们需要更多的美工和更多的程序员加入，以达到在36个月之内完成游戏的开发。
  
• 等到36个月交付时间时，开发团队发现根据设计要求有许多bug需要修改。为了让游戏机制运行，需要去掉以前的机制，包括数据设计。于是管理层很不高兴，但是已经投入6~8百万了，他们只能同意delay了。
  
• 大约48个月之后，花费了1千万之后终于完成原来一半功能的游戏做出来了，公司运行该游戏，虽然有1千个bug存在，以及使用不稳定的技术实现。
  

怎样解决这个问题？


在过程执行：

• 两次设计
  
• 一次建构！
  

设计的态度


又叫做建议(proposal)、态度(treatment)或者游戏轮廓(game outline)。但是，所有态度都会包含如下项：

• 游戏类型(genre) – 是奇幻型，还是射击类型
  
• 图像外观—是全3D外观，还是需要图形加速卡的？它是软件呈现方式的吗？它像塑料外观，还是动漫外观的？
  
• 界面样式—就是给玩家看的界面
  
• 引擎—付费的，还是使用免费的，还是自己写数据库—是使用免费的，还是商业数据比如Oracle或者SQL Server等
  
• 目标观众—谁使用这个游戏？技术派、温和派，还是普通大众？这个游戏需要适应多种层次的受众体吗？
  
• 客户端平台—包括开发平台和端口平台。明确是否直接针对PC网络观众，还是所有客户端接入设备：Xbox和PlayStation 2或者是手机用户。
  
• 主机平台—使用什么硬件和软件做服务器，包括物理配置、操作系统版本，以及开发环境、数据库等等
  
• 游戏剧本是授权还是原创的
  
• 游戏性—描述玩家的游戏性体验，描述关键的游戏性和玩家界面元素，可以让我们与竞争对象区分开
  
• 新手体验—对于PW而言，一个新手体验对游戏的基本的特点和游戏机功能的了解是起到了关键的作用。新手体验会帮助我们练习和引诱玩家进行游戏。
  
• 竞争—市场是否已经有相似的项目存在？我们游戏与它们之间的竞争力？制作该游戏需要投入多少money?为什么我们的游戏更好？
  
• 员工和他们的资质—团队中需要多少在游戏开发的开始阶段，游戏中的中级阶段，以及游戏开发的结束阶段？有特别需求吗？这些工作最基本的描述与任务资质要求是什么？
  
• 核心团队—谁是生产者/项目经理，谁领导服务/网络工程师、谁领导数据库设计者/数据库管理员、谁领导设计？他们需要什么样的资质来开发这个项目？
  
• 时间表—开发的初步预估时间和测试时间表。一般游戏在运行6个月只能使用到80%的功能，但是，执行总监会希望预估投资的收回时间表。所以聪明的项目经理会预估至少6个月的收入效益。
  
• 预算—初始预算一下构建这个游戏和运行它的总费用。它包括：人员工资、软硬件和测试成本，运行服务器硬件费用，带宽费用，网络维护费用；还有CS/玩家关系管理成本。
  

下面是初步设计的步骤

• 故事背景—游戏的历史，玩家为什么在这个PW中被这样虚拟
  
• 玩家界面设计
  
• 人物种族分类，特定的能力、优缺点
  
• 人物创建和成长过程
  
• 游戏世界的位置和环境，包括所有自然的和人造的地形
  
• 所有的游戏机制，包括魔法、战斗、贸易技巧，以及其它的相关的机制
  
• 图形样式指南(the art bible)
  
• 所有物品和神器列表
  
• 怪物类型和游戏中的怪物列表
  
• 固定任务，需要详细列出
  
• 人员列表—设计人员数量和美工人数，什么时候需要这些人
  
• 第一个里程碑，第一次交付的里程碑，以及什么时候交付
  
• 第一次总体开发和预算启动的时间
  

下面是第二次设计—初步的技术设计。当然技术设计必须有技术设计文档，它与游戏设计文档完成分开。技术设计文档是根据游戏设计文档来的，技术设计人员在书写设计文档之间有，必须花很多时间与游戏设计人员交流以。

初步技术设计

• 软件—操作系统环境(客户端和服务端)、编程语言和脚本语言，会用什么数据库进行编程，会用图形软件和建模软件
  
• 工具—使用哪种工具进行构建，包括游戏世界构造工具到CS和游戏内部的GM工具。
  
• 游戏服务器配置和环境—需要指出物理服务器的数量(服务器丛集)，购置这些硬件的费用，第个丛集支持多少在线用户，每台机器的物理空间(内存和磁盘大小)。
  
• 带宽—每个玩家每秒传输多少位，由此估算服务器丛集需要的带宽
  
• 任务列表—详细的编码列表，以及时间段
  
• 功能列表—所有接口和游戏机制功能，它的优先是第一的
  
• 人员列表—完成这个项目多少程序员、工程师和数据库管理员
  
• 初步切割(Fist cuts)—初步预估里程碑，交付的里程碑，以及什么时候交付；以及初步预估所有
  
• 原形列表—确定哪些元素是原形，哪些元素希望在粗略的框架中被demo出来？
  
• 技术风险列表—哪些硬件和软件元素可能成开发的瓶颈，以可能产生交付延迟和失败
  
• The CCP—整个游戏的改变过程，以及技术设计什么时候被提交、reviewed(复查)、approved(审批)和实施。
  

初步技术设计文档阶段完成之后，会有大量的技术文档产出。成千上万的被切割的小任务文档，这些文档在项目管理表格中会有几百页产出。比如使用MS的Project软件生成的项目文档，就一个角色扮演游戏来说，一般会超过200页！

最后


记得给大黍关注+点赞+收藏+评论+转发

作者：老九学堂—技术大黍

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。