【转】网络即时战略游戏软件开发 结构体系分析

文档下载地址：http://download.csdn.net/detail/wanggan768q/4388056

 

网络即时战略游戏软件开发

结构体系分析

 

前言

本人对网络游戏的技术问题一直比较感兴趣，我认为网络游戏的开发在不远的未来是一个很是庞大的产业。这段时间有空，特意玩了几天网络游戏“破碎银行系”，并分析了一下其中体系结构，有些体会，结合本身多年的软件开发经验，就如何开发一个相似于“破碎银行系”的网络即时战略游戏撰文以下，但愿能抛砖引玉，对从事游戏开发的人有所帮助。

网络游戏是咱们的机会

单人游戏的开发国外厂商已经积累了丰富的技术基础，各类游戏模式已经基本定型，新款游戏只能在视、听觉的效果上大作文章，主要的竞争领域是3D技术和美工，在这些方面，咱们要一会儿遇上国外的技术水平还有必定难度。

而网络游戏，其吸引人的地方是多人的交互性和协做性，视听觉效果的做用已经退到次要的位置，例如“破碎银行系”，玩家所但愿的是在上面打一场玩家紧密配合，最后成功打败对方的“国战”，没人关注它是2D仍是3D的。

网络游戏，须要引入新的技术，如数据库、通讯和服务器端软件的开发，这些技术在国内其它领域（如金融和电信）已经获得至关成熟的应用，并不存在任何技术问题，加上2D游戏的开发，国内成功案例较多，所以，只要把国内的资源有效地组织起来，就能开发一个富有市场前景的网络游戏。

许多人会认为网络游戏的开发是一件技术难度很是高的工做，固然，游戏的开发，其它技术含量要比一个信息管理系统高，但并非遥不可及，我更愿意用“开发网络游戏是一个系统工程”这样的观点形容网络游戏的开发。

本文的主要内容之一即是分析如何把一个功能复杂的网络即时战略游戏，划分为多个尽可能孤立的子系统，并逐一分析每一个子系统的技术特色和难点。

游戏功能模块分析

在“破碎银行系”中，可把它的功能划分为如下几类：

1、 交流或做战状态的地图漫游；

2、 属性设定；

3、 聊天；

在地图漫游功能，又分为如下几类：

² 交流状态，多人在线的地图漫游；

² 战斗状态，多人在线，人与人之间的战斗，如“国战”、“竞技场”等；

² 战斗状态，多人在线，人与计算机之间的战斗，如“异形战争”；

² 战斗状态，单人游戏，人与计算机之间的战斗，如“训练场”；

每一个多人在线的地图，都须要一台服务器管理，咱们把台服务器称之为地图服务器。

在“破碎银行系”中，同一交流状态地图能够同时容纳128名在线用户，而战斗状态地图则能够同时容纳64名在线用户。

许多功能，如注册、登陆、购买武器、修复武器、武器升级、武器物品装备、加入军团、选举领主、拜师和系统内信件等，其实均可以纳入属性设定一类的功能，其实质很简单，都是查询或修改数据库中，关于玩家的某些记录。例如拜师，其实就是修改玩家眷性数据库中，其上级的字段。

在Internet环境下，客户端（即玩家使用的PC，如下称为游戏端）不可能直接访问数据库服务器，必须经过联机交易这种方式实现。

联机交易首先在金融等行业获得应用，如今全部的核心金融应用系统，都基于联机交易，并且，联机交易已经普遍地应用于其它各个领域中。

联机交易是指客户端根据实际功能的须要，按照规定的格式填写一个数据结构（称之为交易请求报文），而后经过计算机通讯发给交易服务器；

交易服务器收收交易请求报文后，执行相应的数据处理工做，多为数据库操做，并把处理结果按照规定的格式填写响应数据结构（称之为交易响应报文），而后发给客户端，通知客户端处理结果。

在游戏软件中，一个属性设定功能，就是一个联机交易，只不过是把操做界面图形化、游戏化而。

这里咱们把交易服务器端称为属性服务器。

若是玩家常用系统内信件的功能，则有必要让系统内信件功能单独使用一台服务器。

聊天的实现与ICQ相似，也须要一台服务器（至少逻辑上），我把这台服务器称之聊天服务器。

有一种考虑，就是把聊天服务器合并在地图服务器上，这是由于聊天的对象通常都是同一个地图上的人，但某些状况例如，如领主和军团长能够经过“大喊”功能跨地图，把指令发布到整个星球，而上下级之间的聊天也能够跨地图。

所以，同一地图的聊天可在地图服务器中增长一个聊天模块处理，整个游戏分区还应设立一台专用的聊天服务器，处理跨地图的聊天功能。

服务器组织

    毫无疑问，游戏端使用Windows平台，使用Wins32 API，服务器则最好使用Linux操做系统。

系统服务器分为两类，数据库服务器和通讯数据报文处理服务器。

数据库服务器从稳定性、价格和性能出发，最好选择Oracle，版本不限。Oracle的稳定性和性能自不用多说，而其For Linux的版本，最低价格不到8000元（从分销商那出货），也是很是便宜的。

在“破碎银行系”中，一个游戏分区能够由多个星球，每一个昨星球有多张地图，所以，其服务器组的结构能够是这样：

每个星球大概有100张地图，能够经过动态分配、一台物理服务器运行多个交流地图服务器等方式，减小真正须要的服务器。

由于地图服务器能够动态增长，所以一个分区同支持的用户数取决于属性服务器和聊天服务器。

其实属性服务器的主要操做是数据库操做，其性能又取决于数据库服务器，根据个人经验，一台较好的数据库服务器，每秒种能够处理100笔以上的联机交易，也就是说每秒种能够处理100次属性设定请求，根据我玩“破碎银行系”的经验，属性设定的执行频率不到10分钟每次，那么一个分区能够同时支持60000个在线用户。

由于跨地图聊天的执行频率很低，所以聊天服务器不会成为系统的性能瓶颈。

    系统须要的服务器总数取决地图服务器，一台地图服务器同时支持64至128在线用户，但不可能老是满员，因些，若是须要同时支持5000在线用户，可能须要100台左右地图服务器。

战斗地图漫游游戏引擎的设计

多人在线的战斗地图漫游是整个游戏开发的难点，其它类型的地图漫游均可以视做这种漫游的的简化。在这里，我提出一个战斗地图漫游游戏引擎的设计方案，其要点是：

1、 参照面向对象开发语言的特色，采用数据驱动的程序结构，首先定义一系列全局的数据结构，这个数据结构能够表达整个游戏的状态，包括地图的形态、武器的状态、当前玩家的操做等，其它全部模块都围绕这些数据结构实现。下面把这个数据结构称之为核心结构。

这种程序结构与面向对象的类类似，这里没有采用面向对象的缘由是：核心结构是全局的，引擎的模块都围绕核结构开发，跨度很是大：在游戏端，核心结构必须以全局变量方式实现，供多个线索同时访问；在地图服务器端，核心结构必须放在共享内存中，供不一样的进程同时访问。

这样，面向对象的开发模式很难知足这样的需求，此外，这里也没有必要使用使用继承、重载等面向对象开发模式独有的特性，因些没有必要使用面向对象的开发方式（注：这里只是说核心结构及其操做模块没有对象化，并非说其它地方限制面向对象方式的使用）；

2、 按照模块的功能分类，不一样的模块尽量单独在一个线索（游戏端）或进程（服务器端）运行，这些模块包括：

² 操纵；

² 通讯；

² 核心结构计算；

² 音效表达；

² 视觉效果表示；

² 聊天；

3、 由服务器发出统一节拍（每一节拍大概从0.5秒到1秒之间），全部在线游戏端都按照这个节拍运行。

整个引擎结构以下：

流程分析以下：

1、 游戏端控制线索把最新的操做指令写入本人操做指令的变量中；

2、 游戏端核心计算线索计算结束后，向同步通讯线索发出通讯指令（经过互拆对象实现）；

3、 同步通讯线索收到通讯指令后，把节拍ID、核心数据结构校验码、本人的操做指令以通讯报文（下称上行同步包）方式发给图形服务器；

4、 服务器的同步通讯进程收到来自不一样游戏端的上行同步包后，首先检查节拍ID、核心数据结构校验码是否与服务器中的数据一致，不然通知游戏端出现同步问题，是则把各游戏端上传的上行同步包中的操做指令记入操做指令数组中，操做指令数组聚集全部线用户在同一节拍的操做指令；

5、 节拍时间到了以后，服务器核心计算进程向同步通讯进程发出停止接收上行同步包的指令；

6、 若是同步通讯进程收到停止指令后收到上行同步包，则通知对方通讯出现同步问题，并不把指令记入核心结构中；

7、 服务器核心计算线索计算核心结构，生成一个校验码，向同步通讯进程发出计算结束指令；

8、 同步通讯进程收到计算结束指令后，则把下一节拍ID、操纵队列结构数组、校验码（这组数据下面称之为下行同步包）发给全部的游戏端，；

9、 游戏端同步通讯线索收到下行同步包，把操做指令数组记入核心结构，通知核心计算线索计算核心结构；

10、 核心计算线索以操做指令数组为输入，从新计算核心结构和校验码，并和服务器计算校验码比较，若是不一致，出现认为计算同步问题，启动同步恢复过程，若是一致，则通知通讯线索上传数据，执行下一节拍；

11、 音效和视觉效果表达线索能够以核心结构为输入，按照本身的节拍运行。

12、 聊天时，非跨地图的信息发送至地图服务器的聊天通讯服务进程，并记入聊天即时信息记录，若是是跨地图信息，则直接发至专用的聊天服务器；

十3、 服务器中运行一个跨地图聊天信息获取进程，专门从专用聊天服务器取出发至本地图的跨地图聊天信息，而后记入聊天即时信息记录中。

十4、 不管是否跨地图，游戏端接收的信息都来自地图服务顺的聊天服务程序。这样的设计目的是减轻专用聊天服务器的负担。聊天没有同步要求。

经过以上流程，整个系统，包括服务器和全部的游戏端，都按照统一的节拍运行，并保证其核心结构是一致的。若是游戏中，玩家的游戏端出现同步问题，首先同步回复过程尝试恢复同步，若是恢复失败，则必须做掉线处理。

因为核心结构的信息量很大，在每一个节拍中传递整个核心结构确定是不可行的。在“破碎银行系”中，无论玩家的网速是多少，正常状况下游戏的响应速度都很好，但当一个新的玩家加入时，整个系统会停顿下来，有时时间很长，多达1分钟之久，玩家称之为“卡”。

产生“卡”的缘由很简单，就是全部的玩家的操做必须停下来，得到一份一致的核心结构，而后把核心结构传递给新加入的玩家的游戏端。

“卡”的现象很值得分析，“卡”的时候，玩家能够正常聊天，大地图和缩小地图滚动正常，说明“破碎银行系”也采起了聊天、视觉表达系统与核心结构的同步系统相分离的设计方法。

视听觉表达系统与核心结构相分离，按照本身的节拍运行，可能会致使不一样的游戏端的显示和音响不一样，但这不会影响游戏的运行，致使不一致的游戏结果。

节拍间距和最大在线用户分析

在一个节拍的间距中，整个系统必须完成的任务有：

1、 游戏端向服务器传递一个上行同步包；

2、 服务器向游戏端传递一个下行同步包；

3、 游戏端和服务器各执行一次核心计算。

节拍间距的调整是个很是关键的问题，太长的间距影响游戏的流畅性，过短致使了某些网速慢的游戏端的同步困难。

在“破碎银行系”中，若是快速操做，1秒种能够执行2个以上的操做，能够看到除第1个操做获得执行外，其他操做被忽略，也就是说，“破碎银行系”的节拍间距是1秒左右。

在玩“破碎银行系”的过程当中，我以为操做不是太顺畅，若是把节拍设为0.5秒会好一点。至于更短的值可能没有必要，由于人的操做频率通常不会每秒2个。

同一个地图在线用户的增长，从两个方面影响性能：

1、 核心结构信息量增长，致使计算量的增长；

2、 下行同步包必须包含操做指令数组信息量更大。

通常认为，运算速度不会成为系统的性能瓶劲，下行同步包确定要大于上行同步包（只有一个操做指令），一张地图支持的最大用户数取决于下行同步包的大小和通讯速度。

下行同步包中，每一个操做指令的信息量大概为：

² 操做涉及的武器，1个武器1Bit，每1位表示该序号的武器是否被选中。“破碎银行系”每一个玩家最多只能操纵6件武器参战，也就说须要1个字节。

² 指令类型，1个字节；

² 指令参数（如移动指令的目标，鼠标点在地图上的位置）两个整形，4个字节；

也就是说每增长1个在线用户，下行同步包须要增长6个字节的通讯量。

若是下行同步包中其它信息为32个，最大在线用户数为128，那么每一个下行同步包的报文长度为32+6*128=800字节。

游戏中，人不可能不停地发出指令，大部分时间应该处于空闲状态，这时候可用一个字节0表示空操做指令，0表示没有选中武器，没有选择武器没是没有操做。经过上述压缩方法，把下行同步包数据通讯报文限制在576字节如下应该没有问题。576字节是128K如下的PPP协议（即拨号上网）的最大包的字节数。数据在网络中传递所须要的时间是按照包来计算的，更低的值没有意义。

游戏端使用56K 的拨号上网，通讯有效率为50%，那么每秒可传递3500字节。例如拨号上网下载文件时，下载速度通常是3K至4K。说明节拍间距0.5秒、128个同时在线用户的性能参数还必定的挖掘空间。

除下行同步包外，游戏端还必须向服务器传递一个上行同步包，因为网络有一个“双工”，即同时双向会传输的特性，加上信息确定小于下行同步包，系统主要仍是受下行同步包的影响。

玩家进入交流地图时，并不会出现“卡”的现象，这是由于交流地图的核心结构很小，只须要记录在线用户的用户名、图标号和在地图的座标便可。能够经过一些压缩算法，实现“无等待加入地图”。

聊天模块的实现

    聊天模块包括几个子模块，包括：

² 跨地图聊天服务器

² 聊天数据发送线索

² 聊天服务进程

² 跨地图聊天信息获取进程

此外还有部分功能混集在其它模块中，整个聊天模块的流程为：

1、 在游戏端，“操纵控制线索”收到发出聊天信息命令，把数据写入“待发聊天信息”的数据结构中，向“聊天数据发送线索”发出一个Windows消息；

2、 “聊天数据发送线索”收到Windows消息后，检查待发聊天信息，若是发出的信息是跨地图，则创建一个与“跨地图聊天服务器” （服务器地址在登陆时获取，使用约定的端口号）的TCP链接，若是发出的信息是本地图，则链接地图服务器，链接成功后发送数据，而后关闭链接，回到接收消息的状态；

3、 聊天数据发送线索可以使用阻塞机制发送聊天数据，使用阻塞机制时，必须从新安装一个阻塞处理的钩子函数，控制通讯超时时间；

4、 在地图服务器启动一个聊天服务进程，负责接收来自游戏端的数据，收到后写入“聊天信息记录”，须要在地图服务器开辟一块共享内存的空间，专门记录“聊天信息记录”；

5、 在地图服务器启动一个“跨地图聊天信息获取进程”，进程大概每隔1秒钟从“跨地图聊天服务器”接收目标地址是本服务器的聊天信息，收到后写入“聊天信息记录”中；

6、 “同步通讯进程”向游戏端发送下行同步包时，还须要实现一个“额外”的功能，就是检查“聊天信息记录”，有须要发到游戏端的通讯数据，附带在下行同步包中发给游戏端；

7、 游戏端的同步通讯线索收到下行同步包中附带聊天数据后，把聊天数据写入“接收聊天信息”中；

8、 聊天信息的显示由“视觉效果表达线索”处理。

    这样处理的优势是：

1、 整体来讲，实现比较简单，与其它模块之间的关系比较清淅，相互干涉少；

2、 实现了游戏端的按需传输，象地图服务器的跨地图聊天信息获取进程从服务器获取数据时，必须采用轮询的方式定时从服务器，产生大量的无用通讯，固然，这在带宽比较高的服务器之间并没关系，但对网速较低的游戏端来讲是必需的；

3、 没有大量的游戏端向聊天服务器轮询数据，减轻了聊天服务器的压力。

同步通讯模块

同步通讯应该使用TCP长链接，长链接的意思是指在游戏端进入地图（服务器）以前，就创建一个与服务器的TCP链接（会话），该链接一直保留直至退出该地图，在此期间，游戏端和地图服务器之间全部通讯都过该链接进行。这点和发送聊天数据是不一样的，发送聊天数据时，游戏端须要动态创建一个TCP链接，发送结束后，马上关闭该链接。

TCP通讯通常是是C/S结构，当游戏端进入地图时，游戏端主动呼叫地图服务器某个端口（系统约定），试图创建一个TCP链接。

链接创建成功后，游戏端须要建立两个线索，分别是“同步通讯发送线索”和“同步通讯接收线索”。

在客户端，TCP的通讯使用Winsock 提供的“异步消息机制”，这点与聊天通讯发送线索使用的“阻塞机制”不一样。同步通讯线索与核心计算线索之间的同步应该使用互拆对象，使用互拆对象要比消息更为可靠，这是由于消息会放在一个系统级的队列中排队，若是其它线索没有及时取走本身的消息，就会堵塞后面的消息的传送。下面是客户端的同步通讯处理过程：

1、 创建两个互拆对象，一个称为发送互拆对象，一个为计算互拆对象；

2、 核心计算线索计算结束后，释放发送互拆对象；

3、 同步通讯发送线索运行，从核心结构取出须要发送的数据，生成上行同步包发送，释放发送互拆对象，核心计算线索从新运行，检查计算互拆对象；

4、 此时，同步通讯接收线索正处于接收消息状态；

5、 当系统收到地图服务器的下行同步包后，系统会向同步通讯线索发送一个消息（Winsock的异步消息机制）；

6、 同步通讯接收线索收到下行同步包后，写入核心结构，而后释放计算互拆对象；

7、 核心计算线索继续运行，释放计算互拆对象，进行核心计算；

8、 核心计算线索释放计算互拆对象后，同步通讯接收线索也继续运行，回到接收消息的状态。

服务器端须要处理的关键问题是必须处理多个游戏端的链接，服务器端可以使用：多进程、异步I/O复用和多线索等机制处理，三种机制都各有优缺点，但都能知足系统的需求。因为Linux下的通讯实现比较简单，下面再也不详述。

服务器通讯同步进程可采用信号灯机制实现和核心计算进程之间的同步。

同步的创建和恢复

在网络游戏中，为了维护游戏的一致性，必须在每个节拍中，保证核心结构的一致性，这就同步。在本文同步的方案是，首先让服务器和全部的游戏端得到一份一致的核心结构数据，而后经过地图服务器收集全部游戏端的操做指令（上行同步包），而后经过下行同步包分发这些指令，这些指令造成增量数据，而后服务器和游戏端都根据同一算法，从新计算出下一节拍的核心结构数据来。

当一台新的游戏端进入地图时，服务器停止接受节拍的运行，中止接收新的操做指令，而后出游戏端传递一份初始的核心结构，这段时间称之卡。下面估算一下卡的时间。

核心结构中，地图的信息较大，但这部分信息不须要传递，须要传递的主要信息是武器属性数组。假设这个数组1000条记录（128个在线游戏端，每一个游戏端7.8个，“破碎银河系”为6个），每条记录100个字节，也就是说合计100K字节，假设游戏端使用56K拨号上网，每秒接收3K字节的数据，“卡”的时间大概为33秒，这个估算和“破碎银河系统”的状况大体吻合。

简单采用直接传送核心结构的办法，一方面会致使使人讨厌的“卡”现象，另外一方面，出现同步被破坏后，没法恢复，只能掉线处理。

同步被破坏的缘由有两种：

² 核心结构从新计算后，计算结果不一致，称之为计算同步破坏；

² 游戏端由于通讯或其它问题，未能及时上传上行同步包，称之为通讯同步破坏。

下面提出一种方案，试图解决“卡”和同步恢复的问题，这种方法依赖于服务器大量备份历史核心结构和操做指令序列数据：

1． 当地图服务器顺利完成一个同步的节拍后，服务器服务备份核心结构，同时备份该节拍以后全部的操做指令序列数组。

2． 新的游戏端向服务器发出请求，请求加入地图，或请求同步恢复；

3． 服务器下传备份的核心结构；

4． 服务器接二连三地向游戏端下传备份操做指令序列数组的历史记录；

5． 游戏端收到备份的核心结构和操做指令序列数组后，不断的调用核心计算模块，直至遇上服务器最新的节拍；

6． 在追赶的过程当中，游戏端执行玩家的操做指令。

下面估算一下追赶须要经历的时间。

计算条件：

节拍间距：0.5秒；

核心结构大小：100K；

下行同步包大小：小于576字节；

每秒下传数据量：采用56K拨号上秒，每秒6个包，即3456字节；

其它（如核心计算时间）忽略不计。

追赶时间：S

那么：

S * 3456 =  S / 0.5 * 576 + 100000

即

S = 100000/ （3456 – 0.5/576）= 32秒。

为了保持战略的均势，“破碎银河系”有一个设计，当玩家提出进入某个地图做战的请求后，必须等待一段时间才能进入，这段时间跟据玩家与做战地图的距离（战略地图）而定，大概从几秒到120秒不等，能够利用这段时间追赶同步。

核心结构和计算

核心结构是多个结构数组的集合，包括：

² 操做指令数组：每条记录记录一个用户的指做指令；

² 地图形态结构数组：

每条记录描述地图一个最小区域的属性，在“破碎银河系中”，地图的属性比较简单，只须要表达该区域陆军是否可进入便可，至于其丰富的地貌，如树木、山脉、建筑物、湖泊等，只需另外画一张与地图形态数组一致的图便可，地图形态数据没必要记录这些信息，那是属于表达模块处理的问题；

² 玩家状态结构数组

每条记录描述一个用户的属性，必须的数据成员有：

ID；

所属国；

等级；

² 武器状态结构数组：

每条记录描述一件武器的的属性，主要数据成员有：

武器种类；

所属国；

主人在玩家状态结构数组的序号；

等级；

生命值；

能源值；

装备；

座标；

当前状态；

被攻击的类型；

² 特殊物体数组，特殊物体数组可用来表达布雷等形态，主要的数据成员有：

种类；

所属国；

主人在玩家状态结构数组的序号；

座标等

² 校验码：利用校验算法，对核心结构中可变的部分进行计算出来的校验码，用来防止计算同步破坏、做弊等；

² 节拍ID

核心计算能够按照几个步骤来进行：

1、 计算各武器的最新状态；

2、 计算各武器的最新座标；

3、 计算各武器对其它武器的攻击效果；

4、 计算特殊物对其它武器的攻击效果并删除记录；

5、 删除生命值为0的记录；

核心计算注意事项：

1、 为了保证计算同步，全部计算数据只参使用整形，不能使用浮点数；

2、 为了增长计算精度，应该对计算表达式进行变换，变换成除法是最后一个运算步骤；

3、 注意整形数据的超值（大于2的32次方）；

4、 为了保持武器系统的平衡，避免出现“超级武器”，削弱游戏的可玩性，不管是武器的速度、攻击效果等数据都应该参数化，保存在文件中，方便在游戏测试、营运时调整。

属性设定模块

     属性设定模块的实质就是联机交易服务器，运行于Linux服务器上，通常采用C语言开发，与数据库的接口是Embedding C预编译器，若是数据库为Oracle，预编译器的产品名称为Proc C。

    因为这方面技术很是成熟，就再也不一一禅实。

视听觉表达模块

核心结构给视听觉表达模块一个接口，表达模块只需围绕这个接口按照生成画面和音响便可，不须关心游戏的其它部分，功能至关独立，这是本文接出的结构的最大特色。

笔者没有开发同类程序的经验，就再也不献丑了。

操做控制模块

操做控制模块接收用户的按键和鼠标操做，若是发聊天操做，把发出的聊天数据写入待发聊天数据的内存变量便可。

若是是武器操做，还必须把按键和鼠标操做翻译为对武器的操做，再写入本人操做指令的数据结构中。

分工和工做量估算

上面所描述的游戏引擎，有一个很大的优势就充分考虑了如何分工合做，各模块互相干涉较少。

游戏开发的核开发小组可能须要成员包括：

² 项目经理2人；

² 游戏端总控1人；

² 服务器端总控1人；

² 聊天功能的开发1人；

² 操做数据的交换（即游戏端通讯线索和服务器端进程的开发）1人；

² 核心计算1人；

² 新玩家加入，创建初始状态的通讯模块1人；

² 音效表达线索1人；

² 视觉表达线索须要3人左右的小组一个；

² 属性设定服务器1人；

² 属性设定界面开发2人；

² 美工3人左右；

² 测试2人；

² 系统安装管理1人；

² 质量配置管理员1人。

时间的安排为：

² 脚本编写1个月

² 整体设计和详细设计2个月

² 编码2个月；

² 测试3个月；

² 后期制做2个；

整个工期大根据为12个月，每一个阶段不必定须要全部人参与。

以上安排是按照比较宽裕、规范的方针按排，有很大的压缩空间。

后记

因为笔者并未开发过任何游戏软件，若是某些猜想与现实不符，敬请见谅。在可见的未来，笔者从事的工做虽然和游戏无关，但出于兴趣撰写了本文，笔者更很是但愿能和其它对游戏开发感兴趣的同行增进交流，相互学习。笔者信箱：chenchongfen@21cn.com或chenchongfen@163.com。