查看: 10040|回复: 79
[转]开源《热血传奇》服务端引擎（C#编写），可以顺利进行游戏
在线时间 小时
本帖最后由 zxfzxf 于
20:05 编辑
9 \2 ^! }. N2 l! `+ b' r8 g
[转自博客园]
热血传奇...曾经风靡一时的网络游戏..距离如今已经有10多年的历史了.
这套代码是我通过代码转换工具转换过来加之修改之后可以顺利的进入游戏畅游砝码大陆。
作为菜鸟的我能独立完成并修改代码中的BUG，实属不易...虽然早就完成了，放在手上很久没更新过了，干脆开源出来算了...' E/ E+ r5 C0 ]/ O
代码里面部分字段和方法有注释.带来里面大量使用指针来完成与原来DELPHI写的程序交换数据。* a. _&&h5 g&&A" n
欢迎各位高手指教..) \* K% H1 L) ]) c& ^3 [& c* S
代码下载地址:/
数据库下载（需要MSSQL2008）：/sync/DataBase.rar&&(已重新上传新的数据库，原来的可能会无法附加)6 I1 _: t/ w& J* o$ [! w
数据脚本文件下载：/sync/sql.rar
配套的服务端文件：/sync/MirServer.rar
服务端假设方法请自行百度，这在就不一一说明了。# ?" g7 F. m* u) y
在线时间 小时
┗茹梦忠┛ 发表于
您的QQ 多少& &我想问下 你的代码没办法下啊
6 x1 b5 T, v& }/ D+ ^7 e+ X
点source code --&download! m8 e&&X5 ~& t4 ?$ I% }
直接就可以下载了
在线时间 小时
非常好的资源
在线时间 小时
您的QQ 多少 (TG:28:)&&我想问下 你的代码没办法下啊
在线时间 小时
来看看运行图吧。。
(64.3 KB, 下载次数: 18)
18:58 上传
在线时间 小时
非常好的资源
在线时间 小时
还免费的呢
在线时间 小时
zxfzxf 发表于
18:55 8 G7 w# y) c8 R/ S
/3 P- Z8 K( X7 s4 c- G$ }
点source code --&download: q7 j&&V* c+ \; W, r/ x
真没下载啊 ···············
这样基本的操作问题自己沉下心来看。我都下载了，怎么没法下载！&
在线时间 小时
┗茹梦忠┛ 发表于
21:23 5 {6 G" P8 {1 V
真没下载啊 ···············
五角星左边，你如果找不到我也没办法
在线时间 小时
reaper1129 发表于
来看看运行图吧。。% \- @; [$ L/ Q# q4 j7 ^7 v0 u
非常牛逼的截图
Powered by此页面上的内容需要较新版本的 Adobe Flash Player。
最新开发文章
最新信息推荐
上市公司专栏
实时股价每分更新
纳斯达克（美元）（市值：亿美元）
综指：　涨跌幅：
恒生指数（港币）（市值：亿港币）
综指：　涨跌幅：
综指：　涨跌幅：
游戏服务器引擎设计
来源：网络02-25-2010
　　一般来说,现在网络游戏的服务器设计大致分为以下三大类:
　　1:单服务器结构
　　2:多服务器结构. (根据服务器负责功能不同,有按地图范围进行划分的服务器设计,有按功能划分的服务器设计)
　　3:分布式服务器结构.
　　一:单服务器结构
　　在比较起先的MMORPG游戏中,大部分使用的是单服务器结构,一台服务器容纳人数大约为人左右,根据硬件不同和游戏需要涉及的AI,逻辑等复杂度不同会有少许出入.
　　但是这种方式慢慢被淘汰了,因为网络游戏用户对游戏的品质要求越来越高,用户群也越来越大,开发者们不得不牺牲这种开发效率快,逻辑简单,但容载量小的单服务器结构.
　　二:多服务器结构
　　为了提高同服在线人数,多服务器结构慢慢流行起来,现在大部分游戏服务器结构也是基于该类结构设计的.
　　根据策划需求不同,多服务器结构可以设计为多种,一般来说,比较主流的功能分布方式有以下两中: 按地图划分服务器,按功能划分服务器.
　　按地图划分服务器,结构清晰,实现难度小,效率也相对比较高.但是会有部分资源的浪费(因为玩家不可能平均分布在每个地图上),另外一旦总控服务器(负责地图服务器间的分配管理的服务器)挂掉的话,会导致所有的地图服务器无法正常工作,而且由于每个地图保存一份数据,数据保存方面是相对独立的,所以数据安全性无法保障,一旦某地图服务器挂掉,则很大可能会遗失数据.
　　按地图划分服务器的话,一般服务器是分为以下三部分,世界服务器,地图服务器,网关服务器.
　　世界服务器负责世界地图的管理,它一般负责管理地图服务器的工作分配,数据转移通知功能,一些全局性的功能它也负责,包括读取发布网络游戏配置信息,全地图聊天公告的发布等.
　　地图服务器各自间是完全独立的，各自负责该地图区域内的一切功能,包括怪物AI,该地图的NPC,怪物,玩家,物品等所有信息,而且各自拥有独立的数据库进行记录.当一个玩家从一个地图切换到另一个地图时,地图数据库将通知世界数据库,世界数据库再通知另一个地图服务器,进行这俩地图服务器之间的用户数据传输.
　　网关数据库通常是负责玩家登陆的功能,同时也兼责一些世界服务器的调配功能.
　　按功能划分服务器的话,则是一种面象服务的设计思想,将游戏逻辑中某些常用密集型的功能分离开来,单独做为一个服务器进行控制操作,例如,怪物AI单独由一个服务器负责,物品管理单独由一个服务器负责等等,按照逻辑职能进行服务器分割.
　　这样做的好处是,当一个服务器出现问题的时候,是不会影响其他模块的运行,而且扩充性相对比较优秀简便.
　　但是一旦重要的服务器挂掉,如物品服务器挂掉,依旧是一个很灾难性的结果.不过,由于划分出了单独的服务器,保证了数据的分布式存放,比起场景划分服务器来说,多少还是安全了许多.另外,功能划分服务器还有一个比较大的问题就是,由于各模块之间有直接或间接联系,在服务器进行调试的时候难度会比较大.
　　三:分布式结构.
　　无特殊研究,待补充.仅知道支持远程对象调用,动态分布节点吞吐数据确保了服务器受压平衡,能够支持关键数据的多节点冗余确保了数据安全性.
　　服务器的设计考虑应从几个方面进行:
　　1:各服务器的吞吐数据平衡性
　　2:C-S-C的消息响应时间
　　3:数据的安全可靠性
　　4:开发测试效率,维护效率
相关新闻：
相关专题：
<button style="border:2px solid #background-color:#margin-right:10" onclick='javascript:var _title=document.var _url=document.location.if( document.all ) {var _text=_title+" - "+ _clipboardData.setData("Text",_text);this.innerHTML="已经复制成功，请用 Ctrl+V 粘贴";}'>复制本文地址推荐给朋友
收藏这篇文章ProudNet_服务端引擎_网络引擎_介绍__图文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
ProudNet_服务端引擎_网络引擎_介绍_
&&ProudNet 专业游戏服务端 & 网络引擎
阅读已结束，下载文档到电脑
想免费下载更多文档？
定制HR最喜欢的简历
下载文档到电脑，方便使用
还剩26页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢后使用快捷导航没有帐号？
　论坛入口：
　　|　　　|　　　　|　　　|　
游戏服务器和一般服务器对比，有何特别？
文/wadehan
image001.jpg (26.87 KB, 下载次数: 37)
11:16 上传
　　在中国的互联网诸多业务领域中，游戏一直是充当“现金牛”而存在的。但是，在游戏服务器端开发领域中的很多重要问题，并没有被明确的分辨出其特异性，从而得到专门的对待。我们不管是在业界开源领域，还是内部分享中，很少会有专门针对游戏业务特征进行专门设计的组件、类库或者框架。我们从游戏的客户端方面来看，一款专业的游戏客户端引擎，已经是游戏开发的标配，比如最早的Flash Builder，到后期的Cocos2d-X，Unity，Unreal；但是服务器端，我们几乎找不到同样重量级的产品。
　　在游戏服务器端开发所有要面对的问题中，有两个是最核心和最普遍的：一是和客户端的通讯；二是游戏登录用户的数据处理。对于和客户端通讯的这个问题，大量的游戏开发者会使用“通用”的开源组件，比如Protocol Buffer，Thrift，Jetty，Node.js等等通信或RPC框架。虽然针对游戏，还是要做大量的改造，但一般都有很多现成的代码可供修改。
　　在一般的互联网应用中，我们一般认为服务都是通过请求-响应的方式来完成的。而在游戏业务领域中，请求-响应可以看成是一种类型的通讯方式，但还有另外一种重要的通讯模型，就是“数据同步”方式：游戏中某个角色的HP、位置坐标改变了，需要在客户端和服务器之间、客户端和客户端之间同步。这造成了一般情况下通信协议的大量增加。
　　对于第二个问题，不管是memcache还是MySQL，或者是Redis，都不能完全满足游戏开发者的需求。很多团队尝试过各种组合和修改，试图创造出利用现有开源软件，建设既能迎合灵活的需求变化，又具备高延迟和高可用的数据处理系统，但最后这些努力基本上都很难圆满成功。因此我们在游戏服务器端代码中，还是充斥着大量的内存、缓存管理，数据同步、落地等等代码。而且每个游戏都要重新去写一遍这些类似的功能，不能不说一种浪费。
　　如果我们要想出一种能满足“游戏”这个业务领域的数据系统设计，那么就一定要搞清楚为什么在如此之多的开源项目和游戏团队中，没能实现完美契合的原因。
　　电子商务/一般互联网业务的C-S通讯流程
　　基于WebService类型的通讯模型，现在基本已经成为互联网开源组件的标准。由此而诞生的RESTful API，或者各种RPC模型，其实都是基于这样的客观事实：
image002.jpg (7.46 KB, 下载次数: 33)
11:16 上传
　　l&&用户主动请求，服务器产生回应。典型的就是网页的点击、表单的提交。
　　l&&主动通知的消息，仅仅是提示用户发起查询请求。比如在APP按钮上的小红点，消息页的数字提示等等，这些主动通知都是为了通知用户去刷新页面。
image003.jpg (7.36 KB, 下载次数: 33)
11:16 上传
　　游戏类业务的通信模型
　　游戏中的通信，一般和操作有关。这些操作一般分为两类：
　　l&&UI面板类操作
　　l&&战斗场景操作
　　这两者的最大区别，就是UI面板类操作一般无需让其他玩家看见。而战斗场景操作则需要广播给所有玩家看到。
image004.jpg (90.44 KB, 下载次数: 35)
11:16 上传
image005.jpg (44.42 KB, 下载次数: 36)
11:16 上传
　　在第二种情况下，一般就不是客户端主动发起，而是服务器端直接推送实际数据，然后客户端直接显示这些数据。这个模式和简单的“推送”还不一样，而应该更进一步，是一种从服务器端发起的，向客户端“同步”数据的请求。
　　因此，一个好的游戏服务器端框架，应该是能同时支持请求-响应模型和“推送同步”模型的。
　　电子商务/一般互联网类业务的数据处理流程
　　Memcache、Redis、MySQL在一般互联网业务中的应用非常广泛。而且基本上能很好的应对各种常见的应用场景，包括类似BBS的社区、新闻门户、电子商务类系统。在企业内部信息系统中（Intranet），这一类数据软件也能发挥非常好的功效。由于电子商务类是其中最复杂的系统，所以我在这里以此为例说明，一般数据处理的流程是如何的。
image006.jpg (63.8 KB, 下载次数: 35)
11:16 上传
　　假设我们浏览了一个网店，选中了一个商品，点击了下单这个流程，实际上需要的后台流程可能是下图所示：
image007.gif (9.55 KB, 下载次数: 36)
11:16 上传
　　从上面的分析大概可以总结出几个特点：
　　一、忍受延迟：每个操作的延迟要求较低，操作频率不会太高。一般我们页面在5秒内打开，都不会引起太多客户的抗议。所以，就算我们处理一个请求的时候，后台进行多次的进程间调用，产生的延迟和带宽消耗也是可以忍受的。
　　二、在线交互少：互联网业务大多数是基于浏览器的，所以在线用户之间很少实时交互。
　　三、数据分散：一般来说，互联网应用的数据可以在多个不同的业务系统中共用，但是需要专门的业务模块来做管理，以维持数据的一致性。
　　四、数据变更面广：系统需要持续处理很多数据变更，互联网业务有很大一部分数据是来源于普通用户、网络编辑、店主等等使用者，在使用的过程中，他们会大量的修改系统所存储的数据。
　　以上四个特点，导致了我们一般会把后台要处理的数据，分别用Cache系统和DB系统来处理。并且，我们一般会按业务功能划分模块，同时也划分业务系统。由于延迟和在线交互的需求较弱，所以使用大量进程来做模块隔离，依然是非常可行的，总体来说，就是一种比较“分散”的数据使用方式。
　　游戏类业务的数据处理流程
　　在各种游戏中，MMORPG是数据处理最为复杂的一类，也是最典型的一种“重服务器端”的游戏类型，因此可以作为游戏业务中通用性的参考标准。在MMORPG中，我们可以发现，数据的处理需求，和一般互联网业务大相径庭，它体现出的是一种明显的“集中”式的数据处理需求。我们可以从一般MMORPG的服务器架构中体现出来：
image008.gif (18.86 KB, 下载次数: 34)
11:16 上传
　　在游戏业务中，一般我们都会发现以下的特点：
　　一、延迟敏感：游戏中用户会产生大量操作，都要求“实时”进行反馈，所以一般都不能忍受1秒以上的延迟，在大量动作类型的游戏中，一般都会要求服务器的反馈时延在50ms左右。因此游戏开发者都习惯于尽量减少后台进程间的交互，尽管这对提高系统吞吐量很不利。所以大部分游戏服务器端都有一个所谓“GameServer”，里面运行了游戏70%以上的功能。
　　二、大量实时交互：在线游戏的特点，就是很多玩家可以通过服务器“看见”彼此，能实时的互动。因此我们必须要把用户的在线数据，集中到一起，才能提供互相操作的可能；而且A用户操作B用户的数据，是最常见的数据操作，所谓战斗玩法，就是互相修改对方的数据的过程。
　　三、数据集中：游戏是一个几乎完全虚拟的世界，在游戏中的数据，实际上很少能在其他系统中产生价值。而游戏逻辑也禁止通过游戏以外的方式，修改游戏的数据。所以游戏中的数据，一般都会集中存放在单独的数据库中。由于没有数据共用的需求，所以也不需要把GameServer里面集中的逻辑划分出很多单独的进程模块来。
　　四、数据变更少：实际上游戏的数据变更还是很快的，比如游戏中的每次中弹，都要减少HP的数值。但是游戏里的数据，一般都遵守这样一个规则：“变化越快的数据，重要性越低”。也就是说，游戏中是可以容忍一定程度的数据不一致和不完整的。而游戏中的数据，一般会分成两类：玩家存档和游戏设置。对于玩家存档来说，其单条数据量一般不大，但会有大量的记录数，因为每个玩家都会有一个存档。但是其读取、修改，一般很典型的和玩家的登录、登出、升级等业务逻辑密切关联，所以其缓存时机是比较容易根据业务逻辑来把握的。而对于游戏设置数据来说，几乎只有升级游戏版本的时候才会修改，大部分运行时是只读的，其缓存简单的读入内存就解决问题了。
　　一般的缓存系统的特点在游戏中的问题
　　根据以上的分析，我们可以看到，普通的缓存系统，如memcache和Redis，实际上其特点是不太适合游戏业务的：
　　l&&一般跨进程的缓存系统，无法解决游戏要求的低延迟问题。级别是同机房，每次数据存取都需要10-20ms的时间，对于游戏战斗中大量的数据读、写来说，是很难接受的。（但是一些回合制战斗、低频操作还是有用的）
　　l&&通用型的缓存系统或者数据库，一般都比较难集结多个进程，形成一个完整的数据存储网格。这让玩家间的互相交互产生了额外的难度，开发者必须先想办法确定玩家的数据在哪个后台进程上，然后才能去读写。一般的数据库或缓存系统，为了保证数据的一致性或者完整性，往往会需要牺牲一些分布式的能力。而这种牺牲在游戏业务中，其实是一种浪费，因为游戏的很多数据都无需这种能力。
　　l&&通用性数据系统一般不依赖于特定的语言，所以很少能直接把某种“对象”存入到数据系统中。在游戏开发中，需要存储的数据结构数量往往是非常大量的：一个普通的游戏，基本上都会超过100种数据结构。对于每个数据结构，都去建表或者编写序列化/反序列化配置，是一种非常累人的工作。--明明在代码中，已经用编程语言定义了他们的结构，还要重复的搞一次。
　　根据上面说的这些问题，我们实际上是需要另外一种完全不同设计思想的数据系统。
　　对于游戏业务来说，一个好用的数据系统，应该包括这样一些特点：
　　l&&可以利用GameServer进程内的内存进行自动化的缓存管理。由于GameServer进程往往集中了大部分的逻辑运算，所以大部分的数据缓存也应该在这个进程中，这样才能符合游戏所需的延迟要求。
　　l&&自动进行数据落地和容灾管理。由于游戏数据中有大量的“过程数据”，所以其一致性和完整性要求会稍微低于其他业务，所以应该利用这一点，让GameServer本身也可以是分布式的程序，从而提高系统整体的吞吐量。
　　l&&具备良好的编程易用性。最好是能直接存取编程中的对象，避免反复对数据结构的描述，节省大量的开发时间。
　　游戏服务器和普通互联网业务服务器端，最大的区别实际上就在于“状态”。游戏服务器的状态是实时快速变化的、可以容忍丢失的、需要大量广播同步的；普通互联网业务服务器的状态一般是持久化的、不容忍丢失的、只和特定客户端相关的。所以一个好的游戏服务器框架，在通讯和数据这两个基本层面，会和一般我们所接触的开源组件有很大的差异。这也是作为游戏服务器端开发者，需要去共同建设行业标准的地方。
关注我们官方微信公众号
下载我们官方APP-游戏行
关注手游动态微信公众号
楼主总结得很详细！
只是一般互联网业务服务器与游戏服务器应用场景完全不同。
《绝地求生》销量超过1300万份 开发商成立不一样的射击体验!科幻新作《Star Rage VR将玩家引导玩出新境界
从《神秘海域4》中激萌萝莉,专属宠溺,《萝莉养成计划》9月30仙魔传奇，超越经典《西游记口袋版》9月30《绝地求生》游戏性深度分析：它凭什么火炎
微信扫一扫关注我们→