摘要：MMO-SNS类游戏是一种在线角色之间存在交互，同时在线角色又可以同离线角色交互的游戏。这两种交互行为，决定了不同服务器之间的数据交互和常见的MMO类游戏存在很大差别。这类型一般会有下面两种类型的主服务器。OnlineSvr实现一些MMO的业务逻辑，实现像做任务、战斗、NPC AI、视野管理和消息同步等行为。OfflineSvr 实现一些离线类的SNS业务逻辑。注意，这个服务器涉及到操作离线角色的一些数据。OnlineSvr和OfflineSvr的数据交互有一点讲究。简单以角色的EXP做为交互例子。有一个角色R，在OnlineSvr1上，他的经验值记为EXP；有另外一个角色，是R的好友，记为R 阅读全文

摘要：MMORPG的特点是角色之间一般可见；有不同类型的地图，包括开放地图(城市、村庄等)和封闭地图(副本、大型战场和小型PK房间等)；有各种RPG组织元素(如公会、家族等)。架构设计逻辑服务器部分的出发点是根据上面的特点设计的。一般可以用下面的架构： MMORPG的后台其实就这么简单，架构不复杂。对后台架构经验较少的兄弟，别太纠结，就用这个简单的架构一般就可以满足商业运营要求了。gated 前端接入服务器，主要功能是连接接入，消息接收和发送，也可以包括加解密和解压缩功能。ctrld 一个指挥控制的服务器，控制整个服务器组角色的状态，登录初始化也在这里处理。client进入游戏前的角色列表一般也从这 阅读全文

摘要：我们正在开发的一款游戏有MMO的特征，就是有任务，有战斗；同时又存在大量SNS行为，比如某个角色宠物可以找某个离线好友角色的宠物战斗，找离线角色的宠物修行等。估计目前SNS类的游戏都有这两种用户行为。这样我们看游戏中的数据：角色、宠物、道具、任务、成就、好友、修行、其他乱七八糟的数据。这些数据当中，道具、任务和成就数据，没有特殊需求的话，是不存在离线操作的。所以，这类数据的加载、回写和访问可以按照MMO游戏的处理方式。MMO处理方式，一般是用户登录时加载数据一个公用Cache，切换服务器时，从cache加载新数据，登出时回写数据。Cache可以直接做个简单的LRU淘汰机制。其他数据就按照SNS 阅读全文

摘要：这里的网关服务器(简称gated吧)是指逻辑服务器前面的那排服务器，一般有几个主要功能： （1）接入 （2）加解密 （3）解缩压gated一个特点是不处理逻辑，每个连接之间不存在交互关系，这点非常关键，是我这个优化方案的基础。上面(2)(3)两项目是很吃CPU的，而目前的机器一般是X个CPU，Y个核的，我们可以通过多线程的方式，更好利用机器硬件。当然多线程之间肯定没有任何锁之类的东西。有了锁，多线程效率就下来了。 上行处理过程： 接收线程收到数据后，将数据写入各自连接的接收队列中。 创建X个处理线程，每个处理线程根据某种hash算法去不同的接收队列中读取数据；X个处理线程并行地处理加解密&am 阅读全文

摘要：有的公司可能有一个专门角色名字唯一性判断的服务器，名字服务器。这个服务器的目标保证一个大区或者所有大区的名字唯一。所有大区名字唯一有一个好处是，合服的时候不会出现角色名冲突。一个大区唯一的实现策略很直接很容易。这边文章我们尝试讨论所有大区名字唯一的实现策略。先说一个直接的策略。不同大区的所有的游戏服务器都和一个名字服务器进行数据交互，客户端把创建角色请求交给游戏服务器，游戏服务器去名字服务器上判断一下这个名字是否已存在。这个策略的缺点很多，比如服务器直接耦合增加；如果大区的游戏服务器和名字服务器在不同的IDC而且之间没有专线，效率上一般也不能满足运营要求。所以大部分的项目如果用这类策略的话，一 阅读全文

摘要：pool_alloc是gnu对stl allocator一个扩展实现。位于ext/pool_allocator.h。 pool_alloc实现策略是，当分配的对象大于某个值(我的版本是120bytes)是，就直接用new&delete进行分配和释放。这个策略对于很应用是可接受的，但对于游戏服务器可能不大合适。游戏服务器中的Role(或Player)之类的，很容易超过120bytes。当然有办法避免让他达到大于120bytes。游戏服务器运行的过程中，很多时候都是Allocate&Deallocate Role的行为，这样对象Allocator就不能发挥充分的作用。像一些小对象可 阅读全文

摘要：SNS游戏和MMO类的游戏最大的区别是不分在线和离线状态。SNS游戏中存在大量的某个角色对另外一个离线角色交互。我们拿农场类游戏举例。像偷菜之类的功能都在社区Server（SS）中实现。偷菜之外，我们可以和另外一个角色进入到某个房间进行PK，最后获得经验和物品等，这类功能我们都放到游戏Server（GS）中。这里说一种简单的SS和GS数据交互的策略。1. A从SS切换到GS，GS从SS拉A的某些数据，包括BASE_EXP；2. A与B PK， A得到10点EXP, 记作DELTA_EXP，GS把DELTA_EXP发给SS；3. A退出GS，进入SS。注意看第2步，做过MMO的兄弟们一般应该是把 阅读全文

摘要：本来是不想这类非常简单的文章的，主要是我们公司有一款大型游戏没有针对这个流程做必要的优化，导致玩家进入游戏前的一些请求给Server带来一点不必要的压力。很多游戏是一个账户下可以创建多个角色。Client 选择服务器后，一般流程：1. 拉取自己帐号下的角色列表(GET_ROLE_LIST_REQ&GET_ROLE_LIST_RES);2. 选定一个角色，进入游戏(ENTER_GAME_REQ&ENTER_GAME_RES).对应的Server流程：1. 首先从cache或DB中得到Player的所有的角色列表，列表内容肯定只包含RoleID；2. 根据RoleID从Cache或 阅读全文

摘要：实际项目中，同事的一个道具装备之类的对象要么在背包里，要么就装备到Role身上。有一个逻辑需求是道具要在背包里消失，但这个对象还需要存在。大部分人的道具模块应该能满足这个需求。但在实际工作中遇到了，我们就写点文字。可以简单实现一个ItemHolder(ItemMgr)之类的东西，维护ItemID->ItemObj。注意ItemID"不是"Item的策划配置资源静态ID。背包什么弄一个Bag对象，直接维护ItemID就可以了。上面说得那个需求，只要把ItemID从Bag里删除掉，但ItemHolder还有这个对象。如果从安全方面进一步考虑，也可以实现抽象的存放ItemI 阅读全文

摘要：有的公司用C++做后台服务器的不用STL，理由一般是低效。效率可能主要是和动态内存分配有关。可以用一些手段，使用STL的时候让系统在运行的过程中内存保持稳定：不出现运行时释放系统内存的行为。通过举例子说明用STL保持运行时的内存稳定。Role 抽象一个游戏角色。RoleMgr 用一个hash_map管理所有的游戏角色，一个角色进入游戏的时候，RoleMgr就拿出一个Role对象。RoleMgr可以预先分配好所有的Role对象（当然是未初始化的），也可以运行的过程不断地创建Role对象，Role对象的内存空间肯定是稳定的，就是不删除重复利用。RoleMgr重复利用内存规则，这个很多人肯定都是这样 阅读全文

摘要：REQ(REQuire): 请求类协议，一般是client主动发起。RES(RESponse): 回应类协议，对REQ的一个回应，带有处理结果的数据包。ACK(ACKnowledge): 确认类协议，对REQ的一个回应，与上面的区别是数据包中只有确认序号之类的东西，没有其他内容。NTS(NoTiCE): 通知类协议，这类协议，接收者无须回应(RES或ACK)。 阅读全文

摘要：这个看似一个很简单的概念，但有些细节可能会漏掉。 直接用默认的new(malloc)/delete(free)，如果C库内部没有用一个memory pool，kernel肯定会出现碎片。有的C库如果提供一个公用memory pool有没有意义呢？个人认为意义不大，这种情况下，kernel碎片消失了，但C库的pool还是会出现碎片。问题没得到根本的解决，只是碎片从地方转移到另外一个地方而已。有人也有可能实现一个自己的公共的memory pool，效果和C库的memory pool是一样的。 实际中，可以考虑用一个专有的memory pool(可以称为object manager)，系统启动时，预 阅读全文

摘要：地图分进程架构和无缝大地图单进程架构有的游戏服务器，一个进程处理一张或多张地图上的逻辑，进入到不同进程的地图，数据须要一个进程间同步的过程。简单合理的同步做法是，先将数据同步到一个公共服务器；进入到目标进程后，再从公共服务器拉取本角色的最新数据。可以参考 http://blog.csdn.net/herm_lib/archive/2011/05/01/6381872.aspx 中的logicsvr1 dbproxy logicsvr2的关系。分进程架构有他的优缺点。优点 （1） 实现简单(当然，有的游戏所有的地图是在一个逻辑进程里，同步都省了，更简单)。 （2）分进程后，整个服务器组也可以支持 阅读全文

摘要：网游中，角色ID、公会ID和道具ID等一般设计成全局唯一。这样做，一个便于跟踪这些对象的生存状态；另外一个是合区不会产生冲突。用大区ID+大区内服务器ID+时间+生成序列生成一个64bits的数字作为全局ID，其中0表示非法的ID。 globalID = clusterID(8) + zoneID(8) + time(30) + seq(18)time(30)以秒为单位，可以表示34年。seq(18)是262144，也就说1毫秒内可以生成262个ID，5us一个，应该足够了。进一步讲，如果1s内，seq重复了，就生成0，表示生成失败，下一秒重试就行了。 阅读全文

摘要：SNS类型的游戏和RPG类的网游有一些不同的特点，而这些特点会导致这类游戏的后台架构和RPG网游的后台架构存在一些区别。SNS类型的游戏一般有以下的特点：（1）所有的玩家角色可能存在交互 SNS类型的游戏一个玩家角色会找他的好友或者其他任何一个毫无关系的玩家角色进行某种逻辑上的互动。（2）这类游戏玩家角色一般是看不见的（3）玩家角色在线或离线状态比较模糊 在线的玩家角色可以主动找不在线玩家进行交互。如去某个没上线的好友菜园偷菜，去攻打不在线的玩家角色的城池。（4）交互频率较低，数据量小。根据上面的主要特点，这类游戏后台要设计成唯一一个的大世界，而角色之间无须相互可见，实现这个大世界后台就有存在 阅读全文