一起做网游吧【3】:数据库结构

趁着老婆还在睡觉,可以再更新一下网游教程的内容。本来这个内容要放到上一节中的,但写的时候忘了,只好单独做一个。
先看下数据的定义:

       -record( counter, {
           type,
           value
          } ) .
-record( game, {
           id,
           enable = false,
           pid = none,
           name,
           info=none,
           test_mode = true
          }).
-record( player, {
           count_id,
           id,
           nick,
           password,
           login_errors = 0,
           pid = none,
           socket = none,
           disabled = false,
           online = false,
           ingame = false,
           now_play=0,
           game=[]
          } ).
-record(client, {server = none, player = none, game=none}).

其实,我对上述的数据定义的某些内容并不是绝对的非常的熟悉(之前提到过,数据库的内容我知道的很少)。因为在我刚开始学习erlang的时候,看到了Joe Armstrong提到的openpoker(我希望是这个名字,好几年前了)的服务器,当时在国外,费了好几天的时间,才找到最后公开的源代码,然后,就照搬了一下。比如对于上面的counter,就从未查看过它存的到底是什么内容。从使用的方法上来说,主要是记录其他数据表的个数,然后,作为每个数据在数据表中的唯一的id。这里的每个数据表都是set类型的,也就是说,一对一的。由于erlang的record的中,是否是同一个记录,看record的第一个元素,所以player就有了一个count_id的属性。count_id主要是防止id重合的,最后有没有用到需要到最后查看代码才能知道。
game,从实际上来讲,这个并非其本意,因为在真实的网游服务器中,这是一个节点或者一个进程,至于这个进程的功能,可能是一个大型的游戏,也可能是一个很微型的游戏(比如猜拳),甚至是某个特定功能的npc之类的,在这里,我基本上都是一个小游戏,因为这个教程并不想做的非常的复杂和非常的大,这样,重复的代码比较少。而我之前可能也提到过,这个游戏可以动态的添加或者减少某些小游戏。id对于某个小游戏来说,是唯一的,客户端参加哪一个小游戏,也主要是靠这个id。enable是表明该游戏是否可以允许客户接入,如果不允许的话,客户不应该看到这个游戏。name不用说了,就是游戏的名字。info,本来是存储各个小游戏自己的结构的,但最后没有用到,在这次的整理过程中,也说不定会用到,就暂时留着。test_mode,主要指定小游戏目前是否处于测试状态,在本篇教程中,刚开始的小游戏一直是test_mode,而如果一个游戏是test_mode的话,就需要手动的来启动,而不能随着主程序一起启动。pid负责存储游戏运行的进程id,在互相通讯的时候需要用到。
player中的字段的含义从表面上基本都可以看得到,game本意是存储在各个小游戏中的数据,但到目前为止,没有用到,说不定在教程中写着写着就用到了。socket,online什么的,其实是沿用openpoker的,因为当时可参考的资料很少,就从它里面抽出了部分代码。
client,是服务器的整体结构,但并不往数据库中写。定义在这里只是防止其他文件需要。
以上的代码内容,存储在schema.hrl中。是时候出去买早点和叫醒小懒猫了。

一起做网游吧【2】:约定

这次接着上篇,上篇谈到目标,以及解决的方案。上次的程序模块的结构图像是由erlang自带的,appmon:start().便可以看到那个结构图像。
这次来谈下通讯的协议,数据封包的格式,关于数据封包的重要性,可以参考很早之前的外挂方面的教程,简单来说,封包协议就是客户端和服务器端通讯的语言,语言不对,将无法交流。
这个网游的协议,对于发送方和接受方,都只接受下面的封包格式:
【封包长度:4字节】【命令:4字节】【数据:不定长字节】
其实,封包长度和命令没必要使用4个字节,但我还是喜欢4个字节,看着习惯,比较好数。
对于数据中的字符串,按照下面的排列格式:
【字符串长度:4字节】【字符串:不定长字节】
对于数据的发送,分下面的情况:
1、如果客户端发送一个命令,服务器没有返回,则认为该命令发送成功,否则,服务器将会发送错误命令或者强制部分重置的命令及数据。
2、如果客户端发送一个命令,服务器返回相同的命令,认为是成功。比如发送一个登陆命令,服务器将返回登陆命令,及玩家的详细信息。
在任何时刻,程序都需要监视错误的命令。
以上约定,贯穿于整个项目。

一起做网游吧【1】

很早之前写过网络游戏的外挂教程,现在,将网络游戏的服务器教程提供出来。每个游戏商制作网游使用的技术都是不一样的,但我似乎已经习惯了孤独的写程序了,或者我的程序已经习惯了孤独了,看上去都没什么人采用这些技术(据我所知),因此,我希望我的这个游戏的整个代码(服务器和客户端)可以一个人的能力独立的完成,从目前的角度来说,是这样的。
如果某个人告诉你一个人独立完成网络游戏的服务器端和客户端,是一件遥不可及的事情,那么,现在,可以忘记这一切了。我的目标是写一个一个人可以完成的网络游戏,从目前角度和进步来说,这是一件可以完成的事情,如果你非常熟悉的话,完成一个中型的也不成问题。
关于这个教程中提供的游戏的历史:
1.这个代码从很早之前,我刚开始接触erlang的时候已经有此计划了,大约在两年前(2007年10月份)
2.这个项目中的代码(包含这个项目的教程)遵从GPL版权,不管是客户端还是服务器端,均遵从最新的GPL版权。
3.这个项目中的代码,经过很多次的变更,有些时候,随着我的兴趣不同而变更,我希望目前的游戏可以持续下去,目前来看,也比较可能最终完成。
4.项目持续的时间很长,并不是因为代码量的关系,而是因为很多时间,我都比较忙,无时间铺代码,或者心情不好等等,最长的中断时间大约至少达半年之久。
5.项目服务器端使用erlang与C++描写,如果你对erlang不感兴趣,以后的也不用关注了。
6.目前贡献的代码,是目前进度的代码根据回忆,进行整理的,因为我也觉得有必要整理了,里面很多的缺少注释的地方也应该补全了。这样,我也可以稍作休息,因为贴代码的速度比写代码的速度要快。而且,开始长时间中断的概率较少。
下面是正文的开始:
继续阅读一起做网游吧【1】