5月杂记，学习中的两个东西

最近又沉默了很久，倒不是故意的，i7有Baby了，所以转移了一些精力过去，而且可能是项目到了收尾的时候了吧，U3方面已经没有什么大的工作了，状态也一直没有起色，也没有什么太多可以拿出来分享的东西了。

整理了一下最近的一些思路，主要还是服务器方面的，都是一些实践过程中发现的问题和采用的方法。这玩意儿比预想要复杂得多，这也是必然的，要不服务器岂不是谁都可以去做了，这些心得也并不见得正确，可能还会不断修正，那句话怎么说来着？道路是曲折的……如果众位前辈发现有什么不对的地方，欢迎批评指正。

首先是服务器端的拓扑结构，一个登陆服务器是必须的，它的主要任务就是处理通行证的登陆，验证用户名、密码、密保——并将连接分配到合适的接入服务器去。

这里面可能有多种方案，一种是登陆服务器返回一个ip和端口，本地根据这个ip和端口连到接入服务器，这个方法总感觉暴露了一些不必要的细节给客户，而且一旦把信息交给客户，服务器将处于完全被动的状态，所以后面选择的是另一种方案，就是客户端自己开一个ip和端口，并报给登陆服务器知道，而登陆服务器验证完毕通行证后，直接通知接入服务器这个客户端的ip和端口，接入服务器开启一个连接通向客户端，这样服务器方面的灵活性大一些。

接入服务器的作用是什么呢？相当于一个facade吧我想，游戏的服务器肯定是一大堆的，之间的关系也并不简单，但如果把这些细节暴露给玩家，是没有必要的，玩家只需要保有一个对接入服务器的连接就可以了，玩家与其它任何服务器的联系都只要通过这个接入服务器就可以了。这个接入服务器的逻辑相当简单，没有什么太需要注意的，大部分情况下都是消息的转发，同时管理一下接入的信息即可。比如，一个账号登陆了哪些玩家？这些玩家分别在哪些游戏服务器上存在？大部分情况下，游戏用户的信息可能同时只能由一个服务器去维护，也就是说，在暴风城的用户的信息只能由暴风城这个服务器去读写，切换到诺森德后，这些信息就需要从暴风城服务器卸载，而在诺森德重新加载，否则极容易发生数据一致性方面的问题，比如暴风城正在使用用户的一个物品的时候，诺森德却把这个物品卖掉了……。因此，接入服务器也可能需要处理用户在服务器间的数据交换，暴风城正常卸载后，诺森德才重新加载了游戏数据。这一切在客户端可能只是一个loading条，但对于服务器要考虑的事情还真不少。（呃，当然，也有可能是我想复杂了）

最后就是游戏本身的服务器（组）了，由于现在做的只是一个棋牌类的实践，所以服务器（组）的结构相对简单，只有一个服务器，同时处理大厅（管理所有棋牌桌的信息）和牌桌逻辑（具体的棋牌游戏房间）。这个方法显然是不对的，但是可以尽快先出来大体的结构，所以准备先这样处理，后面再调整结构。

调整就是把这一个服务器给分成大厅服务器和房间服务器，大厅服务器管理所有房间的信息，而房间服务器并非一个房间一个服务器，而是一个服务器承载成百上千个房间，只要这个服务器没有满载，大厅就会通知其接受新的房间请求。用户先进入大厅，然后选择牌桌，只要牌桌是可用的，大厅服务器就会把这个客户端给发到相应的房间服务器去，然后把对玩家信息的操作权完全交给房间服务器。直到玩家打完牌，然后再将操作权交还给大厅服务器即可（在大厅可以买卖物品，所以需要对玩家信息的操作）。

暂时也就做了这么多，也就写这么多，纯学习目的，能对自己有所提高，这样也就好了。

最近有不少人为什么不搞图形改搞服务器了，其实没有不搞图形，前段时间还弄了一会儿Virtual Texturing。服务器这边主要是做了一下以后，能对网游有一些更多的了解吧，总是做图形和引擎难免眼界狭窄了。游戏的引擎固然重要，但是还是有很多比引擎重要得多的东西的。有时候总感觉，重视不见得是好事儿，重视那块儿，就说明那块儿有问题，重视引擎未必是什么好消息。买了几本外文书，看AI Game Programming gems 4里大篇地讲《英雄连》里的AI设计，感觉那些东西不见得比引擎差多少，毕竟《英雄连》之所以好玩，就是这个部分设计得好。图形和物理对游戏本身真的能有多大的增益呢？这些东西都是工具吧，想法还是最重要的。所以想去做服务器了，多掌握一个工具，也就能更好的理解和实现想法，大概就是这个意思吧。