整个系统只有一个大厅服务器(Hall Server), 大厅服务器收集房间服务器(Room Server)的连接信息, 提交给Web Server. 为了让Room Server的实现简单, 不让Room Server直接同Web Server交互. 当用户请求进入某个房间时, Web Server向Hall Server发送指令, Hall Server将指令转交给相应的Room Server. Room Server在这里可视为游戏服务器(Game Server)的接口. 当用户的请求得到允许后, 他将得到一个密钥, 用于进入Room Server. Web Client创建一个游戏进程, 并将密钥和其它信息通过参数或者stdio传给新起的游戏进程. 游戏进程连接Room Server, 开始进行游戏.
epoll, kqueue等单进程IO多路复用接口, 只在处理大批闲置连接时才能体现出优势. 如果每一个连接都很活跃, 请求的操作都是高IO和高CPU的, 那么瓶颈是机器本身的计算能力, 而不是连接的管理能力(这也是epoll等的作用). 这时, 如果能预先确定机器的计算能力所能处理的客户数量, 且数量较小的, 那么很多时候使用多线程/多进程(workers)更高效. 分析一下下面的攻击场景:
这种场景设想, 大量慢速但不闲置的连接, 将导致服务器的计算资源消耗在对就绪连接的迭代和read调用上. 这种攻击只是一种设想, 有待实践验证.
游戏中不可缺少动画. 在之前的图形界面实现中, 程序是基于用户输入事件驱动的, 除非使用单独的线程, 否则无法实现动画. 所以, 把程序改为基于时间驱动, 并使用精灵(Sprite)的概念. 精灵包含一个或者多个图像资源(帧), 以及其它状态信息. 这时, 使用C++来开发会更接近这种抽象. 主循环每隔一个时钟周期轮询所有的精灵, 获取它们的当前图像帧, 并blit到屏幕上页面. 也可以让它们自己blit到屏幕上面. 这就要求, 所有的逻辑处理都必须由开发者分解成流水线, 流水线的每一个片段都能在一个时钟周期内完成, 而且所有逻辑的流水线也必须能在一个时钟周期内完成.
while(1){
foreach(sprites as s){
s->tick();
}
others->tick();
sleep();
}
在前一篇日志(连连看游戏开发实践(1) - 算法)中, 已经做了一个命令行下的文字界面的连连看. 这一回, 我要给它加一个图形界面外壳, 将数字转换为图片显示, 用鼠标点击代替输入文字坐标. 程序运行界面如下:
|
Recent Comments