作者： Radu Privantu 译者：pAnic 2005年5月11日 原文链接：http://www.devmaster.net/articles/building-mmorpg/ 译者序：这是一篇讲解如何开发一款MMORPG的入门文章，作者本人也是一款游戏的开发者，文中的内容源于实践，有很高的参考价值。很多人都想拥有自己的游戏，这篇文章对那些想自己开发游戏的人来说可能是一纸福音，也可能是一盆冷水。无论如何，开发游戏都不是一件简单的事情。 以下是翻译正文：

[/td]

文章的中心是如何起步开发你自己的 大型多人在线角色扮演游戏( 原文：Massive Multiplayer Online Role Playing Games) (MMORPG)(译者注：俗称：网络游戏，网游)。 针对的读者是经验和资源有限的开发者。 读完文章之后，你应该懂得如何起步， 还有一些关于什么是应该做的和不应该做的忠告。第一步是评估你的能力和资源。你必须对自己诚实，因为做你力不从心的事情会浪费你的时间并让你心灰意冷。 第一步：评估你的能力必须的技能: 懂至少一种编程语言。 迄今为止， C++因为性能和效率的优越性成为游戏开发者的首选。 Visual Basic, Java 或者 C# 可能也是不错的选择。 熟悉一种图形库。通常的选择是SDL, OpenGL, 或者DX/D3D。(译者注：网上也有很多免费/付费引擎下载和出售) 选择一种网络通讯库。 你可以从WinSock, SDL_net, 或DirectPlay中选择。(译者注：很多人喜欢开发自己独特的网络库，这并不复杂，似乎ACE也是一种选择) 对游戏开发有大体的经验。 例如，事件循环， 多线程， GUI 设计，等等。 强烈推荐的技能: C/S结构通讯。 多平台开发。 你可能希望设计一个MMORPG, 尤其是服务器能运行在多种操作系统。为此，我推荐使用SDL, OpenGL 和SDL_net。 网站开发。如果你想让用户通过网站查看玩家统计，服务器信息和其他信息，这是必须的。(译者注：其实网站可以交给其他人开发，如果有必要的话)。 安全管理。 你当然不想因为有人攻击你的服务器而浪费时间！ 团队组织能力。 你需要一个你能成功领导和管理的团队。 第二步：初步规划我注意到很多人在不同的论坛发帖子寻找团队开发MMORPG。他们中的大部分是这样：“我们成立了一个公司/游戏工作室，需要3个美工，两个程序，1个音乐制作，等等。为了创新，不要参考过去的MMORPG，你有全部的自由用来创造你想要的世界，等等。 我们会在项目完成并赚到钱的时候付给你酬劳，等等”。 不幸的是，以现有的技术和带宽，你无法拥有一个动态的世界。 朝向无法到达的目标前进只会导致失败。正确的做法是拿出一些小规模的，功能性强的，可扩展的设计和构架。 基本软件构架首先，尝试创建一个简单的C/S模型，有如下功能： 创建一个新角色 保存那个角色(服务器端) 用那个角色登陆 能够和其他人交谈 能在3D空间游览 保存角色看起来简单，其实不然。 例如，有两种方式保存角色：使用数据库服务或者使用文件。两者有各自的优缺点： 数据库 文件 优点 添加新域或者修改现有的都很简单。 更新玩家统计数据非常简单(从游戏外)。 你可以通过SQL查询方便的获取不同种类的统计结果。 无需自行完成I/O操作，数据库会替你做好。 易于更新/恢复。 高速操作(读/写)。 实现简单。 无需额外的库。 不依赖数据库服务器。因此你不必担心数据库升级或安全问题。 缺点 容易出错。 例如，做一个更新查询的时候遗漏了'where'子句。会导致惨痛的损失，尤其是你没有备份的时候。 数据库会比打开/写入一个玩家档案文件慢。你查询一些数据的时候会耗费几个毫秒，尤其是大量玩家同时登入/登出的时候。 需要额外的代码进行游戏和数据库间的数据转换。 需要操作数据库和SQL的经验。并且需要一个程序和数据库之间的接口库。 如果因为某些原因数据库文件损坏，那算你倒霉，你可能会丢失所有的玩家数据(尤其是短期内没有备份的时候)。 很难添加新的域，除非一开始就很小心的设计了文件的格式/结构。 没法做全体玩家的查询。(这可以通过每天晚上用程序把重要字段添加进一个数据库间接实现)。 如果你想更新/检查玩家状态，你必须额外写代码。 更新和还原比较复杂。 现在你决定了如何存储角色，你还得选择C/S通讯的网络协议：TCP 还是 UDP？,我们都知道TCP速度慢，但是更准确，并且需要额外带宽。我实际使用TCP并没有遇到什么问题。 如果你有充足的带宽，TCP是个好选择，至少对初学者是这样。  UDP 会很麻烦，尤其是对新手。 记住，游戏或引擎的初步测试会在你的局域网进行，所有的包都会按顺序依次抵达。在Internet上无法保证这一点。虽然包会按顺序到达，但是有时候会丢包，这通常是个麻烦事。 当然，你可以设计你的协议使得C/S能够从丢包中恢复。但这对初学者来说很痛苦，不值得推荐。 第三步：选择数据传输协议又是看起来很简单，其实不然。你不能只是发送'\0'结尾的串。因为你需要一个通用的协议，能同时适用字符串和二进制数据。用0(或其他字符)做结束符是不明智的，因为那个结束符可能是你要发送的数据的一部分。此外，如果你发送20字节，然后再20字节，服务器极有可能收不到两个20字节的包。取而代之的是，它会一次性收到40字节，这是为了避免浪费带宽在不必要的头上。 而且，你可以发送1KB的包，但服务器会以两个小包的形式收到它。所以你必须知道哪里是一个包的开始，哪里是结束。在 “永恒大陆”(译者注：原文： Eternal Lands，本文的作者正在开发的一款MMORPG)中，我们用如下的方法： Offset 0: 1 字节 表示传输的命令。 Offset 1: 2 字节，传输的数据长度。 Offset 3: 变长，消息内容。 这种方法有一致的优点：所有的数据传输有统一的标准。缺点是有些命令有固定已知的长度，浪费了一些带宽。以后我们会改成混合的方法。 下一件事是决定服务器模型： “非阻塞soket,不使用线程”，或者“阻塞soket，使用线程”。两种方法(使用线程 vs 不使用线程)各有优缺点。 线程: 服务器响应会更加平滑，因为如果一个玩家需要大量时间(例如从数据库中读取数据)，这会在它自己的线程中完成，不会影响其他人。(译者注：也许作者的意思是每个玩家都有独立的线程，但这对MMORPG不太现实) 难以恰当的实现和调试：你可能需要大量同步，并且一个小疏忽就会导致灾难性的后果( 服务器瘫痪，物品复制，等等)。 可以利用多处理器。 无线程: 实现和调试更简单。 响应速度慢。 在我的公司，我们使用无线程的方法，因为我没有足够的资源和人力处理线程模式。 第四步：客户端你打算做2D还是3D游戏？有些人认为2D游戏做起来简单。我两者都做过，并且我倾向于3D游戏更简单。容我解释。 2D下，你通常有一个帧缓冲，也就是一个巨大的象素点数组。象素点的格式会因显卡的不同而不同。 有些是RGB模式，另一些是BGR模式，等等。每种颜色的bit数也会不同。只有在16bpp模式才有这个问题。8-bit和24-bit模式简单一些，但有他们各自的问题(8-bit颜色数太少(256)，而24-bit速度更慢)。同时，你需要制作你的精灵动画程序，不得不自己排序所有对象，以便他们以正确的顺序绘制。 当然，你可以用OpenGL或者D3D制作2D游戏，但通常这并不值得。并不是所有人都有3D加速卡，所以使用3D库开发2D游戏一般会带给你两者的缺点：不是所有人都能玩，你也不能旋转摄像机，拥有漂亮的阴影，和3D游戏炫目的效果。(译者注，目前绝大部分显卡都支持565的16bpp格式，这个也成为目前16位色的业界通用格式，有不少文章和代码都是讲述这一格式下图像处理的，尤其是使用MMX技术) 3D的途径，正如我所说，更简单。但是需要一些数学(尤其是三角)的知识。现代的图形库很强大，免费提供了基本的操作(你不需要从后到前排列对象，改变物体的色彩和/或帖图都十分简单，对象的光照会按照光源和它的位置计算(只要你为它们计算了法向量)，还有更多)。并且。3D给了你的创作和运动更多的自由度，缺点就是不是所有人都能玩你的游戏(没有3D卡的人数可能会让你大吃一惊的)，并且，预渲染的图片总是比实时渲染的更漂亮。(译者注：市面上想买不支持3D的显卡目前很困难，只是高性能的3D卡价格也不低) 第五步：安全显然，不能相信用户。任何时候都不能假设用户无法破解你精巧的加密算法(如果你使用了的话)或者协议，用户发送的任何信息都要通过验证。极有可能，在你的服务器上，你有固定的缓冲区。例如，通常有一个小(可能是4k)缓冲区用来接收数据(从soket)。恶意用户会发送超长数据。如果不检查，这会导致缓冲区溢出，引起服务器瘫痪，或者更坏的，这个用户可以hack你的服务器，执行非法代码。每个单独的消息都必须检查：缓冲区是否溢出，数据是否合法(例如用户发送“进入那扇门”，即使门在地图的另一端，或者“使用治疗药水”尽管用户没有那种药水，等等)。 我再次强调，验证所有数据非常重要。一旦有非法数据，把它和用户名，IP，时间和日期，和非法的原因记录下来。偶尔检查一下那个记录。如果你发现少量的非法数据，并且来自于大量用户，这通常是客户端的bug或者网络问题。然而，如果你发现从一个用户或者IP发现大量非法数据，这是明显的迹象表明有人正在欺骗服务器，试图hack服务器，或者运行宏/脚本。同时，决不要在客户端存储数据。客户端应该从服务器接收数据。换句话说，不能发送这样的消息“OK，这是我得物品列表”或者“我的力量是10，魔法是200，生命值是2000/2000”。 而且，客户端不应收到它不需要的数据。例如：客户端不应该知道其他玩家的位置，除非他们在附近。 这是常识，给每个人发送所有玩家会占用大量带宽，并且有些玩家会破解客户端从中获取不公平的利益(像在地图上显示特定玩家的位置)(译者注：就像传奇的免蜡烛外挂)。所有这些似乎都是常识，但，再次，你会惊奇的发现有多少人不知道这些我们认为的常识。 另一个要考虑的问题，当涉及到安全：玩家走动的速度必须在服务器计算，而不是客户端。(译者注：这是重要的原则，但是会耗费大量服务器资源。魔兽世界没有这样做，它采用类似其他玩家揭发的形式掩盖这个事实，导致加速外挂可以用，但是在有其他玩家的时候会暴露)。服务器应该跟踪时间(以ms为单位)当客户最后一次移动的时候，并且，移动的请求如果比通常的极限更快到来，这个请求应该被抛弃。不要记录这类虚假请求，因为这可能是因为网络延迟(也就是玩家延迟，过去的10秒内发送的数据同时到达了)。 检查距离。如果一个玩家试图和100亿公里以外的玩家交易(或者甚至在另一张地图上)，记录下来。如果一个玩家试图查看，或者使用一个遥远的地图对象，记录它。小心假的ID。例如，正常情况下每个玩家都会分配一个ID(ID在登陆的时候分配，可以是持久的(唯一ID)。 如果ID在玩家登陆的时候赋予9或怪物被创建的时候)，显然可以用玩家数组(保存玩家)的位置(索引)作为ID。 所以第一个登陆的玩家ID是0，第二个是1，依此类推。现在，通常你会有一个限制，比如说2000个索引在玩家列表里。所以如果一个客户端发送一条命令类似：“查看ID200000的角色”，这会使服务器当机，如果没有防备的话，因为服务器会访问非法的内存区域。所以，一定要检查，就像这样： "if actor id<0 or if actor id> max players 然后记录非法操作并且断开玩家。如果你使用C或者C++，注意或者定义索引为'unsigned int' 并且检查上限，或因为某些原因定义为int(int,默认是有符号的)，记得检查 <0 and >max 。没有做这些会严重挫伤你和其他用户。类似的，要检查超出地图坐标。如果你的服务器有某种寻路算法，并且客户端通过点击地面来移动，确保他们不要点击在地图外部。 第六步：获得一个团队制作游戏需要大量的工作(除非是个Pong and Tetris游戏)。尤其是MMORPG。你无法单靠自己。理论上，一个完整的团队组成是这样： 至少3 个程序员： 1 个做服务器，两个客户端(或者一个客户端，一个负责工具，例如美术插件，世界编辑器，等等)。有6个程序员是最好的，更多就没必要了。这取决于你的领导能力。最少一个美工，2到3个更合适。如果这是个3D游戏，你需要一个3D美工，一个2D美工(制作帖图，界面，等等)，一个动画师，和一个美术部负责人。美术部应该由有经验的人组织和安排，除非你就是个艺术家。, 少数世界构建者:创建所有地图是个漫长的过程， 并且直接关系到游戏的成败。再次，你需要一个世界构建部的负责人。你的世界需要协调一致，所以不能只有一个意气用事的人。 一个 网站管理员是必须的，除非你精通网站设计，并且愿意花时间做网站。音效和音乐不是必须的，但是有音效和音乐的游戏比没有的会更吸引人。 一个游戏经济系统 设计师.。你也许觉得那很简单，可以自己来做，但事实上那是最复杂的工作之一。如果经济系统设计不良(比如物品没有平衡，资源在地图上随意放置，等等。)玩家会觉得无聊并且退出游戏。我们早期的进展存在很大的问题，尤其是因为经济系统主要是由我(一个程序员)设计的，它没有被恰当的计划。 于是，我们花费了两个月来重新思考和建立一整个新的经济系统。这需要一次完全的物品清除。我告诉你，玩家会很不乐意你删除他们的物品。幸运的是，大部分玩家赞同这个想法，但是这么多小时的争论，妥协，解释和时间的浪费还是让我们丧气。以后会更多。 如前所说，你需要一个10~15人的团队，不包括协调员和管理者。这10~15人必须是有经验的。如果都是新手就不值得，因为你需要花大量时间解释要做什么，怎样做，为什么他现在的做法不好，等等。 一开始就凑齐10~15人几乎是不可能的。不管你在不同的论坛发多少帖，你也无法找到合适的团队成员。毕竟，如果一个人在他/她的领域得心应手，为什么在你无法拿出任何东西的时候他/她要加入你的团队？很多人有远大的想法，但是实现它们需要大量时间和努力，所以他们宁可从事自己的工作也不会加入你。那如果你需要10~15人，但是无法让他们加入你的团队，你如何才能制作一款MMORPG呢？ 好，事实上，你一开始不需要所有人都到位。你真正需要的是一个程序员和一个美工。如果你是个程序员，只要找个美工就可以了。请求懂美术的朋友帮忙，花钱请大学生/朋友做一些美术或者其他工作。 现在你有了一个美工，你期待的游戏的样子，现在可以开始实现了。一旦你有了可以运行的C/S引擎，一些用来展示的截图(或者更好，玩家可以登陆你的世界，四处走动，聊天)，更多的人会愿意加入你的团队。更恰当的是，除非你使用独有的技术，否则你的客户端可以开源。许多程序员会加入(作为志愿者)一个开源工程而不是非开源项目。而服务器不应该开源(除非你打算做一款完全开源的MMORPG)。 其他一些忠告：在有东西可展示之前，不要夸大你的游戏。最惹人烦的事情之一就是一个新手发一个“需要帮助”的请求，并且解释这个游戏到底有多酷，最后要求一个巨大的团队加入他的游戏制作。一旦你拥有了网站广告(通常是在一个免费主机)，你会看到一个吸引人的导航条，包含“下载”，“截图”，“ 原画”(译者注，原文：Concept art，概念艺术，在游戏应该指美工的原始设计)，“论坛”。你点击下载链接，然后看到美妙的“建设中”页面(或者更糟糕，一个404错误)。然后你点击截图，得到同样的结果。如果你没有东西给人下载，就不要放下载链接。如果没有截图展示，不要放截图链接。然而更好的是，在工程进展10%(程序和美工)之前，不要浪费时间在网站上。 第七步：打破某些神话 你无法制作MMORPG, 只有大公司才可以。 我不同意。虽然制作一款像魔兽世界(World of Warcraft)，无尽任务2(Ever Quest 2)，亚瑟王的召唤2(Asheron's Call 2)，血统2(Lineage 2)，和其他一些游戏对一个小型的自发团队是不可能的，但是做一款像样的游戏还是可以的，只要你有经验，动机，和时间。,你需要1000小时的编程来制作一个可运行的测试版，大概10~15k小时完成几乎完整的客户端和服务器。但是作为团队领导者，你不能只编程。保持团队团结，解决争执，维护公共关系(PR)，技术支持，架设服务器，惩罚捣乱分子，自由讨论，等等都是你的职责。你可能会被非编程的任务淹没。你很可能需要上班/上学，这减少了你花费在项目上的时间。我们很幸运，没有成员离开团队，但是如果这种事情发生，那的确是大问题。假设你的美工半途离开。或者更糟糕，他/她没有给你使用他/她作品的许可。当然这可以通过和他们签订合同来解决，但找另外一个美工仍然很麻烦。一个工程中有两种不同的美术风格也是问题。 需要大笔金钱(通常 4-6 位数) 用来架设一个 MMORPG 服务器. 当然，这不是真的。我见过专业服务器，1000GB/月，不到100美元/月(2~300美元的初装费)。除非你的数据传输协议设计非常不合理，1000GB/月对一个1000玩家在线(平均)的服务器来说足够了。当然，你还需要另一个服务器做网站和客户端下载(客户端下载会占用大量流量，当游戏变得流行的时候)。我们的客户端有22MB，有时候会有400GB/月的传输量。而我们还没有很流行(仍然)。另一件事，我们不需要另一台专用服务器开启这个工程。ADSL/cable服务器可以胜任，直到你的同时在线人数达到20~30。然后要么找一个友好的主机公司，用广告交换免费主机，要么就只能自己掏腰包了。   制作一个MMORPG很有趣。 这不是真的。你可能认为每个人都会赏识你，玩家会支持你，你标新立异，并且，当然，很多玩家都玩你的游戏。玩家可能让人讨厌。即使是完全免费的游戏，他们也能找到理由抱怨。更糟糕的是人们经常会抱怨矛盾的事。战士会抱怨升级太难，商人会对战士掠夺大量钱财很失望。如果你减少怪物掉落物品，有些玩家就会威胁说要退出游戏。如果你增加，同样的一群人会不满新手能更简单赚钱的事实。 真是左右为难。改革和改进是必须的。如果你决定改变某些东西，例如给加工物品增加挑战性，有些人会说太难了。如果你不做，他们又会说太简单无味。你会发现满意的玩家通常不会说什么并且感到满意，同时破坏者会怨声载道。 MMORPG的经济比单机版难以平衡的多。在单机游戏，你可以逐渐改良武器，只要玩家进展，他/她可以使用更好的装备，丢弃(或者卖掉)旧的。另一方面，在多人游戏里，这种观点不成立，因为每个人都试图得到最好的武器，而跳过低等级武器。大部分玩家宁可空手省钱，直到他们能买游戏中最好的武器。经济系统设计要参考相关的文章。 迄今为止我列举的所有事情，加上额外的工作和挑战，足以让你在决定涉足这个工程之前三思而行。你必须知道你的决定意味着什么。 总结希望这篇文章能给你足够的知识。我的下一篇文章将介绍如何建立一个经济系统(更明确的，要避免哪些错误)，还有一些调试服务器和客户端的信息。 关于作者这篇文章作者是 Radu Privantu, 永恒大陆(Eternal Lands) www.eternal-lands.com的主程序和项目规划, 永恒大陆是一款免费，客户端开源的MMORPG。作者可以通过 chaos_rift at yahoo dot com 联系。

我不得不承认，我的能力不足以写出一个100%不会宕机的游戏服务器程序，这也不能全怪我的能力太弱，谁让咱国内网游玩家数量庞大，哪个游戏刚上线时没有挤的爆满过？还有些或是猎奇，或是谋私的个人和组织，在制造着千奇百怪，匪夷所思的数据包及操作流程来试探你的服务器。这些都曾是我在服务器宕机后向老板开脱的理由。

 

当WOW终于来到中国时，我一边欣喜着终于可以在艾泽拉斯的大陆上自由翱翔，一边却咒骂着9C的破服务器，动不动就宕机。当然，身为游戏程序设计师的我明知道，这大部分的错误都不应归罪于代理商9C，但是，谁让blizzard是我心目中的神，谁又让WOW成为我游戏制作的教科书呢。好吧，我知道上面这段极力追捧blizzard跟WOW的话可能早已让你恶心连连，不堪入目了，对不起，忘了这一节，让我们继续。

 

 

服务器宕机后都发生了些什么？

 

显然的，宕机后玩家会骂，就像我在玩WOW时那样，骂游戏公司，骂老板，骂GM。非常抱歉，我们可爱的玩家们似乎并不清楚，这个时候最该骂的其实是我们这些程序员们。长久的遗忘被我们当成了包容，以至于游戏程序员在公司里都养成了趾高气扬，不可一世的坏毛病：看吧，策划们，你们做的太烂了，数值不平衡，玩法没新意，只会照抄WOW跟大菠萝，能怪玩家骂你们吗？运营不得力，买服务器的钱不知道去了哪里，游戏里卡的要死，偶尔办个活动还没半点吸引力，能不被玩家骂你是无良运营商吗？GM们能不天天被骂家指着骂吗？……呃，又扯远了。

 

赶紧先把服务器重启吧。老板正站在你的身后，一脸愁容，虽然暂时还没有发作，但看得出来：老板很生气，后果很严重！

玩家们很快又回来了，不得不为玩家们的毅力和执着精神而感动，更为自己的错误而愧疚，凌晨时分，服务器启了又宕，宕了又启，如此反复，可热情的玩家们依然陪着我在折腾。哦，当年安其拉开门的时候，我也曾这样折腾过。

这个时候不是你一个人在战斗。GM们在忙碌地处理着玩家不断打来的投诉电话：刚买的装备在宕机后消失了；花光了身上所有材料合成的武器回档了，但材料却没有还给我……数据库维护组的同事们也在紧张的恢复着数据，尽可能的将玩家的损失减到最少。

 

真是一件令人沮丧的事。

 

 

真的该试着做点什么了吧！

 

既然我们非常不愿意看到宕机的情况发生，但又无法100%保证写出来的服务器程序一定不会出错，那我们就在当机发生后的抢救措施上花点功夫，让玩家的损失不至于太大，也让我们的维护人员少些压力吧。

 

一个最简单也最有效的做法是为每一台服务器都配备物理冗余，同步更新冗余服务器上的状态，当宕机发生时，立即将处理切换到后备服务器上。只是，物理冗余的代价太大，从成本方面考虑，老板可能不大愿意点头。

 

既然不能做硬冗余，那就再来考虑软的吧。

如果只是简单的启动冗余进程，其实是换汤不换药的做法。原来能跑1000人的服务器，由于同时运行了两个相同的进程，使得CPU和内存开销都翻了倍，结果是只能跑500人了。还是要加服务器。

 

看来只能更深一层，从架构设计上来动手了。

假设我们的游戏世界是由多个独立场景构成的，那么在实现上我们可以让这些场景在进程上也独立，这样做的好处是可以使得一个场景的宕机不会影响到其他场景的正常运行。如果我们的游戏世界物理上没有分隔，是一个无缝的大世界，我们也可以人为的将其分成多个独立区域，所需要做的额外工作是处理好那些站在区域边界附近的对象。事实上，现在的无缝大世界也都是这样实现的。

 

有了这样一个前提，我们再来看这个已宕掉的场景该如何处理。

还是老办法，赶紧先把它拉起来吧。一个具体可行的方案是，由场景管理器，或者你也有可能叫它世界服务器，来监视各个场景进程的运行状态，当某个场景异常失去联系时，由管理器来将其重新启动。这里需要再花点心思的是，如何让玩家数据正常地发送到新启动的场景进程中，而且这个过程对于客户端来说是透明的。

 

这个方案听起来似乎不错，只是，如果宕掉的是场景管理器进程，那该怎么办呢？

按照前面的描述，场景管理器可以看作是整个游戏世界的中心，它以一个指挥者的身份维护着游戏世界的有序运行，所以它的宕机对整个游戏世界的影响也将会是巨大的。

有没有什么办法能够使得场景管理器进程再次启动后能够恢复先前的状态呢？

我们可以为管理器和场景进程定义一套协议，使得管理器不仅能够创建并恢复一个已有场景，而且场景管理器还能通过现有的场景进程数据恢复出自己。

一个理论上可行的方案是，场景管理器与场景进程间保持TCP长连接，并以一定频率进行心跳联系，任意一方发现联系中断或长时间未收到心跳包后都会立即做出处理。

如果是管理器发现场景进程失去联系，那就启动新的场景，如前面所描述的那样。如果是场景进程发现管理器失去联系，那就立即启动重连过程，直接再次连接上管理器，然后立即将自己当前的状态和负责的场景ID报告给管理器。管理器通过这些上报的数据就能恢复出游戏世界内的场景对应关系表，也就是恢复出了自己原来的状态。

 

进程是恢复出来了，可我们忘了最重要的内容：数据。当场景进程宕机后，上面保存的玩家属性数据也随之丢失了，虽然我们能够再次将这个场景创建出来，并把原来在这个场景内的客户端数据重新定向过来，但这些客户端对应的玩家对象的数据却没有了，游戏仍然无法继续。

 

也许我们可以再做一点修改，把场景内的玩家数据分离出来，保存到一个独立的进程上，比如，我们可以把这个进程叫做数据服务器，或者数据中心之类的。一个隐含的要求是，数据服务器的逻辑实现非常简单，简单到你可以认为它是绝对安全的，不会宕机。所以，保存在这里的玩家数据也就是绝对安全的。

 

让我们在这个问题上稍微再深入一点。

场景进程上每次执行玩家的游戏逻辑时都要异步地到数据服务器上来存取数据，这个开销可能太大，而且会使得一些游戏逻辑的实现变的很复杂，那么，把一些会频繁使用到的数据直接保存在场景进程中，当数据发生改变时同步更新到数据服务器上，这样可能会比较容易接受。

 

 

老板全都满意了吗？

 

从理论上来说，我们已经解决了场景进程宕机和管理器宕机后的状态恢复问题，并且在场景恢复后也不会因为丢失了玩家数据而无法继续进行游戏，而且，只要处理得当，这个过程对客户端来说可以是完全透明的，也就是玩家根本不知道服务器上有个进程意外结束，我们做了这么多的工作来将它恢复了。

 

事实上，这个过程的透明也是必须的，我们并不需要嚷嚷着告诉我们的用户，也就是玩家，我们做了多少多少事情来让你玩的更顺畅，又花了多少多少精力来解决因为服务器宕机而引起的麻烦，对于最终的用户来说，他只需要享受最好的服务。闲话少说，让我们继续。

 

真的已经完全解决了所有问题吗？

想象这样一个场景：我带着几个刚刚降临到艾泽拉斯大陆的伙伴冲向了艾尔文森林，去开荒霍格！正在霍格只剩下一丝血的时候，服务器稍稍卡了一下，等我缓过神来，面前的霍格骤然消失，地上也不见尸体。找了一圈，它正在出生点摇头晃脑，也在四处张望，但头顶上的血条分明是，满血！

怎么回事？

处理这张地图的场景进程意外结束了，服务器的宕机处理机制很快地恢复了这个场景进程，并且把我的客户端数据重新定向到了新场景。只是，事情并不是一切都完美。因为这个场景是完全重新创建的，这意味着所有的怪物也是重新创建并被摆放到了初始位置，所以，只剩下一丝血的霍格碰上了好运气……

 

类似的还有，正在护送NPC返回营地，在稍微停顿了一会儿之后，NPC又重新回到了原来的地方，等等。

 

虽然这比起最初的“客户端被迫断开连接，服务器端数据丢失”要进步了许多，但会给我工资的老板仍然可能不太满意，他希望，霍格应该还在我的面前，而且只有一丝血，那个跟着我的NPC也应该还在我旁边……

 

我要是不能说服老板，这是“根本不可能完成的任务！”，那也就只能坐下来再试一试。

也许，可以考虑将所有对象的数据都保存到数据服务器上，当然，这要求每个怪物都跟玩家一样，有一个唯一ID，这一点实现起来可能会有些麻烦。

再不然，为对象提供一个从已有的内存数据构造的方法，这样便可以使用共享内存来保存现场数据，再从共享内存中恢复出原来的对象。理论上来说，这个方法是可行的，只是，这三十多个字的文字描述要用C++来实现也可能将会是一项极大的挑战，所以，这也仅只是可供参考的一个尝试方案。

 

 

我想，我们走的够远了

 

让我们先暂停一会儿，回过头来看一看最初的目的。其实我们想要的只是尽可能的让服务器进程不要宕机，如果实在是没有办法，就尽可能的让宕机后的玩家损失比较小，不需要我们做大量的工作去做善后处理。

很简单的需求，似乎我们纠缠的有些过头了。

 

写出能够稳定运行的程序是对程序员的最基本要求，如果一个程序连稳定性都不具备，那根本都不用再去考虑功能啊、扩展啊等其他标准了。但是，正如我最开始所说的，没有一个人能够100%保证他写出来的服务器程序是绝对不会崩溃的。我们所能要求的只是尽可能的仔细，尽可能的多一些必要的测试，离安全尽可能的更近一步。

 

剩下的就是在宕机后如何降低损失的问题了。

对于一般的MMOG来说，玩家在进入游戏时会从数据库中将该玩家的所有相关数据读到内存，以便快速的进行游戏逻辑的处理，而在玩家下线时再将数据的改动存回数据库。

显然的，当服务器进程出现意外宕机时，内存中所有的数据都丢失了，这也就造成了玩家数据的回档，而且玩家在游戏中呆的时间越长，回档的损失就越大。所以，一个被广泛采用的做法是为玩家数据实现一种定时存盘的机制，就像现在大多数的单机游戏一样，AutoSave。比如，每5分钟自动为玩家存一次盘，这样就可以使得回档的最大损失控制在5分钟以内。

另外，对于一些重要数据的变动，比如玩家花大量游戏货币购买了一件贵重的武器装备，这时可将玩家数据立即做一次存盘操作，这也将有效的减少玩家的重大损失。

 

听起来这是一项不错的技术，在意外宕机的时候最多只回档5分钟，而且还没有贵重物品的损失，玩家应该是可以接受的吧。

 

 

我已经听到了数据库维护员的咆哮

 

“数据库已经快要崩溃了，你就不能让每秒需要执行的SQL语句少一点吗？”

“呃………”

 

我一直以为我们的数据库非常强大，可以处理任何的数据，唯一的缺点就是查询速度比直接内存读取要慢很多。所以我使用了异步数据存取的方法，并且开启了多个数据库操作线程来并行的执行我的请求，运行的效果看起来还不错。

 

也许，我应该来算一算，每秒种究竟丢了多少条操作请求给数据库。

 

请允许我再自私一回，我已经很久没有提到WOW了……

大概可信的数字是，WOW一组服务器的玩家数量在3000到5000之间，去掉最大的数，再去掉最小的数，最后的平均值是，4000吧，就算4000。

4000人在线，假设也是每5分钟定时存盘一次，再假设所有玩家的存盘时间是平均分布的。这样算下来，每秒种就会有67个玩家向数据库发出存盘请求操作。

 

才67个，数据库维护组的同事就跟我说不堪重负了？笑话，这数据库服务器是谁买的？

先别急，67是玩家数，但是每个玩家的存盘请求不会只有一条SQL语句。

 

虽然每个游戏的内容都各有差别，但是一款MMOG需要存入数据库的数据少不了会有技能、物品、任务、宠物、好友、公会这些东西。取决于游戏的类型差异，每个游戏都会有自己的存盘方式，比如我可能会把所有的技能ID作为一条数据来存储，但是我也有可能把每个技能作为一条单独的记录来存储，这样可以方便对技能附加数据的扩展，等等。

 

但是，游戏中的物品存储大概都是相同的，只能是一件(组)物品作为一条记录来存储。

而且，可以说游戏中存储量最大的就是物品数据。算一算你的角色背包有多大，50格？ 100格？还是200格？不要忘了银行、摆摊位、装备拦、宠物背包和邮箱这些地方也能放物品。并且，在游戏进行过程中，玩家背包中物品数据的变动也是相当的频繁，不断的有药品被用掉，不断地又有些小玩意儿被捡起来，不久后，它们又被卖给了NPC。

 

虽然你可以使用一些巧妙的比较算法来过滤掉那些实际上没有发生变动的物品更新，另外也不是所有的玩家物品数据变动都很频繁，但在实际运营中，尤其是当玩家的背包格数都很多的时候，物品数据的存盘的确会成为一个很大的问题。

 

除了物品，还有玩家的基本属性存盘，社会关系存盘等等，再加上全局公共数据的存盘，如公会数据，拍卖行物品数据，如果老板也要我在游戏中开上一家拍卖行的话。

 

这么一算下来，似乎是有些多了。

 

 

再一次的挑战

 

具体的数字将取决于游戏的类型和设计的数据表结构。

而数据库服务器能承担的每秒查询数则取决于数据库服务器的软硬件配置情况。

但是一般来说，数据库维护人员可能会告诉我，当每秒执行的SQL语句数达到1000条时，数据库服务器将会感受到明显的压力，我可能也会看到数据库执行队列中的请求数一直在增长，也可能会看到数据库服务器间歇性地拒绝响应，等等。

 

看起来我们又一次的面对到了巨大的打冷战。

这个问题的起因是什么？我们不希望服务器进程宕机时回档太久，所以我们增加了一个玩家数据定时存盘的机制，结果却导致了数据库请求的骤然增多。

那再退回到这个起点处，将定时存盘的时间间隔延长点，比如10分钟才存一次？数据库的压力会有缓解，但最初的问题却又会有所暴露。真是个两难的问题。

 

既想要玩家数据存盘间隔时间短一点，又不想给数据库造成的压力太大。

同样的需求似乎出现过很多回了：在中间加一层代理做缓冲。我们姑且称这一层代理为数据库代理服务器，它所要完成的工作是从场景进程收集玩家的定时存盘请求数据，再以一个低一点的频率写入到数据库。

 

听起来这又像是一个换汤不换药的做法，写入数据库的时间间隔还是变长了。但实际上在前面我们就曾经描述过，如果服务器进程不会出现意外的宕机，玩家数据只需要在他上线时读取，在他下线时写入即可，中间添加的这些定时存盘过程完全只是为了防范宕机回档所造成的巨大损失。

 

因为这个中间代理层的加入，我们把场景进程宕机的隐患与数据丢失的后果隔离开来了，现在即使场景进程宕机，数据还在数据库代理服务器上，当然这里又隐含了一个条件：数据库代理服务器需要足够稳定，不会在场景进程之前先宕掉。事实上，因为这个代理进程的工作是，我们完全有理由相信，这个进程是非常稳定的，那样的话，多久时间才把缓存的数据真正写入数据库，就看你自己的喜好了。

 

 

该结束了吧

 

是否有些似曾相识的感觉？

没错，前面我们曾经描述过一个数据服务器，也是这样说的。

 

所以，数据服务器，数据库代理服务器可以合并到一起，来共同保证数据的安全。

再加上场景进程与管理器进程的恢复协议，让服务器的重启对玩家保持透明。

看起来这个晚上可以睡个安稳觉。

Author: Fox
原文地址：http://www.cppblog.com/Fox/archive/2007/12/16/game_world_architecture.html

一个MMORPG（Massively Multiplayer Online Role Playing Game）的架构包含客户端和服务器两部分。客户端主要涉及计算机图形学、物理学、多媒体技术等，服务器主要涉及网络通信技术、数据库技术，而人工智能、操作系统等计算机基础学科知识的应用体现在MMORPG开发过程中的方方面面。

一、游戏世界的划分

理想状态的游戏世界仅由一个完整的场景组成，在《魔兽争霸 III 》、《 CS 》这样的单机游戏中，所有玩家位于该场景中，在理论上，位于该场景中的任意玩家都可以看到游戏中所有玩家并与之交互，出于公平性和游戏性（而不是技术上）的考虑，游戏中并不会这样做。

然而，目前的 MMORPG 中，几乎没有任何一款可以做到整个游戏世界只包含一个场景，因为在一款 MMORPG 中，同时在线的玩家数量成百上千，甚至是数万人同时在一个游戏世界中交互。以现在的网络技术和计算机系统，还无法为这么多玩家的交互提供即时处理。因此， MMORPG 的游戏世界被划分为大小不等、数量众多的场景，游戏服务器对于这些场景的处理分为分区和无缝两种。

在分区式服务器中，一个场景中的玩家无法看到另一个场景中的玩家，当玩家从一个场景到另外一个场景跨越时，都有一个数据转移和加载的过程（尤其是从一个分区服务器跨越到另外一个服务器时），玩家都有一个等待的时间，在这段时间内，服务器的主要工作是实现跨越玩家数据的转移和加载以及后一个场景中玩家、 NPC 等数据的传输，客户端的主要工作是实现新场景资源的加载和服务器通信。主要时间的长短主要取决于后一个场景中资源数据的大小。分区式服务器的优点主要是各分区服务器保持相对独立，缺点是游戏空间不够大，而且，一旦某个分区服务器中止服务，位于该服务器上的所有玩家将失去连接。

所谓无缝服务器，玩家几乎察觉不到场景之间的这种切换，在场景间没有物理上的屏障，对于玩家而言，众多场景构成了一个巨大的游戏世界。场景之间，甚至服务器之间“没有了”明确的界线。因此，无缝服务器为玩家提供了更大的游戏空间和更友好的交互，实现了动态边界的无缝服务器甚至可以在某个服务器中止服务时，按一定策略将负载动态分散到其他服务器。因此，无缝服务器在技术上要比分区服务器更加复杂。

目前国内上市的 MMORPG ，大多采用分区式服务器，做到无缝世界的主要有《完美世界》和《天下贰》等，国外的 MMORPG 中，像《魔兽世界》、《 EVE 》等，都实现了无缝世界。

无缝服务器与分区式服务器在技术上的主要区别是，当位于场景 S1 中的玩家 P1 处于两个（甚至更多）场景 S1 、 S2 的边界区域内时，要保证 P1 能够看到场景 S2 中建筑、玩家、 NPC 等可感知对象。而且边界区域的大小要大于等于 P1 可感知的范围，否则就可能发生 S2 中的可感知对象突然闪现在 P1 视野中的异常。

无疑，无缝世界为玩家提供了更人性化和更具魅力的用户体验。

二、无缝世界游戏服务器的整体架构

MMORPG 的服务器架构从功能上主要划分为三种：

1、 登录服务器（ Login Server ）

登录服务器用于玩家验证登录，并根据系统记录玩家信息得到其所在节点服务器，并通过世界服务器为登录玩家和对应节点服务器建立连接。

2、 世界服务器（ World Server ）

世界服务器将整个游戏世界划分成不同场景，将所有场景按一定策略分配给节点服务器，并对节点服务器进行管理。世界服务器的另一功能是与登录服务器交互。因此，世界服务器是登录服务器、节点服务器的沟通桥梁，当然，一旦玩家登录成功，世界服务器将主要处理节点服务器间的通信。因此，世界服务器对于玩家是透明的。

3、 节点服务器（ Node Server ）

节点服务器负责管理位于该节点的所有玩家、 NPC 的所有交互，在无缝世界游戏中，由于边界区域的存在，一个节点服务器甚至要处理相邻节点上位于边界区域的玩家和 NPC 的信息。

在具体实现上，不同的 MMORPG 为了便于管理，可能还会具有 AI 服务器、日志服务器、数据库缓存服务器、代理服务器等。

三、 无缝世界游戏服务器的主要技术需求

1、 编程语言（ C/C++ 、 SQL 、 Lua 、 Python ）

2、 图形库（ Direct 3D 、 OpenGL ）

3、 网络通信（ WinSock 、 BSD Socket ，或者 ACE ）

4、 消息、事件、多线程、 GUI

5、 OS

三、无缝世界游戏服务器需要解决的主要问题

1、 资源管理

无论是服务器还是客户端，都涉及到大量资源：玩家数据、 NPC 数据、战斗公式、模型资源、通信资源等。当这些资源达到一定规模，其管理的难度不可忽视。而且，资源管理的好坏，直接关系到游戏的安全和生命。

2、 网络安全

安全永远是第一位的，我们无法指望所有的玩家及其所持的客户端永远是友好的。事实上，威胁到游戏的公平性和安全性的大多数问题，归根结底，都是由于网络通信中存在的欺骗和攻击造成的，这些问题包含但不限于交易欺骗、物品复制。

3、 逻辑安全

逻辑安全按理说应该是游戏中最基本的考虑，覆盖的范围也最广最杂。随机数系统是一个非常值得重视的问题，随机数不仅仅用于玩家可见的一些任务系统、战斗公式、人工智能、物品得失等，还可用于网络报文加密等。因此，随机数系统本身的安全不容忽视。另外一个常见的逻辑安全是玩家的移动，最主要的就是防止加速齿轮这样的变态操作。

4、 负载均衡

MMORPG 中的负载均衡包括客户端及服务器资源管理和逻辑处理的负载均衡，其中最难预知的是网络通信的负载均衡，正常情况下的网络通信数量是可以在游戏设计时做出评估的，但因恶意攻击造成的网络负载是无法预测的。因此，负载均衡所要处理的主要是实时动态负载均衡和灾难恢复。负载均衡需要解决的问题包括负载监控、负载分析、负载分发和灾难恢复。

5、 录像系统

录像系统的构建，主要用于重现关键数据的输入输出，如玩家交易、玩家充值，或者当 bug 出现后，为逻辑服务器（泛指上文提到的所有类型服务器，主要是节点服务器）相应部分启动录像系统。待收集到足够数据后，通过录像系统重现 bug 。为了使逻辑服务器不受自身时间（如中断调试等）的影响，还可以专门设计心跳服务器来控制数据传输。

四、总结

在 MMORPG 中，真正的 bug 永远存在于将来。从这一点出发，关于 MMORPG 中游戏世界的构建，怎样苛刻的思考都不为过。

参考资料：

1、 [美] Kim Pallister编, 孟宪武 等译. 游戏编程精粹5, P467-474, P516. 人民邮电出版社, 2007年9月. 北京.
2、 [美] Thor Alexander编, 史晓明 译. 大型多人在线游戏开发, P174-185. 人民邮电出版社, 2006年12月. 北京.
3、 [美] Dante Treglia编, 张磊 译. 游戏编程精粹3, P117-122. 人民邮电出版社, 2003年7月. 北京.
4、 [美] Mark DeLoura编, 王淑礼 等译. 游戏编程精粹1, P90-93. 人民邮电出版社, 2004年10月. 北京.
5、 [美] Douglas 等著, 於春景 译. C++网络编程 卷1. 中国电力出版社, 2004年11月. 北京.
6、 [美] Stephen D. Huston 等著, 马维达 译. ACE程序员指南. 中国电力出版社, 2004年11月. 北京.
7、 [美] Erich Gamma等著, 李英军 等译. 设计模式. 机械工业出版社, 2000年6月. 北京.
8、 游戏引擎全剖析. http://bbs.gameres.com/showthread.asp?threadid=101293.
9、 服务器结构探讨：登录服的负载均衡. http://gamedev.csdn.net/page/351491d0-05ad-48a4-85e1-77870bc1eef3.
10、服务器结构探讨：最终的结构. http://gamedev.csdn.net/page/28695655-974c-4291-8ac4-2589c4e770d3.

目前在做一个超大地图MMORPG的场景管理部分，客户端通过动态预读解决了超大图量的动态加载，但是在做人物行走的时候遇到了一些问题：
　　一张地图上的PLAYER和NPC等是存放在一个list中的，地图超大那么上面的PLAYER就可能超多（预计大于２００），这样的话每个行走动作都要发送２００条以上的消息，这对于服务器是一种很大的负担，而且这种负担是呈级数增长（10个玩家都走一步服务器将发送10*10=100条消息，而200个的话就是200*200=40000条消息！），可能任何服务器都无法负担。
　　肯定有很多朋友都遇到了类似的问题，很想知道大家是怎么解决的？
　　

方案一：
　·服务器上每个场景用一个list来保存上面的player和NPC
　·玩家行走、进入和离开等事件发给list中的所有player
　·客户端的list保有该场景上的所有player和npc
　优点：处理起来简单直接
　缺点：发送的消息会随玩家数量的增加而暴增、客户端负担很重

方案二：
　·服务器上每个场景用一个list来保存上面的player和NPC
　·玩家行走、进入和离开等事件只发给该玩家一定范围内的Player
　·客户端的list只保有本玩家附近的player和npc
　·在服务器可以考虑使用hash表来优化查询速度
　优点：减少了服务器发送消息的数量、减轻了客户端的负担
　缺点：实现相对复杂，服务器负担大大加重（因为要不断判断玩家间的位置关系）

方案三：
　·在服务器上把场景划分为小区域（大于屏幕大小）。每个区域对应一个list，场景中的所有对象按他们的位置加入到对应区域的list中，那么每次行走只需要把消息发送给最多４个相临区域的Player
　·客户端的list只保有本玩家附近的player和npc
　优点：大大减轻了服务器遍历list的负担、减少了发送消息的数量、减轻了客户端的负担
　缺点：实现非常复杂、而且在服务器需要不断判断玩家是否跨越区域

方案四：
　·服务器上场景的每个TILE保存一个Object指针用来绑定该格子上的player或NPC
　·玩家行走、进入和离开等事件发给玩家周围一定范围内的player
　·客户端保有该player周围一定范围内的player和npc
　优点：处理起来极为直接、避免了耗时链表遍历（典型的以空间换时间）
　缺点：地图每个TILE都要加入一个指针变量（管理不善容易出错）、每次发送场景广播要遍历所有TILE

方案五：
　·服务器上每个场景用一个list来保存上面的player和NPC
　·不使用事件通知，而使用状态位置通知的方式通过定时发送状态来更新客户端的player和npc状态
　·客户端保有该player周围一定范围内的player和npc
　优点：处理比较简单
　缺点：实时性太低，对于要求同步比较精确的ＡＲＰＧ不太适合

    说起高性能的网络游戏，有2个典范，1个是暴雪的WOW，另外一个要数腾讯的QQGame了，因为对于MMPRPG的体系接触不深，几乎属于文盲，没有太多的发言权，而自己又是搞休闲游戏开发的所以本文就主要谈谈QQGame了。

    前些天通过朋友得到了QQGame的一个系统分析的文档，看完后很是震惊，彻底被QQ的设计所折服了，到底是千万人在线系统经验的拥有者，牛！

    通过资料了解到QQGame目前有以下让我欣赏的特性：

1.单机最高容纳35,000人同时在线，对没有看错是这么多，由于它适用了Linux下高性能的网络处理模型ePoll技术，并且一系列高超的优化技术轻松破万人，当然为了稳定性考虑单机保持了2万人的容量，此时的带宽消耗为近30M；
2.采用共享内存方式高速完成进程间高速通讯；
3.服务器的扩充方式不是平面的方式，而是裂变式的扩充方式，形成负载均衡阵列树状结构；
4.所有的游戏服务器不是直接和数据库联系，而是和数据proxy(qq管叫数据交换机和路由器)进行联系，由此带来的就是游戏用户数据的分布存储，我分析着应该是proxy上记录着这个用户数据所在的实际的dbserver的信息，然后定时的将最新的用户信息写回到db中去，这样就大大缓解了数据库服务器的压力，而且可以非常平滑的将数据分裂开来，数据库服务器也就可以无限的扩充，当然我觉得肯定有个数据库信息索引了用户的id和对应的存储地点的关联关系，这点就类似于google的原理了，所以对于数据库的硬件要求也就不是那么高了，qqgame的一组服务器通常是7台服务器，可以容纳5万人，其中就包含了数据库服务器，这点就不是棋牌游戏所常使用的数据集中存储了；
5.游戏服务器的网络和逻辑分开，不仅仅是层次上的分开，而是在进程上分开，然后中间通过共享通道进行管理和协调，并且增加了辅助线程，在主线程处理大压力的异步的操作的时候直接交给辅助线程处理，保障了游戏服务器的高效性运转。
    作为游戏服务器的结构方面(以下只讨论休闲游戏部分,MMORPG服务器不属于讨论范围)的设计已经相对于成熟并且统一,结构方面和3年前我所接触的中游系的那套平台没有太大的差异,无非是服务器群采用星状的结构,以1个中心节点作为核心,然后向四周扩散出一些应用服务器,如负责登陆的LoginServer,负责具体游戏逻辑的GameServer等等,当然最精简的结构是这样的,这样的结构可以满足50万以下同时在线的容量,如果为了满足更大的容量,如QQGAME这样的目前已经有200万以上同时在线的超大容量的应用则需要额外的优化,从这个结构中分离出一些子应用独立开发出一些服务器端来处理,一方面降低偶合度,另外一方面作为高可用性系统为负载均衡提供条件.

关于负载均衡,作为整个游戏平台的所有服务器.我觉得除了具体的游戏逻辑服务器以外都是可以采用负载均衡,多点分担的方式来处理,惟独逻辑服务器不可以,因为休闲游戏,都是分层次的,不管泡泡堂也好,QQGAME也好这些游戏其实在客户端的表现形式都是分层次的,如QQGAME就是LOBBY-HALL-ROOM这样的结构,LOBBY这层就是游戏广场了,可以看到所有的游戏类别,游戏服务器和具体的游戏大厅,比如:牌类–斗地主–新手场–新手场1 这样的顺序,传统的设计中新手场1就是属于一个独立的游戏逻辑服务器拥有一个独立的IP以及侦听端口,在服务器端通常也是一个独立的进程.一般的游戏服务器允许的连接数通常都是300-600人之间超过的就提示服务器已满了，这样做的原因并不是因为进程的限制因为一个进程完全可以做到同时让3000以上的玩家同时游戏，而是人为设计的考虑，因为在游戏逻辑服务器中有很多需要广播的消息，如游戏玩家的聊天信息，某个房间的开始信息，结束信息，某人进出的信息等，而对于广播来说，给300个人广播和给3000个人广播所消耗的资源是绝对没有可比性的。但是通过从进程上独立来处理这个传统的方式也有个缺陷，比如通过开10个进程来达到3000人和1个进程达到3000人，如果不考虑广播的因素在内的话前者的资源是要高与后者的资源的，并且进程间的通讯也要比进程内的通讯要耗费资源和复杂度方面要高很多，比如说如果要实现一个需求让玩家可以在同一类游戏中可以使用小喇叭类或者跨游戏服务器找人之类的功能的话，同一个进程的优势就显示出来了，为此QQGAME所使用的是Channel(频道)的概念，即一个游戏逻辑服务器的进程可以容纳5000人左右，然后服务器端通过设置分割出很多的Channel如新手1，新手2，新手3之类的传统意义上的游戏大厅，将消息的分发范围进行隔离，节约了资源。这一点可以通过查看连接属性看到，连接QQGAME的同类型靠近的几个游戏大厅其实端口和IP都是一致的。

我们目前的游戏服务器类型主要有3类：CenterServer，管理着所有的服务器连接，LoginServer 负责处理用户的登陆、注册，并且用来给用户传递游戏逻辑服务器列表等功能， GameServer具体逻辑服务器，根据不同的逻辑来实现不同的游戏需求。

当然，根据业务的发展需要，我们正准备把用户的状态在服务器端保存，并且增加一个类似IM服务器的功能来满足玩家跨服务器聊天和查询其他玩家状态的需要。以及GM服务器实现多功能的网管室的需求，这些将在以后慢慢写。

今天开始写些技术的题材,一方面记录一些自己的本分工作的东西,另外一方面也是充实一下BLOG,工作太忙也没有什么太多的思绪来一直写其他的题材,所以就拿工作来填充了.同时如果有人有幸看到了这些文章,并且也有兴趣的话也希望多多探讨.

先简单介绍一下,由于本人的工作就是游戏开发公司的,一直与游戏开发打交道,主要做休闲类的游戏,目前又以棋牌游戏为主,在这个行业中摸爬滚打了整3年了,从运营开始做起,运营过当时国内一流的游戏平台中游系列的产品,然后由于合作方面的原因又自主开发过一套游戏平台,然后由于发展方向上的分歧出来单独做,目前在开发并运维一套全新的产品.

这篇主要是对于游戏服务器的一些想法,结合目前自身的产品的一些问题延伸开来的.

目前我们的服务器还是属于Windows平台的架构,暂时还没有考虑到跨平台,主要原因有2:
1.成本:作为公司来说首先得考虑的就是成本了,虽然说Linux类的平台存在着操作系统成本低廉,性能优异,稳定性高这几个特色,但是作为全局考虑来说,一个Linux的系统管理员,以及开发人员的成本要比Windows平台要高很多,并且作为操作系统方面是免费的,但是支持几乎是没有的只有一些不适合商业应用的开源社区作为支撑,要得到更加好的服务或者额外的支持还是得通过大厂商的高额的产品或服务来实现,而Windows平台则不同,虽然操作系统貌似价格不扉,但是本身就带了很多的模块,比如组件服务,日志服务等等,加上平台上各种软件的数量也和Linux下的不是同一量级的,可选择性要大的多,而让Linuxer所诟病的Win32的安全性其实完全可以通过另外独立的安全模块,如硬件防火墙等来完善,毕竟操作系统不是专门做安全防护的Linux也存在很多的漏洞,并且随着Linux发行版的日益增多,用户的逐渐了解,漏洞也日益的增多.
2.开发效率.无疑Visual Studio系列开发套件是目前开发领域最方便最强大的IDE环境,这已是不争的事实,而如果用VI + GCC的模式去开发LINUX下面的服务器其效率和质量至少从我目前的水平(可以部分代表国内目前中小游戏软件开发商实际现状)要彻底的领悟并转换需要一定的时间,并且还没有成熟的开发平台作为保证, JAVA好象有 但是C++还没有听说有超过VC++的.

Scrum，这只敏捷家族中的生力军，现在正被越来越多的人认识并且接受。在游戏开发领域中，近年来国内的许多企业也开始尝试采用Scrum进行游戏开发。Scrum这种强调频繁交付紧密沟通的开发方式似乎证明了比它的前辈们更适合游戏开发领域。但正如人月神话中的那句老话“No silver bullet”。那么对于如今国内占主流的大型多人在线游戏（MMO）开发领域而言，Scrum是否就是那枚传说中的银弹，一经发射，就能让摆在你面前的所有问题都瞬间灰飞烟灭？我们在具体的执行层面又应该怎么去控制和管理它呢？笔者希望以下的文字能帮助你解答以上两个问题。

Scrum与传统方式之间的不同

在使用Scrum之前，公司或者开发团队多多少少已经有一些成型并且大家都已经习惯的开发模式。打个比方说，策划先行，然后召集大家讨论策划案，之后得出程序和美术的工作量再定义出里程碑拟订好开发计划，然后大家开始正式分头动工。在这个开发流程中，开发人员面临的最大困难是策划案也就是需求的变化量非常大，并且这种变更，很大一部分情况可能是直到里程碑快结束的时候，大家才一起意识到有些功能压根就无法实现或者勉强实现的效果并不理想。这时似乎只剩下修改策划案这一条路。于是大家对于无论如何严格的审核策划案，到中途总是会以这样那样的理由变更的情况已经习以为常。因为需求变更而导致产品推出时间可能一推再推，以至于最后不得不砍掉一些功能才能确保产品在可以接受的时间之内被推出。

尽管传统的开发方式可能有些地方老是出问题，但大多数情况下大家也会比较倾向于下次注意点，而不是尝试一套新的开发方法。在MMO的开发模式的选择上，Scrum在许多地方的确可以解决传统模式所遇到的问题，比如Scrum能在拥抱变化这一点上极大的帮助开发者。类似这样的优点，在Scrum的拥护派看来，可以列出好几页来。但是，要说服一个原有的团队选择一种新的开发模式来代替大家已经熟悉的方式，光列举优点是不够的，我们也需要直面Scrum与现有模式的其他差别，有些甚至是Scrum的劣势。

1． 每次提交可运行的版本

Scrum的精髓在于拥抱变化，并强调通过频繁的交付来获得及时的反馈，以便于尽可能快的调整不合理的需求。但对于某些大型MMO而言，比如MMORPG，系统的复杂度往往超出我们的想象。如果没有一款已经使用过的引擎，光是前期对低层技术的开发就是一个漫长的过程，如果采取Scrum的方式，要求每一小段时间提供一个可运行的版本无疑是一个噩梦。而对于同时进行的策划案的撰写，要求提供一个反应策划内容的版本更是困难。Scrum在这个阶段如何开展，是需要克服的一个问题。

2． Sprint的划分

相对于传统的基于里程碑的开发，Scrum要求划分出一个个相对较短的Sprint。并且每个Sprint需要有可以提交的版本，以及一个比较明确的可以体验的目标。而在MMO的开发中许多工作，比如系统架构设计，数据库设计，美术概念讨论等都很难在Sprint中体现出来，也就无法通过Sprint Review的形式获得反馈。但是这些东西又跟所有的人的工作息息相关。Scrum如何在能够保持紧密沟通的同时，对类似的相对独立的部分也照顾周全？

3． Scrum的管理

Scrum是一个强调自我管理的开发方式。无论是Stand Up Meeting还是Sprint Planning的时候都要求少干涉多聆听。对于项目经理来说，某些时候参与感很差，总是好像找不到自己在团队中合适的位置。但是项目经理又不得不对进度负责，面对各个并行的小组，每天都可能有大量新的task提出，又有大量task被否决，如果你这个时候去问项目经理“我们到底能不能按时完成，如果推迟，那还需要多久”这样的问题的话，他也许只能对你摇摇头。我们在使用Scrum的时候，进度管理上的缺失也是我们需要直接面对的问题。

类似的问题，在我们推广Scrum的时候可能会遇到很多。为什么会有如此的问题归纳一下，原因可能如下：

1． Scrum最早来自于软件工程，虽然现在扩展到开发的各个方面，由于其自身的限制性，注定要面临许多困难。（笔者曾经听说过某公司号称用Scrum进行管理，要求销售，HR部门都实行Scrum方式，很难想象这是一种怎么样的Scrum。）

2． MMO开发本身结合了跨平台，分布式，周期长，变动大等多个开发难题， Scrum能够很好的解决一些问题，但对需要长期规划的问题明显缺乏控制力。

融合：和其光 避其尘

在笔者看来，Scrum是一种优秀的开发方法，许多特征的确证明了它比它的前辈们更好的解决了游戏开发中所遇到的诸多问题。可是，如同它的前辈一样，Scrum并不是游戏开发中的那颗Sliver Bullet，再次应征了Brooks大师所言。所幸的是，我们可以使用Scrum与传统开发方式“混血”式执行的办法，根据自身情况，灵活的选择有利的方面执行，对不适应的地方进行改进，从而能最大限度的在MMO游戏的开发中发挥出Scrum的威力。

笔者有幸在参与的一些项目中使用过Scrum方法，同样也经历了Scrum与本土MMO开发结合时候遭遇的种种尴尬。笔者认为，Scrum对于MMO游戏的开发，有其利也有其弊，对于整体进度的把握以及对于文档工作的控制Scrum做得并不是十分到位。对于任何一种开发方法论而言，执行团队都需要从自身实际的条件出发，选择性的使用。最怕的是盲目执行，暴力式地推行，而其他软件的工作却不跟上，执行的团队并不明其所以，最后可能搞得人人谈敏捷而色变，失败当然是一个必然的结果。笔者始终认为，工具，方法始终是死的，如何使用才是真正出学问的地方，只有从自己实际出发，冷静分析，在合适的地方用合适的工具，才能做到庖丁解牛，游刃有余。

那么Scrum应该如何结合传统的MMO开发方式呢？我们从项目开发的各个阶段来一一分析，如何让Scrum发挥自己的威力。

项目前期

项目前期我们面临的问题有哪些？首先是产品尚未成型，团队也许对将要制作的产品并没有一个十分清晰的概念，更谈不上对项目规模的预估。其次有一大堆技术性的难题摆在团队面前。这些难题能否解决，如何解决，都势必会对策划案的成型有决定性的影响。这个时候，我们可以分两头采取不同的开发模式。

对于将面对的技术难题，这个时候目标明确，团队规模较小。比较适合采用Scrum的形式一一攻克这些问题。我们可以把大家公认会遇到的难题列举出来，通过Scrum Planning的形式分解成一个个User Story再划定各个问题的优先级和互相的依赖关系，然后分别组建Scrum团队。这个时候的目标很明确，即得到这些难题的解决方案。我们希望在这个阶段结束的时候，程序对所要面对的技术问题心中有数，策划也对哪些能做哪些不能做有一个清楚的认识。同时我们还希望对一些我们必须要克服的东西，在这个阶段已经能产生一些行之有效的工作流程。

对于Scrum小组的组建，这个阶段我们可以以程序为主，策划和美术作为某些User Story的Customer，负责对程序工作成果的审查。为避免过早的陷入需求更改的陷阱，这个时候策划除了验收成果之外，不应过多的干涉程序实现的方法，而仅仅在设计User Story的时候提出自己的意见（事实上很多User Story应该由策划和美术直接提出）。在Sprint的划分上，我们可以以2～4周的标准划分。尽量将这个阶段控制在2～4个Sprint之内（这取决于团队的大小和技术基础）。对于一些经过验证存在困难的User Story可以在每个Sprint Review结束后的Planning Meeting上经大家讨论做少许更改，让下一个Sprint向更接近我们的目标（切实可行的解决方案）的方向上前进。对于Scrum的范围，笔者建议尽量不涉及高耦合的工作，将涉及多个方面的User Story拆分成相对独立的部分再分头进行。举个例子来说，可以将服务器端和客户端的技术难题分开进行，对于涉及服务器端和客户端交互的功能再单独提出来作为一个Scrum，尽量保证工作的粒度比较小，减少互相依赖的关系。我们的首要目标是证明技术可行性，这对整个流程的开展有一定的好处。

对于策划案以及美术风格的概念设计，这个时候则采取较为传统的方式，由策划和美术师内部产生。策划在对程序的Scrum小组提出User Story的同时即提出了自己的疑问，在程序执行Sprint的过程中获得对自己提出问题的反馈，进而决定自己的策划案如何撰写。美术则在这个时候确定美术风格，以及在与程序Scrum小组合作的过程中确定某些美术工作的工作流程。笔者不建议这个时候就加入程序对策划案进行讨论，这也许和某些团队采取的方式不同。这种方式对策划和美术的要求较高，既需要向程序的Scrum小组提出User Story，并从审查中获得反馈；也需要保持设计工作的相对独立，做好策划案的前期工作。这需要策划或美术在前期就对中期可能发生的问题有所预见，向程序有针对性的提出需要测试的地方而不是等待程序来告诉你不可行。如果这个时候能有富有经验的产品经理或者制作人来负责这两方面的协调工作，也是一个确保这个过程可以顺利进行的有效因素。对于程序美术在前期就加入讨论，笔者是持保留意见的。比如曾经经历过的一个项目就因为太早冻结策划案以至于美术和程序花了几天来讨论每个UI元素的具体坐标是多少，但最后却不得不尴尬的面临因为用户体验不友好而更改UI方案的情况。

在这个阶段结束的时候，我们应该得到一个策划案的初稿，起码完成了整个系统以及世界的架构，可以估计出项目将来在程序，美术和策划工作上的规模。还应该有几套行之有效的工作流程，能根据项目的预计规模估计出将要投入的人力和项目需要进行的时间，以便于之后的市场等多项工作的计划和开展。接着，我们就便可以投入更多资源进入正式开发的阶段。

项目中期

在MMO项目中期，我们面对的主要问题是对整体进度的把握，确保能按时推出我们需要的版本。其中面临最主要的难题就是对需求变更的控制。这个方面Scrum有其决定性的优势，但如何在高度拥抱变化的同时又不失对进度的把握是Scrum在这个阶段所要面临的问题。笔者建议这个时候需要根据团队对Scrum的熟悉程度来选择不同的解决办法，分别采取以Scrum方式为主导传统方式为辅的方式，或者反之。

对于一个熟悉Scrum的团队而言，笔者的建议是在正式开发之前，整个团队坐在一起，讨论策划案。将策划案中划分的各种系统分解为不同阶段的User Story，再通过团队之间的讨论以及各组之间的工作配合需要制定出优先级。现在我们有了一大堆由策划案分解出来的User Story，这些User Story有一定的依赖关系和不同的优先级，这时候根据我们的需要将这些User Story组合成不同的Sprint，再视这些Sprint的目标和内容组合成不同组合，每个组合我们可以视之为一个里程碑。如果你的项目的时间预算非常有限，你可能会倾向于将一些不是很重要但如果不完成其他部门就无法开展工作的User Story先行制作；如果你的时间充裕，你则可能更倾向于先有一个完备的系统设计以及一个方便扩充的灵活架构，让其他部门暂时等待或者做其他的事情。总之，这一切取决于项目具体的需要和团队资源，并没有孰是孰非之分。

由User Story来构建里程碑这对团队的Scrum能力而言是一个考验，需要团队对User Story乃至Sprint的划分有一定经验，并且能够预见整个过程中可能面临的风险。选择合适，制定好的，可实现的User Story可以规避很多由于后期Sprint变更时候带来的连锁反应。这也是为什么笔者建议有一定Scrum经验的团队选用该方法的原因。

对于初次尝试Scrum的团队，可以尝试采取相对保守的方法。通过传统的方式对策划案进行技术评估后，划分出里程碑，然后根据每个里程碑的目标制定User Story，再划分Sprint。这在一定程度上降低了对User Story制定上的要求。同时在每个Sprint结束的时候根据Sprint完成情况结合里程碑的目标对User Story进行修正。听起来似乎和上个方式大同小异，但执行过程中可以省略对Sprint筛选和组合的过程，可以说目标更加明确，对尝试达成这个目标的团队来说也相对轻松一些。

无论采取什么样的方式，对于进度的管理上都是需要按照传统的方式划分里程碑。这可以方便我们把握项目整体进度,防止由于Sprint过多并且更改过快以至对项目整体进度没有概念。每个里程碑就像一扇扇保险门，明确里程碑所要达到的目的以后就不再轻易变更，严格控制好里程碑中间Sprint的变更范围。从某种意义上讲，这种互相结合的方式能够有效降低项目中期由于变更过多而造成进度失控的风险。

这个阶段的Scrum团队的组建也不同于项目前期。这时一个Scrum团队是一个包含程序，美术，策划乃至市场人员的复合小组。这个阶段中的Sprint的之间的变更乃至小组成员的身份的变化也会更加复杂。同一个Sprint中一个User Story的执行者可能是另一个User Story的Customer，需要在开发过程中保持高效的沟通。小组成员也并不是固定不变，在一个Sprint结束之后根据下个Sprint的目标可能组合成不同的小组。比如这2周做NPC交易的小组成员，可能下个Sprint会和其他人组成摆摊系统的Scrum小组。重要的是我们作为一个整体的团队如何达成每个Sprint的目标，而不是保持单个Scrum小组的独立性，毕竟灵活性也是Scrum的一大优势。

这是一个频繁迭代的阶段，也是游戏内容不断增加和修正的过程，在每个Sprint结束的时候，我们都应该得到一个可以运行的版本用于衡量该Sprint的目标是否达到。策划要在每个Sprint review之后总结更正自己的设计，美术也随着一个个Sprint的完成，看到自己的作品一批批导入到游戏中的效果。所有这些都需要建立在团队成员之间高效的沟通，以及默契的合作之上。这也对团队的自我管理能力也提出考验。

在项目中后期，我们会面对成批从QA部门反馈的bug以及为配合市场活动而临时增加的开发需求。Scrum的灵活性在这个时候可以得到进一步的发挥，随着投入资源的增多，我们可以对这些工作内容建立单独的Scrum团队，用于解决这些琐碎但庞大的新增需求。别忘了，Scrum是最善于解决目标相对明确的短周期需求。

随着Sprint的一个个进行，里程碑的一个个完成，我们终于走到项目交付和维护的时候，这个时候我们面对的是单机游戏不曾经历的维护和运营阶段。

项目后期

一个MMO的开发并不随着产品发行的结束而结束，无休止的维护和资料片的推出是团队必须要面对的现实。同时团队人员的更迭也需要在这个时候开始进行。我们慢慢要把原来开发团队的部分人员抽离出来，以便于开始新的项目。对现有项目的维护和对新加入人员的培训是我们在项目后期需要面对的主要问题。

项目后期的工作，笔者看来分为两大类，一是原有系统的BUG，运营商的2次开发需求以及来自于市场或者策划方面的活动需求，二是并行的资料片开发。先说资料片开发，开发量和内容都基本上相当于项目中期的一个或两个里程碑，对于Scrum的处理方式可以按照项目开发中期的方式通过复合的Scrum团队来处理。通常会在版本控制系统中建立一个平行的分支进行开发，值得注意的是需要随时准备集成对原有版本的改动。对于第一类问题，则通常不会涉及太多原有系统的改动，可以单独建立程序或者美术+程序的Scrum小组进行有针对性的开发。通常这个时候，进度已经不会再成为压力，对积累了开发阶段Scrum经验的团队来说，不会有太大问题。值得一说的是如果不是自主营运，对来自运营方的需求如果要对方来适应Scrum的开发模式可能有点强人所难。好消息是来自运营方的需求并不会像我们可爱的策划案一样频繁变更。Scrum小组定义好一个接口人以后可以仍然按照自己习惯的方式进行开发，把哪些恼人的外部沟通工作扔给接口人吧，这样可以在一定程度上降低我们沟通的成本。

Scrum的过程控制工具

在使用Scrum的过程中，尤其是周期比较长的项目，对于负责项目进度控制的人来说，整体进度把握和对基础架构工作的控制都是比较头痛的问题。这时，有许多工具可以帮助我们对目前的风险和进度有一个清楚的认知。

可交付物件列表（Deliverable Check List）

不同于其他采取Scrum方式进行开发的软件项目，MMO的开发过程中，文档还是扮演着相当重要的角色。一个MMO可能产生上万甚至百万字的文档工作量，我们既需要保证开发的高速和灵活，也要保证这些文档的创建和维护。在项目的各个阶段我们需要有一个或者多个可交付物件列表。这个列表可以方便我们跟踪策划案，美术工作量，以及诸多程序设计的文档的制作情况。

列表中的每一项都是一个可提交的物件，每个物件都需要设定相关的负责人，审批人以及预计完成时间。这种列表是传统开发方式的产物，然后在Scrum进行的过程中，这些物件可以作为一个个User Story分布在各个阶段的Sprint中，也可以独立在Scrum之外。通常这些文档可以作为某个阶段结束的标志，然后再以这些文档为基础来做下个Sprint的Planning。通过维护这样的一个列表，我们可以对一定范围内的整体工作量有所控制，能够弥补原本Scrum在这点上的不足。

每天编译 （Daily Build）

存在着多个并行的Scrum小组就意味着会可能同时存在多个不同的版本。前面建议大家在Scrum过程中尽量将不同Scrum小组目标的耦合度降低正是为了减少系统集成的时间。有不少团队采取分头开发，然后在一个约定的时间统一进行系统集成的办法。然而笔者并不建议采用这种方式，主要原因是随着分头开发的持续，各个小组之间并不清楚对方在做什么，代码上产生的差异会累积下来。等到做系统集成的时候，有时候会被迫面对二者只能取其一或者又要花费大量的时间来修改已经完成的系统的尴尬情况。这个时候，建立一套每天自动编译最新版本的系统可以帮助你化解这个方面的危机。

这个系统每天会从版本控制系统中更新最新的代码来编译一个可运行的版本，并自动做一些简单的系统测试工作。这里的测试工作相当简单，往往只要能保证启动程序或者连上服务器端这样的基本功能。当编译出错或者系统测试无法通过的时候，该系统能够通知相关人员，从而迫使程序员在上传代码的时候做好merge工作。为了合并好代码，不同的Scrum小组之间也需要经常沟通，以了解对方的工作进展，帮助程序员养成符合Scrum精神的工作习惯。

向下燃烧进度表（Burn down Chart）

对于Sprint与Sprint之间，乃至里程碑与里程碑之间的完成情况，通过Burn down chart这个工具我们可以随时了解任务的完成情况以及和计划的偏差。同时Burn down chart也能很好的反映在项目进行过程之中，user story的变更情况。

拿下面的一个burn down chart来说。

这是一个持续了3周的sprint，这个表反应的是在这个sprint过程中所有任务每天的完成情况。这里每天的完成百分比是由从第二天在每日起立会议以后收集到的任务完成情况决定的。我们可以看到在4-28和5-2这两天的计划曲线有一个起伏，这是由于当天有新增加的任务，这对我们Sprint review的时候评估这个Sprint的完成情况可以起到参考作用。

其他的比如告示板，索引卡，Sprint Planning等工具和方法，一般的Scrum的书籍都有介绍，笔者在这里就不再一一列举。笔者主要列举的是基于MMO的Scrum开发过程各个层面上的简单进度控制工具，以帮助团队及早发现风险，并得出应对之策。

推广Scrum过程中要注意的问题

向一个已经有过开发经验团队推广Scrum的方式并不是一件轻松的事情。没注意好的话，往往最后流于形势，不仅团队的积极性没有调动起来，甚至会让人产生反感。

环境的营造

使用一个类似Scrum这样自组织式的开发方式的时候，需要特别注意的是对于整个Scrum环境的营造。尤其不要流于形式，不然就真的是费力不讨好的事情了。笔者遇到的一个很典型的例子是：Sprint Review之前，程序的版本并没有集成编译过。于是为了准备Review中需要演示的东西，花了大半天的时间来合并代码并修改，演示结果可想一般。更糟糕的是，在user story被否决了以后，团队的积极性受到打击，对Scrum也颇有微词。

让团队真正理解什么是Scrum并不是简单跟大家宣读一下章程这么简单。持续的培训和心得交流是一个比较好的办法，有助于让团队了解每一步的意义和目的。同时还要鼓励大家多沟通交流，在Planning的时候提出自己的想法，多了解同伴的工作情况。不能再像原来一样各家自扫门前雪。

团队适应能力

谈团队素质是一个比较尴尬的问题，中国的游戏业毕竟还非常年轻。笔者的一个朋友曾经跟笔者抱怨过，原来尝试过Scrum方法，但试行了半年之后就放弃了。理由是Scrum太讲究团队的自我管理能力，他的团队并不能很好的适应这种自我管理的方式，而他的团队中还不乏有多年经验的开发人员。笔者的观点则是团队的适应能力跟团队成员的态度有关。我们当然不能苛求所有的团队成员都有多年的开放经验，尤其是项目失败经验，以便于他们理解Scrum可以帮他们解决多少他们曾经遇到过的问题。同样，就算有多年经验，抱着原来的方式不放，觉得这些新东西只是花招式，还不如自己的老三套来得实在也要不得。

团队是否能很好的适应Scrum方法，跟团队是否抱着积极开明的学习的态度有关。这在一定程度上也是依赖于团队内部的环境建设。而团队成员中参差不齐的素质笔者认为并不是太大的问题，我们并不需要所有人都能够对任务的规划和分解深刻把握，团队成员在这个高度强调沟通的环境中反而成长会更为迅速。

多次交付VS多次迭代

多次迭代并不等于多次交付，这是Scrum常有的一个误区。在每个Sprint开始的时候，我们都必须要明确这个Sprint结束的时候我们需要Review的是哪些东西。很多时候，如果一个Scrum开展不是很顺利，在Sprint Review的时候我们常常会听到这样的理由，“因为某些原因，这个功能我没有办法展示给你，但是这个功能是有了的，我只需要改动小小一点东西就可以了。”或者是“这个部分与另一个系统相关，我代码已经写好了，但我要一起改好了你才可以看到。”如果放任的话，这些理由到后期会泛滥成灾。我们所能做的，除了拒绝通过这些相关的User Story之外，在每个Sprint开始的时候还应该帮助团队了解到我们需要在Sprint Review上看到什么东西。强调我们重视的是可交付的版本，而不是一个口头上的功能增加。

有些时候这也取决于我们的User Story是否范围太大太空以至于无法实现。这也对要求我们提出更具体可实现的User Story，否则就需要及时拒绝它或者再细化。

结队

是否结队编程这个问题，笔者是持保留意见的。曾经有过一段不太愉快的结队经历，虽然不是随时“面向显示器编程”但相当时候两个人坐在一起写一段代码是常有的事情。个人认为在两人没有达到足够默契的程度的话，还是不要轻易尝试结队开发。而对于Scrum来说，除了结队，也可以通过buddy check（在提交代码前交由另一人检查提交）来确保互相对工作情况的了解。同时前面提到的每天Merge同伴的代码也是一个帮助团队成员互相了解工作情况的好机会。

最后

Scrum毕竟是个新东东，大家还正从适应中慢慢了解和熟悉。但从笔者看来，它的确是目前最适合游戏开发的方法论之一。除了能够从容应对需求的变化之外，他鼓励沟通的方式也能一定程度上激发团队的创造力，促进团队内气氛。在面对中国式MMO的开发上，灵活的把Scrum和传统方式相结合，通过不同的工具进行控制，能很好的弥补原来Scrum对长期进度缺乏控制，以及文档管理缺失的一些劣势，从而发挥其在需求管理，针对性解决问题上的优势，更好的解决我们在开发过程中可能会遇到的问题。

2009-09-02

今天为项目管理部的各个PM介绍了和培训了Scrum，得到了一致的认可。并同意在接下来的项目中使用Scrum进行实践。
但同时也提出了一些问题需要解决：
1、如果团队中存在美工，只有一个美工的时候，美工的工作量如何估算才算合理。程序不知道美工要干什么、要干多少天。同样美工也不知道程序怎么干。
如何保证美工的工作量估算的合适。
2、一个项目存在策划、美工、程序三个不同技能的集合，是当做一个团队、还是当做各自的团队，还是出去策划，把美工和程序作为一个团队。

不过今天的目的是为了说服PM在接下来的工作中使用Scrum，今天得目标已经达到。接着等待项目实践。

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://dreamhead.blogbus.com/logs/14189175.html

作为一个有理想、有追求的程序员，你成天被各种名词包围着，你对其中一个叫做敏捷的东西特别感兴趣，因为它特别强调人的作用，这听着都让做程序员的你感到舒服。为了让自己早日敏捷起来，你从众多的敏捷实践中选择了一个叫做测试驱动开发（Test Driven Development，TDD）的作为你的起始点。因为它对你周遭的环境要求是最低的：它不像结对那样，要求其他人和你一起合作；也不像采用Story那样改变你所在团队的做事方式……你所需要做的，只是在你编写业务代码之前，把测试先写好。这完全是一种润物细无声的做法，根本无需告诉你之外的任何人。就在别人忙碌的找bug时，你便开始享受敏捷带给你的快乐了。顺便带来的好处是，下次在那里和别人争论敏捷的时候，你可以以一个实践者的姿态出现，而不是在那里信口开河。

你不会打无准备之仗，于是，你通读了Kent Beck的那本薄册子。通读之下，你对TDD更是充满了信心。因为“红——绿——重构”的步骤实在是简单得令人发指。好吧！总而言之，你已经信心十足的准备开始TDD，步入敏捷的康庄大道了。

理想很美好，现实很残酷。

当你着手在实际项目中体验TDD的时候，一切变得并不像最初看起来的那样美好。虽然你努力的坚持着TDD的原则，但你经常就会发现某些东西不好测，比如你遇到了数据库，比如你遇到了GUI，比如你遇到了计时器（Timer）。敏捷并非教条，当某些事不可为的时候，你完全可以不那么坚持。于是，你告诉自己，不好测的东西可以不测，这样，至少从心理上来说，你觉得舒服多了。随着工作的继续，你发现，你不能测的东西越来越多，单元测试的覆盖率随着开发的进行正在逐渐降低，一丝恐惧涌上心头。回过头来，再去看Kent Beck的书，你突然觉得，你似乎被骗了，因为Kent Beck的例子貌似全都是逻辑，如果只是逻辑，当然好测了，但现实从来就不是这样。

难道TDD只是看上去很美？

显然，你不愿意就这样放弃，放弃你苦心学来的软件开发秘籍，那些传说中的高手极力推崇的TDD必然有一定道理，TDD确实能够让你感觉很好：能测试的那部分代码确实极大的增强了你对软件质量的信心，而且出错了也确实好找，每次修改代码之后运行测试出现的绿条也确实让你身心愉悦。

那问题到底出在哪呢？你陷入了沉思。

信马由缰，你翻开了自己写过的代码。看着自己写的这些代码，你忽然意识到一个问题，自己遇到的问题并不属于TDD，而是属于单元测试。正如你之前所想到的那样，TDD做法本身的结果是让你感到快乐的。对，一定是单元测试本身出了问题。那单元测试出了什么问题，很显然，一大堆不能测试的部分让单元测试变得很难写，降低了单元测试的覆盖度。那是不是这会是一个无解的问题呢？你显然不愿意就此放弃，所以，顺着这个思路继续向前。

TDD之所以让你安心，主要是每次编写代码之后，运行测试会出现一个绿条，告诉你测试通过。这样，你可以放心大胆的向前继续，因为你的代码并没有破坏任何东西。究竟是什么让你感到不安，显然是那些测试没有覆盖到的代码。你又仔细翻看了一下那些没有测试覆盖的代码，你的思路一下子清晰起来。之所以这部分让你不安，因为里面除了那些确实不好测试的部分之外，里面还有一些逻辑。如果只是那些真正不好测试的部分没有被测试覆盖到，你会觉得心里还有一些安慰。你确定了，真正使你不安的就是与不好测试的代码共存亡的这些逻辑部分。

如果测试可以覆盖到这些逻辑的部分，至少从感情上来说，就可以接受了。那怎么才能让这些部分被测试覆盖到呢？你仔细观察着那些没有测试的代码，如果这样做，这个部分就可以测试了，如果那样做，那个部分也可以测试了，一来二去，这些貌似不可测试的代码可以分解出许多可以测试的部分。

你的心情一下子好了许多，因为这么做终于可以让测试的覆盖度达到让你心理上可以接受的范围。不过，新的问题也随之而来。我在做什么？拆来分去，这不就是设计吗？怎么走到这里来了。我不是在分析单元测试的问题吗？对了，我最初的问题是TDD，怎么一路跑到设计上来了？

TDD？设计？

你突然发觉自己对TDD的理解有一些偏差。TDD，并不代表不需要设计。读过很多书的你突然想起了Robert Martin那本著名的《敏捷软件开发》，上面有一个关于数据库访问的例子。那个例子里面，前后两个版本的差异正好就是考虑设计的结果。通常，在设计中考虑测试，会很容易找到设计中僵硬的部分，让程序更加灵活。再进一步，如果在开始动手之前，稍微进行一些设计，这些问题还是可能注意得到的。你突然觉得，正是因为TDD本身过于强调测试的价值所在，让你忽略软件开发中很重要的部分：设计。

思路一下子清楚起来，TDD其实不只是“红——绿——重构”，它还是与设计相关的：在动手之前，还是要有一定的设计，而且，在设计中要考虑测试的问题。终于解开了心中的困惑，现在的你，对于TDD有了一个新的认识，虽然这个认识不见得是什么终极真理，但至少是通过自己的思考得来的，这让你更加相信实践出真知的道理。

理清思路后，你更加坚信TDD本身的价值所在，也坚定了在日后开发中继续使用TDD的念头，当然，目光远大的你已经盯上了其它的敏捷实践。

第一步：

安装DirectX SDK(June 2008)和Microsoft Visual Studio 2005

 

第二步：

设置DirectX和Visual Studio 2005关联：
<1> 打开Visual Studio 2005，将D3D需要的Lib 文件目录在链接器中指定路径。具体步骤是：工具->选项->项目和解决方案->VC++目录，在右边“显示以下内容的目录”中选择“包含文件”，加入directx中的Include目录，我电脑上的该目录为D:\program files\directx9\Include。添加完Include头文件后，再

选择库文件，加入lib文件，我电脑上的该目录为D:\program files\directx9\Lib\x86
<2> 打开sdk的sample里面的一个例子，打开时打开.sln文件，引用几个相关的lib文件，具体步骤是：项目->属性->配置属性->链接器->输入,在附加依赖项里面加入下面几个lib文件:

d3dxof.lib

dxguid.lib

d3dx9d.lib

d3d9.lib

winmm.lib

 

第三步：

设置好后，就可以执行程序了，调试->开始执行(不调试)。

 

注： 若出现打不开预编译头文件的错误，就如下设置：项目->属性->配置属性->C/C++->预编译头，右边第一项“创建/使用预编译头”选择“不使用预编译头”。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/KEIGOliye/archive/2009/08/24/4479134.aspx

[如果你在做游戏时已发现Scrum敏捷开发的价值,专家Clinto Keith向你概述精益和看板,使你在所有游戏开发阶段变得敏捷的两种方法.]

 

许多游戏团队发现Scrum的价值后就迅速采用.引入的价值是提高了速度,游戏以一个经常反复的速度提示项目主题.并让团队和用户频繁地通过改善游戏来相互反应.然而当团队进入制作阶段,发现Scrum的价值减少了.

 

许多团队在项目生命周期的晚期放弃了一些Scrum实践又回到传统的瀑布实践方式.他们称这种方法为”Scrum和瀑布的混合”.这篇文章将解释背后的原因及引入一些精益制作及看板的概念作为采用瀑布实践的替代方法.

 

精益和看板可以回答许多团队使用Scrum面临的问题,而且它们不需要团队放弃敏捷的方法.这些实践方法基于真实世界的产品制作经验,它们改进了56%的关卡制作成本.

 

在游戏业以外的大部分敏捷项目中,没有开发阶段.没有概念(concept)阶段,没有预制作(pre-production)阶段或制作(production)阶段.这些项目从发行（release）开始，每个发行发布一个新版本给客户，比如Firefox这样的应用程序每一个月左右发行一个新版本。而大部分游戏需要几年后才拿到一个发行版本。

 

消除（Eliminating）阶段是一个很大的敏捷好处；瀑布阶段比如测试阶段强迫测试关键活动被推迟到项目最后的话，这样修复臭虫（fixing bugs）的成本会很高。在项目开始的规划（planning）阶段尝试创建关于什么功能是有趣的及创建关联工作的详细知识。不幸的是最好的知识来自于执行，这就是为什么非常详细的预先规划（pre-planning）会失败。

 

对于许多游戏，在游戏制作过程中仍然需要分不同阶段。有两大原因：

 

被交付的无论什么质量的内容有个起码的底线。 60美元的游戏必须提供8至12小时的游戏。这代表了大部分的开发成本和由游戏性产生的时间。这需要一个预制作阶段（pre-production phase ）用于发现游戏乐趣及一个制作阶段（production phase）用于大规模制作内容，为了8到12个小时的游戏体验。

 

发行商有一个投资组合驱动的市场模型。他们的投资制约了游戏的目标.为了获得发行商的审批（其中包括市场及特许经营/知识产权所有权的审批），开发商在项目开始的概念阶段（concept phase）需要创建一个详细的概念论述。之后开发商不能太偏离整个项目的设想。

 

预制作可更自由地反复进行创意设计及探索各种可能性。制作期间，我们创建数以千计的资产依赖于我们在预制作阶段所发现的经验教训。这些资产在制作阶段变更会发生成本障碍。

 

例如，考虑一个团队在制作一个平台类型的游戏。平台游戏（如任天堂的马里奥系列）挑战玩家用于开发在变化莫测的环境中的导航技能。制作团队将创建数以百计的资产取决于角色移动指标，如“角色能跳多高”或“玩家能抓取的最低高度”。制作资产取决于这些指标。

 

如果这些指标在制作中期被变更，它可能会造成严重破坏。例如，如果设计人员变更了角色跳跃高度，数以百计的暗礁或障碍不得不被修改。这可能使在最昂贵的开发阶段创建了大量的无用付出。

 

在预制作阶段发现和锁定这些指标是很关键的。这并不意味着我们不能在制作过程中使用敏捷。我们如何才能不改变敏捷。用更适用更渐进式的流程（如精益）代替使用迭代和渐进的流程（如Scrum）

 

冲刺和制作

 

资产创造的确定性和顺序工作，也不符合冲刺迭代周期。如果我们把制作想象成工厂组装生产线，那么2到4周迭代周期是没有意义的。工厂不会每隔四周后空下来再决定将来构建什么东西。

 

组装生产线更频繁的复制产品需要即时逐步改进。完成资产复制的生产线时间成为制作团队的新节拍.

 

Scrum任务公告板及制作团队

 

冲刺开始时，Scrum团队将提交一份由他们预估的完整任务集。这些任务集被放在任务公告板上，供每人每天复查。许多任务可以顺序工作或并行工作。

 

如果一个任务在等另一个任务，就可以继续做其他的任务。有组织的任务执行流程将促进团队沟通并防止他们停滞。Scrum任务公告板正很好地表示了为了各个冲刺目标，大量在被顺序执行的任务。

 

然而当我们有一长串序列的任务必须按顺序完成那么我们失去一些并行执行任务的好处。任务必须按顺序完成，工作必须经一个可预见方式的流动，用于确保制作团队中的许多专家不在等待工作。Scrum任务公告板不能用于表示很长制作流水线的工作流。

 

 

Scrum任务公告板用3到4个任务状态表示

- 还未开始（Not started yet）
- 进行中（In progress） 
- 需要审批（Needs approval） 
- 完成（Done） 

 

这些在预制作阶段足够了。在任务进行中实际上在不同工种间有许多来回，这是正常的。然而当我们进入制作阶段，在游戏中看到一些制作完成的资产之前可能有一个长的任务链。例如，出现在游戏中的一个单一关卡需要发生如下的步骤。

 

 

 

这是一个大量任务的简化及发生在每个游戏关卡制作中的递交（hand-offs）过程。这个流程中的每个任务在它递交给下一个前必须发生。

 

如果在工作流中有一个步骤失败或延误，将影响到整个工作流中剩下的其他几个步骤。让我们套用一个任务公告板为一组任务:

 

 

以上任务公告板告诉我们剧本（script）完成后概念美术（concept art）要在关卡设计前完成审批。立即显现出一个问题—整个工作流交叉依赖的可见性没有在任务公告板上被表示出来。也许概念美术审批已被停滞了。

 

对其它任务这意味着什么？这意味着它们都被延迟了！谁来为延迟买单？正在做调整的人，或许甚至是音频设计的人。任务公告板主要的好处是给团队提供他们正在操刀的任务的可见度。在这个案例中工作流因为内部依赖性而失去了可见度。

 

Scrum任务公告板上表示工作流的另一个问题是：

当第一组任务正在被执行时，后续的工作是什么？音频设计者在概念美术等待审批时在做什么？

他们可以创造环境的声音或者一些填充者工作，但这没有最有效地使用他们的时间。Scrum任务公告板在每个冲刺（Sprint）结束时被清空。制作中，我们不想清空制作线。我们希望能持续地填充，使工作流中的每个人每天有工作做。

 

那如何在制作阶段使用敏捷？

 

我们需要删除一些迭代开发特征并在制作期间变得更规范。但我们不想放弃对变更的反应能力，制作从来没有100%的效率。

我们永远不能预测每一个潜在的问题。我们有找到大量改善产品的权力直到游戏发卖。因此我们不想完全放弃敏捷。

 

如果我们设定了固定时间表（schedules）和最后期限（deadlines）。我们希望的最好结果是匹配时间表。无计划的问题将继续出现并威胁这些时间表。我们需要的仍然是敏捷实践；实践的期望不仅关注变更而且把注意力集中在不断提高我们制作的资产品质。

 

精益制作及如何应用

 

精益开发与制作的根源可追溯到20世纪40年代的丰田（Toyota）。在20世纪90年代，许多汽车制作商和其他制造行业都采用了精益原则的思想。

 

过去十年中，在不被考虑的传统制造行业领域,包括软件开发的许多行业中都看到了它的运用。精益原则集中精力消除浪费，快速发布，增强团队及全局控制（其他好处—见文章结尾的参考书籍）

 

我们也可以把这些原则应用到游戏开发。像汽车制造业一样，在制作中我们有一个长长的工作链或工作流，需要一些专家按顺序工作。

 

像汽车制作也一样，劳动力成本及错误是迄今为止最大的成本。我们需要录用覆盖”制造线上”所需技能的每个人来提高我们制作及设计能力。汽车业几十年前发现的，指派生产线上每个人以完成一套固定的任务并没有达到最好的效果。

 

平整制作

 

平整制作是一种精益技术用于减少浪费及理顺制作中的波动。这使我们以恒定可预见的节拍创建制作资产。

制作中我们花的大部分时间是无用工（或活动），这些成果不会添加到最终产品。通过我们的努力专注减少这些无用工，我们可以得到一个巨大的生产力的提高。

 

看板

 

凡使用Scrum的会使用一个简单的看板系统。日语中单词Kan意思是“信号”，ban意思是“卡片”。因此kanban是指“信号卡片”。看板是工作的“牵引系统”。

 

一张看板卡片是一个触发行动的信号。看板随处可见。当你下一次在星巴克喝咖啡时你可以看到一个适当的看板系统！

在Scrum中，每个团队成员每天基于完成工作在板上“推拉”一张卡片。没有人在按预定义的节拍推动工作。

 

我们可以选用一些看板实践方法，这些用来可视化一个复杂制作流程并让我们运用精益原则使制作流程尽可能有效率。

 

平准化(均衡化)公告板

 

一个平准化公告板是使用卡片来表示工作能力及整个工作流程的价值流的看板系统。

 

如上所述，当你使用Scrum任务公告板时，你正在使用一个非常简化的平准化公告板来表示一个3到4个阶段的价值流。我们可以通过增加步骤来扩大制作规模，以我们关卡制作的价值流为例：

 

 

现在我们有8个状态用于每个关卡，它们代表了价值流的6个阶段及在两端关卡制作没有开始和关卡制作完成的两个状态。在平准化公告板上旋转典型的任务流程使之变为状态。

 

该公告板在关卡制作中对于工作流程的沟通比Scrum任务公告板更清晰。

 

应用精益原则

 

现在我们已经展现了关卡制作的价值流，我们可以开始应用一些精益原则来逐步提高关卡制作。第一步我们需要审视价值流的周期时间。

 

周期时间是从左边剧本（script）作业开始到调整阶段（Tuning Pass）完成的总共时间。我们的例子，以上一个关卡需要16周的周期时间。通过减少周期时间使我们可以更有效率。

-更快的周期时间意味着更高的生产力。 
-东西下线越频繁，我们就越能解决制作生产线的问题。 

-我们可以更容易地找出浪费（无用工）及解决这些问题。 

 

有许多方法用来减少周期时间。第一个方法是通过缩小工作流中工作项规模。对于我们关卡制作的例子来说，我们可以通过把关卡分割成部分或区域。

 

每个区域大约花12天才能通过价值流—而不是每个关卡16周。因此，我们平准化公告板看上去像以下这样：

 

一个平准化公告板显示了一个区域通过价值流每个阶段的过程。在上面的例子中，区域1通过了每个阶段并被转交到结束时最后调整阶段。该公告板表现了完美地平衡跨越价值流每一步的工作流。

 

最初它不会以这种方式发生。在某些列中会出现断层而在其它列中出现工作堆积，但这样做：这些问题一旦发生能马上可见，当我们发现了问题的本质后，就可以开始修复清楚地看到的问题。

 

如何改善流程

 

现在我们有一个看板并在运行中，我们必须努力使其尽可能有效。平准化公告板将每天告诉我们,在我们的工作流程中哪里有断层哪里有工作堆积。我们不仅希望保持平衡而且希望工作流动尽可能迅速。

 

我们的例子中，如果每个区域需要12天才能通过整个价值流，我们要想方设法减少周期时间直到我们在不牺牲用户可接受最低水平的品质。

 

我们有一些工具来改善流程：

    - 时间盒      
    - 平整工作流 
    - 减少浪费  

 

时间盒

 

时间盒是每个使用Scrum的开发者工具，一次冲刺是一个2到4周的时间盒。在一次冲刺中我们坚持并且只有我们能提供的功能。这样的好处是创建一个价值能被加入游戏的可预见的节拍。

 

在制作中，我们借此又向前迈进了一步。我们在价值流每个阶段启动时间盒。例如，我们可能给音频设计师10天给一个特定区域添加声音。这和Scrum任务中不同之处在于音频设计人员将预估自己的工作并告诉客户他们愿意的承诺。

 

在制作中这种变化，因为我们在预制作中了解了给一个区域音频设计应该需要多少时间。品质变成了你用时间盒资产控制的变量。我们不强迫美术在一个规定时间内满足一套质量。

 

输入是时间盒（我们愿意为这些资产支付的成本），输出是品质，这是美术在一个限定时间内能提供的。

 

时间盒资产的关键是找到一个正确的时间盒大小。如果你选了一个太短的时间盒，那么品质会有问题。例如，如果高解像度关卡几何的时间盒设定为一天，那美术将给我们一个用没有贴图的方块填充的关卡！这肯定比用户想要的品质低。

 

另一方面，如果给区域的时间盒是2个月，我们最终可能会是一个到处错综复杂的详细几何区域。这绝对是漂亮的，但对用户来说带来的成本太高了。这是用户（Scrum中产品拥有者）的工作以创建的制作资产来对投资回报率（ROI）负责。

 

产品拥有者必须考虑玩家对游戏资产的期望。当我工作在一个开车游戏时，我会告诉我们的美术要把重点放在决策“90英里每小时的艺术”。质量条应基于玩家在全速驾驶看到的设置。如果我们陷入40小时创建一个完美的灭火器，这额外的成本将在玩家以90英里每小时穿过时被浪费！

 

产品拥有者必须始终在他脑子里保持成本/价值曲线。

 

以上表示用户价值不是直接反映创建资产的成本.当你在资产(如方块堆成的城市)上花太少投入,用户价值就会太低.玩家可能会注意到路边假装消防栓的黄色方块.

 

超过一定成本,投资回报也将会减少(如在一个开车游戏做一个1000面的消防栓).我们不是把品质关联到成本.而是用户价值关联到我们付出的努力.我们不想”给想要巨无霸的用户提供鱼子酱”.

 

 

平整工作流

 

时间盒使我们录用一个非常强大的看板.每列的卡片表示价值流每个阶段的工作能力.正如我们以上所看到的,每个阶段一次只能处理一个区域.这就是每个阶段的工作能力,如果我们在每个阶段只有一个人在工作.

 

时间盒是为价值流开始寻找平衡的工作流程的第一步.然而存在一个问题,在这个流程中每个阶段的付出需要是不同长度的时间盒.这可能导致工作断层和堆积.

 

例如,如果我们的关卡设计师一周内布局了一个关卡,但高解析度美术师需要两周,那么对高解像度美术可能有许多工作堆积.反之,如果原画设计师需要2周完成每个区域的原画美术,那关卡设计师可能正在等工作,无事可做:

 

我们必须找到方法来平衡工作流,使每个人每天有事可做.一个方法是平衡每个阶段的付出以实现整个系统同样的工作流程.

例如,如果我们想使一个区域在10天内通过工作流程,我们开始寻找团队每个成员工作每个阶段的时间盒的付出

阶段(Stage)
 每区域人天(People days per zone)
 
剧本(Script)
 5 days
 
概念(Concept)
 10 days
 
关卡设计(Level design)
 20 days
 
高解像度美术(Hi-res art)
 30 days
 
音频设计(Audio design)
 10 days
 
调整阶段(Tuning pass)
 7 days
 

 

概念美术师和音频设计师需要10天,每区域10天很符合我们的周期时间.然而其它几个阶段需要的时间是不同的.剧本和调整要低于每阶段10天.剧本作家也许必须帮助两个团队.在调整阶段的设计人员可以帮助关卡设计或甚至测试.

 

对那些超过每区域10天的阶段,我们需要开始加人用并行来缩短时间.例如,我们可以增加第二个关卡设计师.两个关卡设计师可能有效地在10天内完成一个区域.

 

由于高解像度美术师需要每区域30天,我们也许必须用3个高解像度来平衡我们的工作流.有三种不同方法用于加人来解决问题

1.    多个高解像度美术师可以同时工作在同一个区域.

2.    细分高解像度阶段为更详细的特定工作流程(如贴图美术,道具美术,静态几何美术)

3.    多个高解像度美术师并行工作在不同区域.

所有这些方案工作在不同情况下的.方案1不是最好的因为我们的关卡编辑工具不支持同时在一个区域编辑.方案2不是最好的是因为这个特定的工作流也不是平衡的.

 

而且我们已经完成大部分贴图和道具.我们选择方案3.每个高解像度美术师仍然需要每区域30天,但工作被错开使整个高解像度工作在每10天完成.

 

我们的平准化公告板看上去如下:

 

每个人有一个区域的制作能力.通过增加关卡设计师和高解像度美术师,我们可以在每个阶段添加更多的卡片,因为我们需要加更多的制作能力.

 

我们现在设立了一个时钟频率,它是对关卡制作的每个阶段是相同的.这个时钟频率(我们的例子中是10天)被称为”节拍时间”.通过维护甚至改善整个价值流的节拍时间,我们平整制作及真正有效改善我们解决的浪费.

 

减少浪费

 

我们可能很高兴地在这里止步了.我们已经有一个适度平衡及可预见的制作流水线.许多开发商将满足现状.然而精益制作的工具使我们可以走得更远！

 

首先精益的原则是减少浪费.我们已解决许多在设立平准化公告板后标记出来的浪费,但我想强调一些其它特别针对游戏制作的方面.

 

许多这些浪费可以被团队自己标记和纠正.这是理想的消除浪费方法.主要的工具是时间盒.时间盒在团队找方法使其更有效时将产生微妙的压力.在我们上述例子中,我们确定一个周期时间是10天及平衡整个工作流来改善效率.

 

当产品所有者要求团队减少周期时间到9天会发生什么事?我们将失去10%的资产价值.令人惊讶的是我们不.第一反应是紧缩周期时间,如果对团队来说消除效率低下的工作方法.

 

让我们使用一个真实的例子.一个制作项目,在关卡制作中区域制作的周期时间是10天.当他们想减少20%的周期时间,他们面临了一些瓶颈.

 

最大的瓶颈是概念设计阶段.他们只有一个可用的原画美树师,并且该原画美术师和其它原画美术师坐在一起.该原画美术师花10天来给每个区域创建十来个图纸.没有其它方法使更快地获得这些原画图纸.

 

在小组讨论中抖出关卡设计师和高解像度美术师并没有真的需要所有这些图纸.因为原画设计师是个分离的团队,许多概念设计是基于错误的假设.概念美术师不喜欢听到他大部分工作被忽略.

 

方案是把这个概念美术师移到关卡设计师和高解像度美术师的旁边.这样让他们讨论设计图及正在完成工作的质量条.因此,少得多的图纸,这需要加以创造及实际改善最终产品.

 

这是一个工作递交产生浪费的例子(由精益原则定义的7个浪费之一).文档是一个移交浪费主要源头.文档的作用是记录知识.但它不能代替面对面的交谈.通过在工作流每个移交处使用这种方法,该团队在跨越每个阶段时同样可以节省时间.团队座位区应根据平准化公告板本身重新安排.

 

在上述例子中,团队从16周制作一个关卡变为每周制作一个区域,每个关卡7个区域,最终的改善是关卡制作的成本改进了56%.

 

改善品质

 

注重品质是精益制作的原则.精益制作是最大限度地减少价值流中每个阶段无需完成的工作.这使得变更被引入的更频繁,因为这将无用组件的债务保持很低.

 

这是丰田等汽车公司提高汽车品质并主导市场的关键.如果你在汽车生产部分发现一个缺陷,它将很容易引入一个改进部分当没有大量旧零件在库存时.

 

这个理念也可以转化到装配线.在丰田工厂车间,如果任何一个装配线工人看到有缺陷的车他就会按下附近的一个大按钮.如果那个问题不能在随后的20分钟内修复的话,整个工厂装配线马上停止直到问题被修复.这对品质的贡献是其它公司所不能比拟的,通过使用精益制作原则使之成为可能.

 

此外,我们通过整理完成制作的批次来减少周期时间.我们改进了迭代的周期.用我们的例子,我们可以每周玩到完成的区域像他们”复制出制作流水线”

 

我们不必等16周,整个关卡完成后才能玩.这一周的循环使我们更快地体验关卡并在我们决定花许多时间来创建关卡区域的剩余工作前引入变更.

 

如果我们并行建造所有的关卡而且直到工作完成了90%后才发现问题(如渲染或内存预算或游戏性品质)我们将要面对不得不抛弃已完成的大量工作或者发卖低品质的工作以满足最后期限.汽车企业当它们决定扔掉库存中大量有缺陷的部件,也是同样的问题.

 

外包

 

外包在资产制作中有其好处和地位.然而许多工作室已发现外包限制了迭代的次数,这些发生在创建大量资产如关键角色或关卡.有限迭代会影响到品质或引入昂贵的返工,这些限制了外包的成本收益.

 

精益制作方式演变成和外部供应商一起工作.这些对制造业如汽车制造都是必不可少的.供应商成为精益制作公司必须要自己变得精益.和精益供应商不同的关键是他们给主要制作线提供小批量零件.这样做是为了以较低成本提高品质

 

如何转化到游戏制作?我们的例子,我们不想外包整个价值流.关键是外包整个价值流中不需要高技能的部分,高技能部分就留给自己做.一般在关卡制作中,你想在工作室内能够保持大的任务布局而且外包也是被用于布局中的几个部分.

 

这个例子是一般整个关卡的环境集或资产集合.如果你在创建一个大城市的关卡,你将外包所有的小物如灯箱海报,油箱,车辆,建筑构件,背景音乐等等.这些环境集将被带进设计图阶段(高解像度美术和音频设计).这可以让他们在自己的工作室继续设计图迭代.

我们外包的关卡制作价值流如下:

 

外包资产在早期关卡概念开发阶段被确定给外包足够的交货期.许多设计工具支持异步引入外包组件.一个例子是Unreal Engine 3编辑器.数据包系统可以用代理资产,这些可以被一次自动替换整个游戏资产的所有实例.

 

如果其他团队仍在使用Scrum?

 

制作期间,不是所有的迭代都没有用.团队仍然在不影响制作的领域进行游戏创新.对这些团队冲刺仍然是有价值的.这些组如何和使用看板的组一起工作?

 

Scrum团队仍然可以使用看板驱动制作.如果我们在一个4周冲刺内有一周的周期时间,制作团队仍然可以显示每冲刺4个周期的审查结果.制作团队不必作冲刺计划,但他们仍然需要定期回顾.另外每日Scrum对制作队员仍然是个有用的实践.仍然会出现障碍这需要由团队解决.

 

结论

 

逐步地使用这些实践方法来创建关卡资产.制作一个简单游戏关卡的成本从16周变成了7周(7个区域*1周/区域).这表示改进了创建一个关卡成本的56%并且只需非常简单的工具或技术就能达到.

 

这只是一个开始.精益制作表明改进可以用外包代替或扩充工作室可能想自己做的大量关键资产工作的外包需求。

 

像Scrum一样,采用并精益实践要根据你自己的环境进行调整.关键是获取过程的可见度并创建有意义的指标.时间盒资产创建是有挑战的.大部分美术人员在工作中没有把品质作为一个变量考虑.产品所有者的关键作用将其远景不仅是最终的产品也要有责任控制投资回报率.

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Guo_zanhua/archive/2008/11/17/3321368.aspx