关于Darkstar游戏框架学习心得

最近看了一些关于，Darkstar游戏框架的文章，在此进行一下总结吧，也算是对学习成果的展示。相信人们平时一般都会玩游戏，尤其是对于一些大型的MMO游戏有些人更是情有独钟。那么在设计这些游戏的过程中都要考虑那些问题，这些问题又是如何解决的呢？

1.游戏设计面临问题：

在大型游戏设计过程中出了要考虑到游戏剧情机器相关的内容外，在技术层面上，伸缩性问题成为了在设计阶段重点考虑的问题之一。没有人能够准确估计将来游戏可能达到的规模，也没有人能准确预测未来该游戏的走势。有可能在很长一段时间内该游戏都无人问津，用户量极少，那么预先购置大量昂贵的设备显然是对资源的浪费，然而，也有可能突然有一天该游戏被大多数人所认识，人们开始蜂拥的加入游戏的行列，游戏的用户量激增，也许当初的预期跟实际情况相差甚远，当前的设备根本无法满足用户的需求，即使当初预料到了准确的用户量，那么谁又能保证用户永远对你的游戏感兴趣呢？很有可能有一天人们都放弃了该游戏，转而投向其他的游戏，那么用户量又会极具下降，又会有很多多余的资源闲置。那么这种状况体现了游戏对于框架的哪种需求呢？伸缩性，伸缩性能够使游戏随着当前情况不断调整策略。

 另外一点涉及到游戏不同于一般web应用的伸缩性的问题体现在，游戏角色与虚拟游戏交互的问题上，在一般的MMO游戏中用户智慧与周围的虚拟环境如：NPC，或者其他的玩家进行交互，但是这之发生在小范围内，在同一个虚拟世界中两个玩家交互的可能性是极小的。对于这种情况的伸缩性考虑也是非常重要的，直接影响到系统的性能。

还有一点便是可扩展性的问题，当然这里所说的可扩展性并不是指代码的可扩展，那只涉及到后期的维护和开发，这里所说的可扩展所指的范围更大，粒度更大，一款MMO游戏肯定要有一定的剧情支撑，如果长期不对剧情进行更新，放入新的副本，那么很快玩家便会失去对游戏的兴趣，那么很自然的对游戏的扩展便成为了游戏是否成功的重要方面。

延时问题也是一个重要的方面，因为很多玩家对于MMO游戏就是为了追求一种即时的刺激感与交互的快感，然而延时却严重影响了用户的体验，降低延时也成为了游戏的一个重要考虑方面。

2.如何解决上述问题：

为了解决上述问题，人们首先应当想到的解决方式也许就是分布式的方案，我想这也应该是最好的解决方案之一。当用户量激增时我们可以采用增加主机的方式来增加系统的处理能力，当用户减少的时候我们可以适当的关停部分主机。这种横向扩展的策略比纵向扩展的方式对于系统的提高更大，成本更低，当然我们也很容易想到，即使采用纵向扩展的方式很快的便会出现性能的瓶颈难以继续实现扩展。在加上现在的主机处理器大部分采用多核技术，这种增加内核数更加适应我们所需要的并行的多任务处理需求。另外对于游戏的编程方面对于多线程的需求也是巨大的。

服务器端处理的人物基本上都是并发的因此对系统的多线程处理能力有很高的需求，另外，游戏的服务器端基本上都是采用反应式的，服务器端的监听器时刻监听客户端所产生的短任务，并对这些短任务进行快速的处理。这些人物都是些简短的易于处理的任务，但是由于并发程度高，因此处理压力比较大。但是如果服务器端采用多线程的任务处理方式便能有效的缓解这种压力。

另外对于游戏来说，与普通的web应用存在巨大的不同之处在于，一般的web应用基本上都是一个瘦客户端配合一个胖服务器，客户端把请求发送到服务器在服务器进行处理后把结果传输过来，主要的运算工作都是在服务器端完成的。然而对于网络游戏来说情况却大有不同。网络游戏为了提高用户体验，游戏中的图片等信息都比较大不适合用来在网上进行实时传递因此，游戏的地图，图片，声音等具体信息都在客户端完成，另外图像的渲染及其他大量的计算人物也都在本机完成，只有当游戏主人公与虚拟世界进行交互时才生成一个短任务发送给服务器进行处理。在服务器端一般只存储一个虚拟世界的抽象，和一些用户的账户和游戏相关信息，当用户与虚拟世界进行交互时服务器端对虚拟世界的信息进行修改，这样便完成了具体的交互。也许说到这你也许会想到，在游戏服务器端对数据库的访问一般都是一些写操作，而不是向其他web服务一样读操作居多，因为服务器端的接收的的交互人物都是对虚拟世界信息的修改，至于读取一般都体现在客户端。

至于解决游戏的延时问题，现在一般都有两种解决方式，第一种便是基于地理位置划分来实现，也就是说游戏种地图的每一个部分各自运行在一台服务器上，这样，玩家处在不同的区域也就使访问压力分散到各个服务器上，然而这种解决方案存在一些问题，当某一时间段用户有可能集中处于某一个区域，那么就给当前区域造成了很大的压力，访问延时也会比较高，另外如果采用这种方案，系统的伸缩性也会存在一定的问题，当系统编程实现时便要制定某一区域所处的服务器，不利于系统的伸缩。第二种解决方案便是我们现在很常见的分区，每一个服务器上运行一个游戏的副本，玩家处于不同的服务器上，这种方案存在的问题便是，不同分区上的玩家不能进行交互。

3.Darkstar采用的游戏架构

对于Darkstar架构的整体架构如下：

其中元服务部分集中了游戏所提供的全部服务的集合，这里集中了游戏的全部功能。

对于每一个darkstar服务栈中包含了一部分元服务的有机组合为每个服务器上运行的游戏的真实副本。

游戏服务器便是为了接受客户端消息，与客户端进行相应的交互。

对与所有的元服务中对于数据的服务是所有darkstar栈所共有的，也就是说所有darkstar栈所访问的数据都是一致的，这也为系统的负载均衡和灾难备份提供了方便。

在客户端与服务器端的交互上存在两种方式：会话和管道。其中会话的方式工作方式为：当客户端与服务器链接后客户端将发起一个会话，服务器端通过会话监听客户端传送过来的消息，进行处理后返回结果，其中会话隐藏了客户端和服务器端的真实端点。当然也就是由于这点也就为游戏的负载均衡提供了方便，因为所有服务器的数据服务是共享的客户端又不知道为其服务的具体服务器端是谁，那么只需要底层服务修改该会话的服务器端即可实现将此会话迁移到其他服务器上的目的。另外一种交互方式也就是管道允许游戏用户可以以一种一对多的方式直接发送到多个客户端上，也就允许的客户端的直接通信，减小了服务器端的负担，但为了防止客户端恶意传输信息，一般这种管道通信都要经过服务器端的验证。

这些也就是我对这个框架的理解了，确实很灵活，可以做适当的迁移，以完成其他的系统。