GameSrv项目招募志愿者进行合作开发

wsm

这里说一下我的构思,我是完全以现在的边锋之类的游戏为借鉴的：
client部分也需要修改为mainframe+plug的方式，现在这个构架来看用户要玩两种游戏就要两个完全不一致的client,对使用来说不友好，也不方便版本升级。
用gtk作界面我不太清楚实现这种方式是否简单可行，但用gtk的东西摆明了是抛弃windows用户了，关于gtk的兼容之类的问题我不懂，但如果这个东西拿出去想让人玩的，不考虑window用户是不太可能的。（实际上我的感觉是：前端界面用java作很容易实现模块化和升级增加游戏的机制，也许是因为做过java的缘故吧）
另外客户端要考虑的就是消息格式，客户端的主干部分要维护这些消息：
用户登陆/注销/申请，服务器/游戏的选择/转移，客户端升级/下载，用户数据同步
其他的都不需要了解，因为这些是具体游戏模块要确认的。
也就是不同于现在的作法，上面这些消息和具体游戏中使用的消息有相同的消息号是可以的，因为不会也不应该有一个服务器端进程来同时处理不同类的消息。

wsm

再说服务器端的：
数据库的功能我认为是必须要的，否则对玩家没有任何玩的意义。而且数据库中的功能定义可以减少一部分应用服务端的任务（比如玩家级别头衔以及升级奖励等等 都可以在数据库的定义中完成）
除此之外服务器端就是两类进程
1：接入服务 管理用户登陆/注销 由他在用户选择游戏类别后将此用户派到相应的游戏服务进程(简单的可以只是通知client游戏进程的服务端口，然后client可以转向和特定游戏服务进程联系)，如果用户一直没有选择游戏或暂时离开所有游戏，这些用户是和这个服务进程联系的
这个进程必须派生线程，至少要为那些初次加入登记个人信息的用户派生单独的线程来防止堵塞
2：游戏服务
特定于某一种游戏的服务，他至少要完成的是用户数据同步，玩家一些操作的维护（比如到那个桌上了，向那个用户发消息）,开始游戏服务线程
游戏服务具体的线程要：开始/结束一局游戏，相应用户信息的维护,游戏异常的处理
（逃跑，断线等等）

wsm

呼 感觉说了好多
我感觉这个东西是很有前途，作的好的话可以让每个感兴趣的人做出自己的游戏client和游戏服务来让大家玩。（当然要服务器够）甚至将来可以做robot比赛......
开放就胜过一切，什么连众边锋永远只是玩具
虽然我也只是搞了2年多的软件，可还是要“说点经验”，先定义模块和层次吧
我还没有见到哪个设计周期占总开发周期1/4以下能够做的比较好的项目

wq1977

wsm说的很中肯，我先来说说将来的样子，就是说，到底要做一个什么东西出来。以前我模糊的说过要做的东西是联众，现在想来不是。

在我期望的模式中，客户端的开发者，彼此甚至是毫无关系的，一个人在天涯，一个人在海角，谁也不认识谁，谁也不知道谁在做什么东西，彼此使用着不同的framework，你可能用着gtk gnome，我可能用着Visual C＋＋。你可能在做着纸牌，我可能在做着麻将，要说他们之间还有一点点联系的话，那就是他们的客户端使用的是同一个服务器，成千上万的人，通过浏览器访问同一个server下载到了他们的客户端，从而认识了他，认识了她，但是他们还是互不相识。 我不希望给客户端开发者任何限制，我更不是要把开发者招至麾下，一起来做一个庞大的游戏平台。

没有人计划什么时候要出一个什么客户端，一切都是出自自愿，想写游戏的冲动，很多人有好的创意，但是他们没有服务器，他们可能只是某个学校里的穷学生。

当然，关于我不堪入目的代码风格和笨拙的算法的批评我完全接收

关于用户信息全在内存没有保留到数据库或者文件，原因是我本想只保留用户名和密码，不收集任何私人信息，后来又想这样的话还要密码干什么，后来又一想，既然这只是个无意义的用户名，还保存它干什么。直接用户等入的时候注册，登出的时候注销算了。所以就成了现在的样子。

sjinny

我根据wq1977的意思猜测：这个项目实际上重点还是在服务器，服务器的开发是和客户端无关的，也就是说服务器端的程序不关心任何游戏细节，只关注各种游戏的通用功能。也就是说，这个服务器端程序是个各个游戏提供服务的，然后各个具体的游戏再给玩家提供游戏服务~

sjinny

关于 网络小游戏的通用服务器平台...


网络游戏有很多种，联众这种就属于小游戏，传奇之类就不是了，因为此类“小游戏”技术相对不太复杂，所以还是比较可行滴~
“通用”二字何解？就是说，这个“服务器平台”不是某个游戏专用的，联众也就是这样的。
一时没找到GameSrv的代码，先谈谈我的想法吧：
因为服务器不是针对某个游戏而开发，所以网络通信的协议（也就是如何包装和解析数据）就得全由客户端提出，服务器按照规则办事而已。一般的小游戏，典型代表是棋牌类的游戏，它们都包含着人与人之间的竞技甚至争斗，所以需要作为“第三方”的服务器来维护游戏的公平性和对游戏结果评价的公正。所以，服务器端需要有一个模块用来检测每个客户端发出的数据报的合法性，还有保存游戏状态等。每个游戏在客户端都有一个客户端软件或客户端插件，在服务器端都有一个对应的模块。

关于服务器端的模块：
Game类：
一个服务器中可能会存在此类的多个实例。
每一个Game类的实例都对应了一个游戏，也就是游戏桌或房间的概念，它里面保存了这个游戏里所有的数据，当然还要有相关的成员函数；比如：假如是一个五子棋的游戏，那么其成员变量中就有一个二维数组，成员函数负责处理某个客户端发出的数据报的合法性，向房间中的人广播游戏数据，判断游戏的胜负等。当某个游戏结束时，其对应的对象也将被delete，在析构函数中还要包括一些数据的处理，特别是如果有积分制度的话还得计算和累加积分。但是，所有game的网络操作都是统一进行的，也就是说一个Game类实例要向玩家广播数据时只是把数据包送给服务器平台，自己并不进行socket操作，收到数据也是由服务器平台引起的，同样不会自己去读取socket。
run()，一个函数（详细功能见下文），并没有包含在任何类中，其内容是：
[code:1]
{
  while(1==gaming){
    <游戏循环的内容>
  }
  <进行游戏结束时的收尾工作>
}
[/code:1]
Manage类：
一个服务器中只有此类的一个实例。
它负责管理这种游戏的所有Game类的实例：
1。当服务器平台告知此模块有用户申请开启一个新游戏时，它将创建一个新的Game类的实例，并创建一个新的线程去处理此Game类实例，这个线程中运行的函数就是上文的run()函数，每个run()函数中游戏循环中都会对一个game对象进行操作，这个对象就是段首讲的那个“Game类的实例”。当然game运行的过程中此线程要和服务器平台所在的进程或其中的线程进行通信。
开启一个新游戏的过程是：
[code:1]
{
  Game* game=new Game;
  <创建一个新线程: 其中运行的函数=run(); 传给这个函数的参数=game>
}
[/code:1]
2。它将保存这个游戏的全部信息，这样服务器平台才能识别这个游戏。也许还可以在这个类中加入一些统计功能。
ps：忽然又想到另一个模式，原来想的是在线程的外部创建好Game类的实例并进行初始化，然后再传给新线程的处理函数；现在想到其实可以把Game类的实例初始化时需要的数据作为参数传给新线程的处理函数，在函数中创建新的Game类实例并初始化，这样当游戏结束时随着run()函数的结束，Game类的事例也会自动被释放的，剩得再用delete了。
3。可能需要Manage类的实例定期地检查游戏，比如是否运行正常，比如是否有哪个已经结束的游戏的数据或线程资源还没被释放的；发现问题的话就要进行日志的操作和尝试自己解决问题。
每个服务器的模块都要做成一个动态连接库，然后由服务器平台载入。不过不知道C++的类能不能做到库里面。不知道Qt之类的是怎么弄的。反正一个服务器模块也就相当于一个插件吧。

客户端暂时还没想到什么~

wq1977看看撒~

ShiChao

我在想：
服务器应该提供哪些功能？
我以为，服务器只需要提供用户登陆，注销，用户当前状态，IP，目前的房间列表... (就是可以把几个客户端放在一个房间里），可能还有转发消息

剩下的事情留给客户端，毕竟每个游戏的需求不同啊


在下的愚见啊，不知道有没有表达清楚

sjinny

关于客户端，我提出几个看法：

首先要设计一个完善的通信协议，完善与否的标准如下：

1。是否具有通用性，也就是能否让各种不同的游戏使用这同一个协议来让客户端和服务器端、以及和其他客户端进行通信；
2。是否具有可扩展性，也就是以后能否给协议增加内容以适应变化，同时还有个含义：能否让各个游戏的设计者根据具体的游戏对通信协议进行扩充以实现某些功能；
3。要确保功能、效率和安全性的统一协调；

当然以上标准可能高了点，不过那只是目标，不一定要完全达到滴~

然后要设计一个具有通用性的游戏客户端，这个客户端采用主程序+插件的方式工作：
主程序包括功能：

1。聊天，包括聊天室和p2p的私聊；
2。通知系统，这样游戏服务器有什么消息可以通知客户端，消息分位两类：一类是给游戏玩家看的，一类是给程序发送消息的；
3。插件系统，一个插件就做成一个动态连接库（Linux和Windows下都有动态连接库的机制），插件系统要能管理好插件，包括：
[quote]
3.1。插件的载入和卸载；
3.2。当运行一个插件时，这个插件一定要使用一个线程来工作，这个线程要和主程序相对独立起来，当某个插件线程发生了错误（比如死锁等）而不能正常工作或不响应用户操作时，主程序要能判断插件线程状态并对出现的问题进行处理（比如重新启动出错的插件线程、记录出错的插件按照插件出错的机率来安排此插件线程的运行优先级等）；
3.3。从插件里提取这个插件的说明（希望能有这个游戏的玩法说明 ）；
3.4。插件和主程序的兼容性检测（或者是版本匹配检测？）

4。网络通信功能，这个当然是为各个游戏插件服务的底层模块啦~
5。数据库功能，主要用于：

5.1。保存和管理聊天记录；
5.2。保存和管理游戏记录（比如玩家也许会要求下棋后保存棋谱）；

6。Skin（换肤）功能，我觉得这对一个娱乐软件也是很重要的；
7。也许还需要能够播放背景音乐？
8。难道还要文件共享功能？
……
[/quote]
插件的内容：

1。向主程序说明游戏的界面然后由主程序来管理这个界面，具体的比如：
[quote]
向主程序说明一个按扭控件，然后告诉主程序：当这个按扭被按下后执行foo()函数（把这个函数的地址给出来……）
当然，Timer（记时器控件）、socket（网络控件）、Datebase（数据库控件）等非界面控件也是必不可少的……

2。管理游戏在客户端的游戏逻辑，包括：

2.1。规则检测（到了服务器端还得检测一次）；
2.2。游戏中一些多媒体效果的显示等；
2.3。游戏界面中发生的各种事件的处理（通过回调函数来实现）；
2.4。这个游戏的网络数据的打包、解包、分析、处理等工作；
……

3。要提供这个插件和游戏的说明；
……
[/quote]

说完客户端，我再侃侃服务器端：
上面我有个帖子写了对于服务起端我的想法，这里再补充说明一下：
服务器端也是采用主程序+插件的模式：
主程序：

负责通用功能，与具体游戏细节无关……

插件：

一个插件对应一种游戏，每个游戏“房间”都是单独的一个线程……

以上是我个人的一点想法……

sjinny

补充：
只要设计好了游戏的通信协议（客户端和服务器间的协调机制），客户端是否使用主程序+插件的方式也不一定，一个人只要愿意完全可以自己单独做一个客户端，只要使用约定好的协议就行了~

wq1977

呵呵，同意

可是老大们说最好不要侧重服务器，因为服务器要很多钱。

wsm

sjinny的想法基本上已经按照oo的思路来 看得比较具体了 不过大致上我们的想法还是比较一致的 其实现阶段对客户端具体某个游戏的功能可以不做详细的考虑
比方说：是否有聊天功能，这我想可以在各个游戏模块内部决定是否需要或者允许 如果你在打麻将 现在很忌讳就是互相通牌
象是房间数目也应该是各个游戏自己可配置的 比方说双扣4个人允许20桌 那么捉奸细就只允许15桌 因为每桌人多了 负荷大了
现在做的话，自己的客户端是必须要有的，也就是一个“官方”的基础版本是必需的，这个官方版必须是能够让大多数人认识熟悉我们的系统的。由于是opensource，别人需要怎么改怎么移植那就是发展起来的事情了。
我们可以从一个两个游戏开始，当然主要目的是测试服务器端的可靠性。
这里也该说到需要估计以下大概需要多少人了。什么时候统计个邮件列表方便讨论和联系吧
ps:sjinny说到了背景音乐，这个...我现在最讨厌就是边锋的喀喀声了

我的邮件：[email protected] 申请加入
我是属于几乎不用im的人群。

ShiChao

sjinny 果然强

wq1977

呵呵，IM有时候还是需要的。昨天晚上和applepie老弟试了一下找朋友，可惜applepie老弟不擅长玩纸牌游戏，于是我们通过msn一步一步交流下一步给出什么牌，测试的结果证明 目前的那个demo server 在这种模式下也还是工作正常的（服务器在cosoft，applepie是P4+adsl+redhat，我是P3+长宽+redhat）.

感觉大家的想法越来越一致了，很开心。

不过老大们的担心也不是多余的，服务器是很贵的资源，的确不太适合开源的这帮穷人。

所以我也想过以后发布的时候可能真的会像找朋友一样，在客户端的发布包中带一个server，即使没有公用的server，也可以自己在局域网上架一个server玩，不过这样的话这个server的优势也就没有了，所以还是有公开的server的好，只能看哪位有钱的大佬能慷慨解囊了。

不过我考虑将来在server上嵌入一个小的web，server，客户端可以通过普通的浏览器查询目前有多少个game，desk，player在这个server上登记，以及他们的信息，比如在哪里下载某个game等，同时似乎也可以有一些糊口的广告在上面。

不过这都很遥远了。

ShiChao

linuxfans能不能给提供一个server

还有，不同server上的人，能不能一起玩（这个是不是有点麻烦），每个server上，保存他所知道的其他server的地址。

这样，可以减轻主server的负担

sjinny

恩......说到服务器......
现状是：我们不能指望有谁真的慷慨解囊出钱弄个很好的服务器……
但是我们可以指望能得到一些有限的服务器资源，但是可以肯定的是这些服务器资源都是很小的……
所以一个理想的方案是：把网上零散的服务器资源联合起来。
比如：国内有三个协同开发站点：GRO、 COSOFT、linuxforum的，假如我们能从这三个站点争取到一些服务器资源，比如都允许我们在他们的服务起端运行我们的程序，那么就需要让这三台服务器协同工作，联合提供服务，对普通用户而言应该和使用一个服务器没有区别，同时应该提供一种机制，这样假如还有其他组织或个人想建站也可以方便地和已有的游戏站协同工作。这些思想最初我是从Linq那里学到的~
……
似乎一下子还想不出什么好的协同工作的机制，因为服务器的细节还没有确定……

不过我曾有过一个想法：
如果我们假设所有玩家都是诚实可信的（他们不会作弊等），那么我们是否还需要一个传统意义上的服务器？
如果把CS在局域网中的模式扩展到Internet上呢？
当然这只是一个想法而已，目前还没什么实际意义，只是在这里说一下~

目前的设计，服务器的作用其实就是：
1。让一个玩家能够找到其他想玩同一个游戏的玩家；
2。保证游戏的公平性；
所以每个具体的“房间”（每个具体的游戏过程）是否在同一个服务器的支持下进行是不重要的。