GameSrv讨论 之 一

默难

似乎我对桌面的理解有些错误了……
我的意思是：每个游戏一个进程
比如：打牌游戏一个进程，麻将的是另一个进程……
个人感觉应该加入plugin，这样可以动态的进行装载游戏
我的设想是：

默难

Games是由用户（制作游戏者）编写的，主进程和Games之间通过特定的协议进行通讯

sjinny

现在我提出另一个问题：
如果别人要为我们的平台写一个游戏，那么针对服务器端，哪些功能是要游戏编写者自己实现的呢？或者说，我们要给他们提供哪些功能实现？如果不能有效地降低联网游戏的开发难度，那么想让很多人来写游戏是不现实的~

wsm

各位收邮件没有？不是当作病毒删了吧？

可以把sjinny, 和默难, 的问题结合起来 如果我们实现动态加载，动态生成游戏服务进程，势必我们对这个游戏开发者的要求更多，对我们接口定义的要求也更高，这就是为什么我比较倾向于，我们的主服务和游戏静态分离的原因

divey

各位好小弟有一点看法,只是个人意见不要见笑.
一、主服务器与游戏服务器分开思考
主服务器负责加载各游戏服务器的地址,这样用户连入玩游戏时只连接主服务器
下载一下地址列表,保存在用户机器中.这样也能分散服务器的负载,各游戏服务器
可以由很多人提供,主服务器只要将列表更新一下,用户连入时比较本机的列表与
服务器列表,如更新则client自动下载列表.
二、关于桌的概念
游戏服务器的线程分配,每一个用户连入时服务器都产生一个线程为用户服务,称作用
户线程
(当然了这个线程的传送数据量是非常小的),负责每一个游戏者在没有开始游戏前的
所有动作.
游戏服务器还应该为每一个已经开始游戏的桌子分配一个线程,这里称游戏处理线程
,游戏处理线程负责游戏的逻辑(这里要做好同步,而且要处理用恶意dos的情况)
一个linux下的进程能创建大约1500左右的线程,这样考虑保守的说一个游戏服务器能容纳的人数就在500人左右吧,不知道2.6内核的是多少,我想一个服务器这样也就够了.
(我有一点不明白,采用阻塞式socket可以为每一个用户线程都创建一个socket吧？)
这样在创建一个游戏线程后,他其实也就是负责几个服务者的用户线程数据的传送
现在只想到这些.
..........以上只是个人想法,有不对的地方请大家指教........

wq1977

gamesrv的目的在于开放，但是绝对不是说 任何人都可以写服务器端的代码，因为性能和安全性方面的原因，服务器端的代码是由专门的开发小组开发和维护的。但是任何人都可以写客户端的代码，由于接口遵循统一规范，使得任何人都可以开发的客户端不至于对服务器的性能和安全造成影响，如果一个游戏一个服务器模块，那么肯定是每个人都要写服务器模块的代码了，这是不现实的。

ShiChao

看了楼上的搂上话，有点受启发，也比较同意主服务器和游戏服务器分开

我的想法是
主服务器和游戏服务器分别可以放在不同的机器上
游戏服务器负责桌面的处理
主服务器负责维护在线用户列表，用户的login和logout，维护桌面列表，转发消息给游戏服务器

也就是说，流程大概是这个样子的
client发消息给主服务器
主服务器判断是否应该自己处理
如果是，处理发送结果
否则，发给游戏服务器，等待游戏服务器处理，返回游戏服务器处理的结果

主服务器和游戏服务器用socket通讯，有统一的协议
一般的游戏服务器指负责转发消息即可，如果有特殊需求，开发者可以根据自己的需求实现自己的游戏服务器（比如防作弊等，就不需要plugin了）

divey

不明白你的意思,那你的意思是一个服务器带所有的游戏？
其实所有的游戏服务器代码中不一样的部分只是游戏的逻辑是不一样的
这点我已经说了.
性能与安全的代码当然不能谁都来写了
不要忘了主服务器还要负责用户数据的问题如果用户多起来了,式必要用到
专门的数据服务器,这样主服务器的负责是非常的重的,
我想设计的时候应该考虑到以后用户多的时候的情况
只是个人意见

divey

联众与边锋用的也是这样的设计思路,
还有一些其它的游戏也都是这样的，
这样做那些商业游戏可以轻松的找到合作伙伴,
开源游戏就更能找到合作伙伴了
(他可以宣传一些自己的东西,还不收他钱,呵呵)

ShiChao

我的意思是

GameSrv附带一个基础的游戏服务器

如果游戏只有简单的要求（比如麻将，只需要把每个人出的牌，告诉给对方，发牌的工作，一个client完成，然后再告诉别的人就行了）

如果是游戏需要一些特别的要求（比如要求服务器发牌，就可以更改GameSrv带的基础游戏服务器的代码，增加发牌部分）

如果像计时战略那样，需要很多的数据交换的话，就需要P2P来完成了，不应该由服务器中转


如果用户多了的话，最好能像linq那样，在不同服务器上的用户可以一起玩，不知道该怎么实现

wq1977

我想我们可以参考一下通信协议中的NGN模型，看看是不是对我们能有什么启发。
在NGN模型中，网源主要由MGC和MG组成，MGC称为网关server，MG则称为网关，在MGC和Mg中间通过H248协议或者Mgcp协议通讯，在Mgc之间则又有多种协议，包括Bicc，sip，isup等。 Mgc的核心是交换，也就是传统意义上的交换机。

大容量的Mgc可以带几十万个用户，也有几百几千的用户的小Mgc。

我们是不是也可以这样。把游戏客户端看作Mg，gamesrv看作Mgc，制定他们之间的H248或者Mgcp协议，以及bicc或者isup协议。

我的初衷是，gamsrv只有交换功能，以及一些抽象的逻辑，比如客户端可以请求server生成一个随机数序列发送给每个客户端，不同的客户端可以把这个逻辑解释成它自己的含义，以此来实现某些特定的逻辑。

divey

为什么要让不同服务器上的用户在一起玩呢？
用户想进哪个服务器就进哪个服务器好了联众不是这样吗？
每一个游戏服务器放在不同的地方,这样祖国各地都可以有游戏服务器
想想谁不想找一个速度快的,认识人多的服务器打牌呢？
其实不同服务器上的用户在一起玩,可能是通过主服务器的用户列表
得到对话的IP地址(或是其它的方式,linq没看过代码不知道他是什么方式)
,然后可能就是P2P了。

wq1977

当然可以登陆不同的服务器，这个不是问题，但是要实现分布式的服务器，就要制定分布式服务器之间的接口。

只是说有没有必要每个游戏在服务器上实现一部分这个游戏的逻辑。

想想看，如果期待中的游戏制作者是普通人，那么怎么能期望每一个游戏制作者提供本游戏的一个服务器呢？

divey

我想不要看这些什么模型,我觉得这样会束服人的思路,
可以设计好框架来跟现有的模式做比较看哪里要修改，
这觉行这样更好些.

ShiChao

看现在的样子，好像找不到一台服务器，祖国各地都有游戏服务器更是不太可能
如果是从服务器取得ip地址，然后p2p，那这么实现多台服务器上的用户一起玩也就没什么意义了。因为这样服务器不会因为转发消息而负载很大。

据前面的讨论，大家的意思好像都不是先取得ip，然后p2p，而是服务器转发消息吧