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

 

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

 

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

结构体系分析

 

前言

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

网络游戏是我们的机会

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

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

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

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

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

游戏功能模块分析

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

一、 交流或作战状态的地图漫游；

二、 属性设定；

三、 聊天；

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

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

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

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

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

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

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

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

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

联机交易首先在金融等行业得到应用，现在所有的核心金融应用系统，都基于联机交易，而且，联机交易已经广泛地应用于其它各个领域中。

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

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

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

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

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

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

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

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

服务器组织

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

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

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

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

每一个星球大概有100张地图，可以通过动态分配、一台物理服务器运行多个交流地图服务器等方式，减少真正需要的服务器。

因为地图服务器可以动态增加，因此一个分区同支持的用户数取决于属性服务器和聊天服务器。

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

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

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

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

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

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

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

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

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

² 操纵；

² 通信；

² 核心结构计算；

² 音效表达；

² 视觉效果表示；

² 聊天；

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

整个引擎结构如下：

流程分析如下：

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

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

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

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

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

六、 如果同步通信进程收到中止指令后收到上行同步包，则通知对方通信出现同步问题，并不把指令记入核心结构中；

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

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

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

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

十一、 音效和视觉效果表达线索可以以核心结构为输入，按照自己的节拍运行。

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

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

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

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

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

产生“卡”的原因很简单，就是所有的玩家的操作必须停下来，获得一份一致的核心结构，然后把核心结构传递给新加入的玩家的游戏端。

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

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

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

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

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

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

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

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

在“破碎银行系”中，如果快速操作，1秒种可以执行2个以上的操作，可以看到除第1个操作得到执行外，其余操作被忽略，也就是说，“破碎银行系”的节拍间距是1秒左右。

在玩“破碎银行系”的过程中，我觉得操作不是太顺畅，如果把节拍设为0.5秒会好一点。至于更短的值可能没有必要，因为人的操作频率一般不会每秒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个同时在线用户的性能参数还一定的挖掘空间。

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

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

聊天模块的实现

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

² 跨地图聊天服务器

² 聊天数据发送线索

² 聊天服务进程

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

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

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

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

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

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

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

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

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

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

    这样处理的优点是：

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

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

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

同步通信模块

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

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

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

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

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

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

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

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

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

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

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

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

服务器端需要处理的关键问题是必须处理多个游戏端的连接，服务器端可使用：多进程、异步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

核心计算可以按照几个步骤来进行：

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

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

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

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

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

核心计算注意事项：

一、 为了保证计算同步，所有计算数据只参使用整形，不能使用浮点数；

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

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

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

属性设定模块

     属性设定模块的实质就是联机交易服务器，运行于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。