游戏服务端开发-二

应用服务器的设计（上）

 

应用服务器的工作有：0同步广播玩家的行为；1作为第三方对玩家个体和玩家之间互动行为计算，并将计算结果推送到数据存储系统；2驱动游戏中的NPC；3作为一个特殊的游戏参与者，与玩家相互作用。

 

应用服务器最重要的工作莫过于同步广播玩家之间的行为，使玩家之间能够互视，多人同时游戏才有意义。

最简单的广播莫过于向全体在线玩家广播，但这么大IO对客户端和服务器都是不可忽视的压力。理想情况下每个玩家的行为消息的受众是那些看的见此人的玩家。每个玩家都维护了一个列表，表中元素是自己看得见的其他玩家。我们假设每个玩家的视力情况是一样的，我看见你的同时你也看到了我。这样每个消息的发送目标就是这个列表的所有元素。至于这个列表，是随着玩家的移动而更新的。

 

服务器程序开发两个指标最重要，一是要快，二是要稳。面对纷至沓来的客户端请求不可能像Apache那样为每个请求派生一个子进程或线程来完成业务计算，也不能为每个客户端的连接派生子进程或线程，利用线程池也是应该避免设计思路。换句话说，对客户端的请求不应该设计并行计算的思路。我们假设现在有两个以上的玩家攻击一个NPC，如果我们对客户端传来的攻击请求做并行计算，那么在NPC很可能死上两次以上。因为玩家A读取的NPC血量为1，CPU切换到另一个玩家的线程，玩家B读取的NPC血量为1，玩家B继续杀戮，NPC的血量从1到0，死亡一次，这时CPU切换到玩家A的线程，在这个上下文里，NPC又经历了一次死亡。这种荒诞的现象正是多线程数据不同步造成的。而同时游戏应用里数据读写操作十分频繁，对数据加锁并不是一个好主意。如果锁的粒度过小，系统将在锁的检查上浪费掉大量的计算时间；如果过大则异步并发没有意义，试想一下我们将每次攻击设计一个同步块，那么对一个Boss会有多大的延迟。

 

另外一个致命的问题是，玩家之间是异步的，每个玩家的行为是序列的。如果将玩家每个行为交由线程池计算，则这种序列性无法保证；如果将当前玩家当前所有的行为以队列结构交由线程池处理，则会占用CPU资源，对其他玩家并不公平。

 

多任务操作系统其实在某一个瞬间也只是执行了一个进程，可是系统却在少食多餐，表面上多个任务同时在进行。游戏应用程序也可以对所有玩家做迭代计算，每次只计算一个行为，保证所有玩家在短时间内都是活跃的即可。