GameSrv讨论 之 一

divey

不是说了吗每一个游戏服务器的不同之处只在游戏逻辑上,
但是也不能在游戏服务器上不能没有安全与性能的代码,
这样所有的服务器的负载都分散了,对游戏的速度跟扩展性都提高了

divey

晕,没有p2p这一说呀,我是说你说的linq的意思,
p2p在这样的游戏里是不可能的,游戏服务器就是负责消息的转发,跟主服务器通信
来保存用户的某些状态

wq1977

p2p的话首先如果不具有公网地址就会很麻烦，其次客户端的安全性也没什么保证。

原先的设计，客户端是不知道彼此的ip地址的。

divey

这个是当然的了客户端之间没有什么联系的,
我所说的从主服务器取IP地址列表中的IP指的是
各个游戏服务器的IP地址列表,然后在client生成
游戏服务器列表就像是联众那样的列表,其实联众就是这样做的

divey

晕怎么谈到P2P去了,我说的是linq的不在同一个服务器也能一起玩,
那个可能是从服务器取对方用户的IP，然后就是P2P了，
不是我们谈的Gamesvr的.

wsm

linq的不在同一个服务器也能一起玩

这个目标太大了 我们目前没有这个需求吧

原先的设计，客户端是不知道彼此的ip地址的

这样服务器端要做的事务太多，分析现实情况是我们不太可能马上有强大的服务器，加强客户端的要求就减轻服务器的负担

还有一些根本设计思路的问题 我们究竟是在做一个模型还是一个现实可用的东西？
我的建议是做的越实在越好。可以看到不少人在作什么库什么框架什么新内核，结果谁来用？
没有第一批用户，永远是失败的。
我认为我们要定清目标，我们是要做出在现在的条件下一个大家可以玩，玩的高兴的东西，然后才是考虑是否别人可以做什么扩展。
联系前面的问题：
主服务器和游戏服务器分开，mg和mgc模型（我做这个做了1年）先不说其中的健壮性问题和安全问题，我们开始的时候能有多少服务器来做这这种部署的？如果一个冬冬一出来就是要求很高，那他就很难得到支持。假如我们实现一个简陋的静态进程的模型，等到游戏真的做大了做好了，修改一下也不会是问题。
第三方开发游戏模块（姑且这么叫）的问题？现在边锋上面支持40多个游戏，我们会有多少？如果全部游戏的服务器端都要内部开发，我们能维护多少个游戏？别人愿意加进来的，测试基本ok的，都应该允许。
（这也是为什么做静态模型，别人或许已经作了一些通过网络实现的游戏，那么稍微修改一下就可能加入到我们的游戏中，而用什么模块 plugin无疑是加大了这种难度）

divey

,同意。
不过,第个client都是不知道其它client的IP这点没错呀。

sjinny

偶也说两句~
说说技术以外的问题吧，根据我的经验，现在我们需要的是一个可以玩的“垃圾”，但是要能玩得起来、玩得尽兴~在这个不能算正式作品的作品生存的时期，我们主要是组建和磨合团队，但是这个“垃圾”的框架要优秀（至少要正确）；第二步就是完善前面说的“垃圾”，让它变成这个项目的第一个正式发布的作品，在此作品的生存期中，我们主要是发现现有框架的不足之处，积累经验；第三步，可能需要推翻以前的架构，以积累的经验为基础重新提出一个非常优秀的架构，然后靠这个架构使项目真正发展起来，这个架构就会成为a new begining & a new hope。
技术方面，游戏数量太少当然不行，但是所有游戏的开发是否应该完全靠我们这个项目呢？我觉得不好，举个例子，Linux下硬件的驱动程序很重要，但是如果让Linux核心团队以外的人去开发驱动程序的话，是否会有安全问题呢？当然会有，但是是否就要因为这个而让Linux核心团队去为无数的硬件开发驱动程序而不接受其他人的驱动程序呢？游戏的服务器端完全由我们这个项目来开发是不现实的，如果用别人的也会有安全性问题。但是可以这样：
1。我们作为项目开发团队，在我们发布的程序中不包含任何具体游戏的服务器端，那么想建游戏站的人可以自己去下载游戏服务器端模块，这样如果因为哪个模块不好而出了问题也不是我们的责任，是GM选择了那个问题模块，是别人开发了那个问题模块，就像我们安装了一个开发地不好的程序一样。
2。假如采用我的方案，那么没有游戏服务器端模块其实都是受主程序的控制的，只要保证不让各模块间互相有影响，那么就没有大问题，即使哪个模块有严重bug、发生死循环之类，主程序把那个问题模块unload掉就行了。

wq1977

大家都喜欢玩什么游戏？
如果有哪个游戏投票超过一个游戏桌的人数，我们就一起做那个游戏吧。

ShiChao

四国军旗

默难

首先，我认为软件的工作环境是：
（见下图）
即：
将应用层划分为两个层：
GameSrv工作在下层，
每个游戏工作在GameSrv之上。
GameSrv从网络上接收数据，对数据进行分析，将有效数据去掉头部后（GameSrv之间的通讯用的头部）传给相应的游戏（具体哪个游戏，根据头部而定）GameSrv对于每个游戏来说是透明的。每个游戏都是由GameSrv通过fork和execl得到的子进程。GameSrv与每个游戏之间保持三个管道（pipe）：
一个管道负责给每个游戏发送信息，对于每个游戏来说，这个管道是标准输入（stdin），如果每个游戏想接收数据，那么可以直接通过scanf getc等函数接收。
另一个管道负责接收每个游戏需要向外发送的数据。对于每个游戏来说，这个管道是标准输出（stdout），如果每个游戏想向外发送数据，那么可以直接通过printf putc等函数实现。
最后一个管道对于每个游戏来说相当于标准错误输出（stderr）
这个很像Linux上的tcpserver之类的东西。
游戏的编写者不用关心网络的数据传输，只需要将需要传出的数据写到标准输出上，要接收数据只需要从标准输入接收

默难

如果某个游戏需要对用户的属性之类的进行操作，那么就按照特定协议通过共享内存与GameSrv通讯

sjinny

默难说得有道理，GameSrv应该是为各个游戏服务的~

hibernate

讨论了这么多
我也觉得我们该做一点切实的实验的东西出来
没有试验性的踏出第一步
我们永远到达不了彼岸
我的个人意见是：
我们现在可以不考虑是否支持多种游戏支持可扩展
我们现在可以只做支持一种游戏比如扑克
一个主进程每一桌为一个子进程每一个参与者一个线程（或者根本不用线程）
做个简单的以后再慢慢修改甚至推翻重做
这样至少可以形成一个团队一些用户
否则也就成为了纸上谈兵了

默难

我觉得我们首先需要明确的是：
我们做的不是游戏，而是为游戏制作者提供一个简单的环境
因此我们暂时不要考虑在GameSrv之上建立什么游戏，而是要为Games与GameSrv、GameSrv与客户端之间的通讯建立一个统一的协议。