PHP5网页游戏开发入门教程.doc

网页游戏开发入门教程一（webgame+design）
 一、简单的程序框架。
webgame程序构成：
三大部分。
第一是数据流程。第二是程序。第三是美术。
其中，数据流程包括了功能。也只有在功能中才能体现数据流程。
数据流程相当的麻烦，后面再讨论。
比如最简单的卖买产品。
要实现这个功能。
那么需要有产品基础表、产品详细表、商店表、背包表。如果扩展性更强，相应的双表是少不不了的。
表的问题都简单了。关键是这个物品有什么用。这样物品的来源，一大堆数据，物品的走向，又是一大堆数据。
最后，这些数据得绕成一个圈。
绕圈是一件困难的事情。特别是功能和道具多了起来的时候。难度是2的n次方。
在绕圈之前，如果你比较熟练设计模式。那么这个过程可以简化。难度由2的n次方变为1。
只需要有控制器、事件工厂、抽象道具工厂这三个虚类；再加上定时器，任务编辑器，这两个通用类。即可以构建一个健壮、高扩展的webgame。
在webgame里控制器几乎可以等同于页面。随便采用一种模板技术即能很方便的处理。
事件工厂是一个抽象类，所有的事件，如打工、战斗、移动等都由事件工厂的生产。并且接口相同，方便控制器控制。工厂模式。
抽象道具工厂是一个抽象类，所有的道具，如城市、地图、装备等，都由抽象道具工厂生产。并且接口相同，工厂模式，事件与道具的结合又是一个桥接模式。
美术：
UI。简洁漂亮的界面总会有好处。小图标。道具，地图，装备。一类至少10个吧？大体上百把个是需要的。
程序分5个部分：
服务器定时器。（C语言或自己设定服务器）定时循环执行某一段代码。而这段代码主要是根据数据库的数据进行更新。这个可以找个C语言程序员来做。对于C语言程序员来讲，这个功能是相当的简单。当然，具体的处理数据的判断和操作数据库，需要你自己写。让C语言程序员给你段标准代码就行了。完全支持sql语句的。
php的话，可以配置corn实现。但是不管是什么操作系统，配置的时间最低是1分钟。所以，如果你要处理1秒钟刷新一次的情况。你还需要专门的定时器程序来处理，或者被定时执行的php需要包含sleep().当然，即使有即时交互，可以不管服务器端。只处理交互的双方的客户端。js和ajax实现。
功能页面、功能函数。主要就是数据存取，判断，数据走向。
用上抽象类，会比较轻松。不过子类的爆炸是少不了的了。
ajax函数。（可选）某些需要伪即时的功能要用到。
为了让游戏看起来酷一点。用吧。
javascript函数。（可选）模拟客户端的数据计算。也就是webgame的与时间相关的数据。分为两部分。一部分是真实数据，是由服务器端的定时器计算的。另一部分是只有初始值，客户端显示用的。不需要即时同步，仅仅需要模拟同步就行。
这里还包括一些漂亮的UI特效。毕竟是游戏。
数据库。一大堆基础数据表和详细数据表。基础数据表：比如等级1到等级100的用户的属性初始值。详细数据表：每个用户的具体属性。
数据库上，尽量优化。结构上能用1字节的就别用2字节。

二、一个详细的例子。
单纯的讨论数据流程是件痛苦的事情。
讨论程序而不给代码也是比较痛苦。
这里用的是php+mysql的。同时，这个例子没有用到类。如果时间充足的话，今年年底，我会提供一个带即时交互的简单webgame代码和核心类来说明使用了设计模式的好处。
那就按一个超简单的webgame的方式来讨论。配上适当的代码。应该有所帮助。不足的地方也请大家指出，对我个人也是帮助。
我们不去考虑游戏的可玩性，数值平衡等等问题。我们先只考虑一个简单例子的实现。
那么一个webgame的基本内容需要些什么呢？
数据库：玩家、地图、城市、建筑、武器、士兵。
功能：登陆、升级、个人战斗、士兵之间的战斗、与城市的战斗、修建建筑、打造武器、买卖道具。
（注意：每一个功能，必然对应1个或多个数据表。上面数据库中所列的只是基础中的基础。）
首先是地图、城市、建筑。
这里认为，地图可以有多张，城市在地图上，建筑在城市内。
地图表
Map  :Map_ID ,X坐标, Y坐标,City_ID(城市ID),描述。
其中Map_ID是指地图的id。不是自动编号。一张地图就是一个Map_ID，可以重复。
城市表
City:City_ID,城市名字，城市所有人，城市等级，城市资源，描述。
建筑表
Build:ID，City_ID，建筑名称，建筑等级，建筑功能。
其中，地图表确定城市的位置，城市表确定城市的相关数据以及所有人，建筑表内的多条信息属于某一个城市。
建表后，显示出来。
一个for循环。把地图表整个取出来就ok。
跟普通网站的新闻列表没太大区别。不同的是，你需要取得X坐标和Y坐标定位。可以用tabel也可以用div。

 1 class Map//地图类
 2 {
 3 var $Map_ID;
 4 function Map_bg_css($Map_ID) {
 5 
 6   $this->Map_ID = $Map_ID;
 7     
 8   mysql_select_db($db_name,$link);
 9   $sql="select * from map where Map_ID='".$this->Map_ID."' limit 1";    
10   $result=mysql_query($sql,$link);   
11   echo "<style type="."text"."/"."css>";
12   $rs=mysql_fetch_array($result);  
13   
14    echo "#map{";
15    echo "position:absolute;";
16    echo "width:".$rs[X坐标]."px;";
17    echo "height:".$rs[Y坐标]."px;";
18    echo "z-index:0;";
19    echo "left:0px;top:0px;}";
20   
21   }
22   
23 function Map_bg($Map_ID){
24 
25   $this->Map_ID = $Map_ID;
26    
27   $sql="select * from map where Map_ID='".$this->Map_ID."'";     
28   $result=mysql_query($sql,$link); 
29   while($rs=mysql_fetch_array($result))  
30   {
31    echo "<div id=Layer_bg_".$rs[X坐标]."_".$rs[Y坐标].">";
32    echo "<img src=".$rs[Map_bg]." border=0 title=".$rs[ID]."></div>";
33   
34   }
35    
36 } 
37 }
38 
上面是一个很简单的地图类。代码可能不太正确，意思是正确的。就是根据map表中的坐标，生成了一组div层，以及这一组层的css。
你可以改为table的。你可以也把坐标放到一个字段里，用数组的形式取。
使用的时候，用
new map;
map(N);
其中N是map表里的地图Map_ID.
城市内的建筑也类似。如果要显示出来的话。
关于地图，现在我采用的方式更为简单。通过坐标来判断需要哪些图，然后直接显示出来。当然没有碰撞什么的，因为暂时不需要。至于人物走动什么的，不在本文讨论范围。
有了地图和城市后。涉及到的问题就是城市里资源的产生。
这时候，City表里需要有可供判断的时间和数量的字段。
比如：产生资金量Money,产生资金花费的时间Action_Time,上次产生资金时间Money_time。
这两个字段的数值应该在City_base表里出现。（即城市基础表，不同等级，不同类型城市的对应数值。这是给策划填数据用的，建好表后就等策划去头痛吧。如果你身兼数职。。。）
如何自动产生资源呢？
我们可以在城市所有人改变的时候，写入一个时间。或者在城市初始化的时候写入一个时间。
$Now_Time=date('Y-m-d H:i:s');
(说明：$开头是变量的意思。php里特有的。如果是asp的话可以写成。Now_Time=Now() )
把$Now_Time写入到Money_time里。
update("UPDATE City SET  Money_time='$Now_Time  WHERE  City_ID='$City_ID' LIMIT 1;");
$City_ID是你自己定义的。指某一个城市。如：$City_ID=1;
我们假定当前城市产生资金量为100。即$Money=100；（具体的数值，应该是由City_base表里取出的。）
假设间隔时间为$Action_Time,我们再假定是每小时执行一次。即$Action_Time=3600；（具体的数值，是根据你的初始化表里取得的。也可以根据城市等级或者用户等级取得。反正随便你自己怎么设定。）
这时候，有基础时间了。有基础资金产量了。有间隔时间了。让它循环执行起来就行了。
上面说过，服务端用C语言定时器。客户端用javascript。
服务端，资源定时器设定为5分钟执行一次。那么我们的误差就是5分钟。对网页游戏来说，可以接受。（战斗的定时器得1分钟吧。当然服务器够牛的话，几秒钟都可以。）
当然，可以完全php写，然后配置php的corn。现在我在做的程序就是直接用php写了。包括任意长时间的定时器类，专门控制抽象事件用的。C的定时器暂时没用。
每次执行什么代码呢？
首先得新建一个定时器任务的表。目的就是让定时器知道需要执行哪些程序和数据的更新。表内容比如：城市资源更新。当然，这个表可要可不要。建立的好处是方便处理类似保护状态不产生资源之类的问题。

服务端程序：
获得当前服务器时间。
获得当前需要更新城市。
判断服务器时间与$Money_time的时间差。（时间戳，具体的时间戳网上资料满多的。）
判断时间差是否大于$Action_Time。
大于，则更新资源。同时更新$Money_time。
小于，则无操作。

客户端程序：
获得当前服务器时间。
获得当前城市的$Money,$Money_time,$Action_Time。
使用javascript显示剩余时间的倒计时，以及增加的资源量。

客户端特殊情况触发：
因为客户端显示的资源情况是伪同步，所以当客户端使用该资源的时候。需要服务端将当前的实际资源更新，属于定时器处理的时间也需要更新。
即，当客户端触发涉及资源的情况时，立即更新当前资源。同时更新定时器中会用到的$Money_time。这样才不会造成，看的资源用不到，或者定时器重复产生资源。

总体来说。这部分程序都很简单。难点在C语言定时器的制作，以及前台javascipt倒计时的写法上。
C语言定时器，找个C语言程序员，超简单；前台的javascipt，网上有很多倒计时的代码，找个来改改就能用。

1 <SCRIPT LANGUAGE="JavaScript">
 2 var maxtime = 这里是你的时间差///一个小时，按秒计算，自己调整!
 3 function CountDown(){
 4 if(maxtime>=0){
 5 minutes = Math.floor(maxtime/60);
 6 seconds = Math.floor(maxtime%60);
 7 msg = "你的文字说明"+minutes+"分"+seconds+"秒";//动态显示剩余时间。
 8 document.all["timer"].innerHTML=msg;
 9 //if(maxtime == 3) document.all["timer"].innerHTML='只剩3秒！';
10 --maxtime;
11 }
12 else{
13 clearInterval(timer);
14 document.all["timer"].innerHTML='时间到';
15 }
16 }
17 timer = setInterval("CountDown()",1000);
18 </SCRIPT>
19 
20 <div id=timer></div>
21 
这个是网上找的代码。稍微修改就可以用的。这里只是显示了倒计时。也可以改为显示资源的增加情况。

C语言里操作mysql数据库。

1 // TODO: Add your control notification handler code here
 2 bool bRes = m_dbConn.Connect("数据库ip地址", 3306 , "用户名", "密码", "数据库名");
 3     if(!bRes)
 4 {
 5   AfxMessageBox("connect fail");
 6   return;
 7 }
 8 
 9 string strSql = "select * from city limit 1";//所有显示或取值类的都用这段。中间的sql语句可以自己构造。
10 ResultSet* rs = m_dbConn.ExecuteQuery(strSql);
11 while(rs->Next())
12 {
13   string str = rs->GetString("username");
14   AfxMessageBox(str.c_str());
15 }
16 /*
17 strSql = "update city set money=money +100 where City_ID='xxx'";//所有的增加、删除、更新都用这段，中间的sql语句可以自己构造。
18 
19 bRes = m_dbConn.ExecuteUpdate(strSql);
20     if(!bRes)
21 {
22   AfxMessageBox("ExecuteUpdate fail");
23 }
24 */
25 m_dbConn.Close();
26 
27 定时器的主函数。
28 void CBeiLiDlg::Go()
29 {
30 while(true)
31 {
32 // AfxMessageBox("go");
33   
34   Sleep(5*1000);//毫秒。定时器刷新时间。
35 }
36 }
当然。这里的C的代码不能直接用。只是一部分。
新的方法是，通过php定时器类负责前台、时间到后，调用ajax执行完成。后台通过定时执行php定时器类的专用处理函数，处理前台掉线，前台未正常执行等情况。
如果我们的新游戏今年年底能正常上线的话。我可以公开这个类，没技术含量，但是很巧妙。
地图、城市、基本上算是有了。
接下来是城市里的建筑。
上面讲的资源增加，其实定位在建筑上更准确。不过建筑的分类和数值会复杂很多。那是策划考虑的问题。
建筑上，只讲一个前台的修建效果。
当然，这个效果是可有可无。你可以直接给个类似新闻列表的显示，再加个倒计时就行。
显示的效果就是，点修建后。不刷新页面，调入一张动画图片。并在时间到后自动转换为其他图片。

1 <script language='javascript'>
 2       function xiujian()
 3       {
 4       top.abc.document.getElementById('前台建筑位置所在图片的id').src='修建后建筑的图片地址';
 5 //显示修建后的建筑图片。可以加上后台时间判断。其中abc，是建筑所在层的id，
 6       }
 7       function xiujian1()
 8       {
 9       setTimeout('xiujian()',5000);//动画时间5秒。这里也可以加入时间判断。当时间不到的完成的时候，继续调用动画。
10       }
11       function donghua()
12       {
13       top.abc.document.getElementById('前台建筑位置所在图片的id').src='建筑动画所在的地址';//显示修建动画。
14       }
15       donghua();
16       xiujian1();
17       </script>
18 
附带讲一下。如果要考虑多浏览器兼容，那么用prototype.js。如果只需要ff和ie。那么用而jqury.js
或尽量自己写。因为120k的prototype.js不算小。
后台部分，把时间到，增加资源的代码，改为时间到，增加或更新建筑就行了。又是增加N个表。。
新的方法是，增加事件子类。
建筑基础表：产出，类型，图片等等。。
建筑详细表：属于哪个城市，可以在城市表里关联。关联的方式不同会对程序有很大的影响。各种关联方式都行，但是一旦关联方式确定后，最好别改动。
现在建筑也有了。用类似的定时方式，打工，征兵等等都可以实现。
战斗，
兵的参数：兵种，数量，攻击，防御等等。
战斗的临时表：谁的兵，打谁，出发时间，战斗时间，战斗结果。
这里的几个字到是简单。实际的表会复杂一些。
webgame中，战斗的过程分两种，一种是给出双方参数，时间到，就根据公式计算结果。一种是半即时或者即时的战斗，可以边打边喝药边用技能的那种。

第一种流程。
点出兵。这时候，兵的参数，出发时间，到达时间，都记录进战斗临时表。
定时器中，处理战斗的部分，判断时间是否到开打的时候。到开打的时间了，则取得被攻击方的兵的参数。然后通过几个公式计算结果。处理结果，比如谁的兵挂了多少，战场掉落了多少钱，城市被谁抢到了。一大堆判断以及updata。（这里的定时器处理和获得资源的定时器处理是很类似的。）
最后把结果分别发给双方。（又涉及到一个短信息系统。）

第二种流程。
点攻击。马上就处理数据。打打npc好做。玩家之间对战，也可以把被攻击的玩家当成npc来处理。
两个人或两人以上即时战斗。需要用到ajax了。目前在技术上和理论上是没问题的，还没实际写代码，所以不好讲。
现在，技术上已经确定可以很好的实现了。
很简单的公式，两种战斗都可以用到：
intval(sqrt($User_B_AP)-sqrt($User_A_DP));
根号下攻击-根号下防御=伤害。
具体写的时候，公式肯定会复杂不少，不过这头痛的事，还是交给策划去做吧。
战斗的具体参数，其实已经不是程序考虑的了。
程序只需要考虑从数据表A取得数据，存入临时表B。然后当时间到了后（通过定时器实现），再从数据表C取得数据，通过公式计算，最后删除临时表B或者把临时表B存到另外一个地方备份。
这里的思路其实就是定时器类。
数据是哪些？找策划要。有几个表？找策划要。战斗公式？找策划要。
有地图、城市、建筑、士兵、战斗后，道具的出现就有必要了。
为什么呢？
有了城市能做什么？产生资源，产生钱，产生兵。
有了士兵做什么？可以抢资源，抢钱。
资源和钱做什么？买道具。
买道具做什么？更好的抢资源和抢钱。
（同时，抢资源，抢钱的时候，资源会被消耗）
这是一个很简单的循环。就是绕成了一个圈，虽然这个圈很小。有部分策划想得非常好，就是绕不成圈，那样没任何意义。

首先，需要一个道具的基础表。自动ID，道具类型，道具属性，说明。在道具的处理上，可以在玩家表里增加更多字段，道具跟随玩家。也可以单独建一个道具的详细表。用类似背包的方式实现。
背包的方式有两种，一是用数组存储，二是用横向表存储。都挺麻烦的。不过从道具流通和买卖上考虑。用背包的方式是值得的。接下来的功能。
商店。拍卖行。基本上跟一般的网站应用很类似。只不过产品变为了游戏里的道具。货币是游戏币。

三、总结
上面的小例子，思路上是基本完善，没问题的。程序代码上只给了一小部分，能真正理解这一小部分。其他部分的程序应该不是问题。
webgame重要的还是数据流的绕成圈，以及可玩性。
现在讲为：程序的健壮和数据流的清晰。
上面的功能，真的做出来，是不够玩的。就是没什么可玩性，做出来都没意义。
但是，仅仅是做出来，仍然是一件困难的事情。
游戏里涉及的东西太多。即使是很简单的游戏，即使webgame看上去很简单，甚至实际也很简单；做出来，非常困难。
没有过开发webgame经验的人，来策划webgame或者说开发webgame。会觉得很简单。大功能其实就那么几个。思路上也容易绕成圈。
实际情况是，一个非常简单的功能，当它需要绕圈的时候；当它需要交互的时候。这个功能就不再简单，而是复杂，相当的复杂。
这是当你不太明白设计模式的时候，如果你精通设计模式，那么功能就会简单起来。

特别是你想制作一款有足够的可玩性，能面向市场的产品，即使是初期思路非常简单，功能也很单纯。但你实际策划的时候，实际编程的时候。大量的数据、数值需要你去处理，大量的交互需要你去处理。这时候，开始的简单，已经变得复杂了。虽然从程序的角度讲，技术含量不高。
更准确的讲，是繁琐，非常繁琐。

优秀的策划是可以把数据表列出来，把数据走向清晰的列出来，放在你面前。这样的策划不多的。
当然，他不一定列得很准确，但是程序员能比较准确的理解他的意思。

网页游戏开发入门教程二（游戏模式+系统）
 一、游戏模式
目前webgame游戏模式大体上可以分为以下四类：
1、玩家拥有一个城市，不断的升级城市内建筑，建筑可以自动获得物资，可以生产军队，军队之间进行对比数值的战斗。这里我简单的称为Ogame模式。
比较优秀的代表：战神世界II，Travian，Ogame，武林三国，纵横天下，领主online，乱舞春秋，热血三国，方便面三国等等。
这是一个比较成熟的模式， 但正因为成熟。因此，玩家接触到这类游戏比较的多，除非你能超过这些优秀的代表，否则就只是简单的重复开发。
对玩家来说：
优点：Ogame模式模拟一个君主，发动一系列战争。满足君主的成就感。
缺点：玩Ogame模式的游戏需要足够的耐心。当然有钱也行。
对开发者来说：
优点：有相当多的地方可以参考。甚至有源代码参考。(Ogame的源代码)
缺点：不管名字怎么改，策划怎么策划。本质没有变化。换汤不换药，玩家不是傻子。
Ogame模式所获得的成功，就像传奇刚出来的时候。不是因为这个模式非常好，而是因为暂时还没有更强的模式超过他。所以，如果你想做网页游戏赚钱，而不是好玩，或者仅仅为了架设一个自己的服务器。那么请从新开发一种新模式。
2、游戏的核心就是战斗，不断的战斗，不断的完成任务。这里我简单的称为Ebs模式。
比较优秀的代表：EBSII，web幻想（wog），无心宠物（论坛插件）。
Ebs模式也是成熟的模式。
对玩家来说：
优点：只管不断的战斗，完成任务，PK。
缺点：只能不断的战斗，完成任务，PK。
对开发者来说：
优点：有相当多的地方可以参考。甚至有源代码参考。
(wog（ web幻想）的源代码，无心宠物的源代码)
缺点：收益到底如何呢？
3、mmRPG模式游戏。
猫游记、英雄之门、昆仑（昆仑不应该算网页游戏了）。
模拟具有客户端的网络游戏。本身这个想法非常好，但是，谁来玩是一个问题。
对玩家来说：
优点：类似有客户端的网络游戏。
缺点：画面、游戏性等等都比不过客户端网络游戏，要玩mmrpg，有必要玩网页游戏吗？对开发者来说：
优点：模式清晰，参考众多。（大部分网络游戏都可以作为参考）
缺点：策划难度高，技术难度高。
4、经营模式游戏。
武林足球经理、XBA篮球经理。
经营类游戏在游戏消耗上，和成就感上比较难处理。毕竟不是单机的经营游戏。
如果策划够强，经营类游戏是很好的选择。
那么，作为开发者来说，选择哪一类入手呢？
从程序的角度上来说，不管哪一类，都需要六个系统。

二、网页游戏六大系统
1、经济系统。
经济系统包括：商店、拍卖行、生产或打工场所、道具和资源。
生产或打工场所通过 玩家 消耗时间 产生道具和资源。
商店 让玩家和系统进行道具和资源的交互。
拍卖行 让玩家和玩家之间进行道具和资源的交互。
2、消耗系统。(战斗、战争、比赛系统。)
不论是哪一类网页游戏。都是以下12个模式中选择某几个组合。
1玩家vs 1 NPC
N 玩家 vs 1 NPC
N 玩家 vs N NPC
1玩家vs 1玩家
N 玩家 vs 1 玩家
N 玩家 vs N 玩家
1团队 vs 1 NPC
N团队 vs 1 NPC
N团队 vs N NPC
1团队 vs 1团队
N团队 vs 1团队
N团队 vs N团队
比如，无心宠物，就包括了
1玩家vs 1 NPC
1玩家vs 1玩家
比如，战神世界，就包括了
1玩家vs 1 NPC
1玩家vs 1玩家
1团队 vs 1团队
N团队 vs 1团队
3、消息系统。
短信息，系统通知，游戏内邮件等等。
4、任务系统。
任务系统是对以上系统功能的集合。有了功能，自然就有了任务发挥的空间。
5、公会系统。
游戏始终是人跟人玩。所以公会系统是重中之重。
6、地图系统。
虚拟的世界环境。可以是复杂的图片地图，也可以只是几个数字。
分析6类系统到底是做什么
1、经济系统。
相信大多数开发者都做过电子商务类型的网站吧，要不商店类型的网站做过吧。
再不然，一个产品列表总做过吧。
ok,网页游戏中的商店跟一般的网站商店非常类似，而且可能更简单，因为你不需要购物车。
拍卖行，如果你用过淘宝、易趣的拍卖功能，你就知道是怎么回事了。
经济系统的难点是：
生产或打工场所、道具和资源。
生产或打工场所：
你至少需要完成一个计时器，一个生产类，一个打工类。
生产类和打工类都只需要有：
开始() 过程() 结束()
开始():数据初始化。如判断体力是否够啊。材料是否够啊之类的。
过程():可以什么都不做。
结束():产生了什么产品。
计时器用来配合处理什么时候执行开始()，什么时候执行结束()。
道具和资源：
道具最好整合到一个表里。加上如itemtype（道具类型），itemaddtype（道具增加属性类型），itemaddpoint（道具增加点数）之类的字段。
你可以很好的处理装备、药品等等。
2、消耗系统。
消耗系统比经济系统复杂。因为它涉及到一个个具体的功能模型。
比如1玩家vs 1 NPC的模型。
你可以通过纯js处理，也可以通过ajax配合后台编程语言处理。
比如一个完整的过程：
1、获得初始数据。开始计时。
2、模型过程。比如攻击一次，攻击XX个回合。
   判断，循环模型过程，或模型结束。
3、模型结束。返回数据。
难点在模型过程。当然，你可以简单的，提交模型数据后，等待多少分钟，返回另一堆数据。目前很多网页游戏就是这样处理的。
你也可以做得很复杂。比如做成即时的回合模型。(例如无心宠物的商业版玩家战斗模型)
甚至你够牛叉的话，你做成战棋类模型。当然，这个对策划，对程序都是严峻的考验。
最大的问题是：一个模型往往不够，可能需要多个模型。
获取数据、返回数据都是比较简单的。模型功能本身，比较复杂和繁琐。
因此，我强烈建议，模型最好做得具有开放性以及方便扩展。多写几个虚类，多写几个接口，可能会很有好处。
我也参考了一些网页游戏的代码。但是，纯函数的写法，纯过程的写法，写出的模型。。真的好难用。没办法直接用。数据和模型交杂在了一起。Ogame是这样，无心宠物是这样，wog也是这样。
没有足够扩展性的模型，还不如自己写。修改花的时间更多，而且非常不好用。
3、消息系统。
参考一般论坛的短消息功能。很简单。
游戏内邮件，如果可以邮寄物品，那么会困难一些。但是只要前面的道具类完成好了。增加一两个字段不是大问题。
4、任务系统。
整合前面的功能。形成任务链。
大概需要几个表：
1）任务基础表
id
位置id
任务类型一（打怪/寻宝/等等）
任务类型二（单一任务/连续任务开始/连续任务过程/连续任务结束）
任务进行状态（开始/中断/取消/未接/完成）默认：未接
任务开关文字（连接文字或图片，点击触发）
任务开关图片。
任务文字描述。（说明任务的具体内容）
是否一次性任务。
是否有前置任务。
前置任务id
是否有后置任务。
后置任务id
任务开始NPC
任务结束NPC
2）任务完成条件
id
任务id
任务完成类型 （无条件/需要物品/需要属性/都需要/等）
物品id
物品数量
玩家属性
玩家属性达到值
3）任务完成奖励
id
任务id
物品id
物品数量
玩家属性
玩家属性增加值
任务完成开关文字
任务完成开关图片
4）任务记录表 （记录只能执行一次的任务）
id
角色
任务id
任务进行状态（开始/中断/取消/未接/完成）默认：开始
5）任务临时表
（记录可以多次执行的任务,开始即写入，完成即删除或备份。）
（连续任务，当全部完成时再删除或备份。）
id
角色
任务id
任务进行状态（开始/中断/取消/未接/完成）默认：开始
6）NPC表
id
NPC名字
NPC图片
NPC对话
任务系统是对前3个系统功能的总结和升华。对游戏性和易玩性相当重要。
5、公会系统。
公会是一个类似虚函数的东西。
公会说，进攻某个地方。
这时候，如果有多个公会玩家去进攻某个地方。从1v1,形成了貌似Nv1。
公会本身，不用管玩家到底如何进攻法。
公会系统和任务系统结合。能够产生很强大的游戏成就感。
6、地图系统。
网页游戏的地图系统，其实跟网站导航很类似。
不同的是，网站导航可能只需要几个连接就行了。
地图系统会复杂一些。可能有图片，连接更多，有的还需要自动生成。
有的是XXX*XXX个点（图片或连接）组成。
个人觉得看成是模板就行了。最简单的就是地图系统（不同于网络游戏，还需要检测碰撞、寻路，一大堆算法）。当然，你要做成跟网络游戏很类似的地图，那也没办法。找本游戏开发的书看，都有讲。
总结：
经济系统、消耗系统、消息系统是基础。
任务系统、公会系统是升华。
地图系统是容器。
三、如何分析网页游戏的优缺点
站在开发者的角度：
分析网页游戏，就是分析它的六大系统如何。分析网页游戏的核心，就是分析它的消耗模式。
Ogame模式的游戏：
经济系统：中级，生产场所自动生成。没有单人打工。有商店，拍卖行不健全。道具不丰富。
消耗系统：出兵战斗，等待时间，返回战斗结果。
          发现敌人有进攻，转移资源。
附加型的英雄模式，对出兵战斗有一定影响。
消息系统：初级，站内短信息。有的加个简单聊天室，大部分是通过论坛。
任务系统：中级，修建任务，获得道具任务，战斗掠夺任务（实质还是获得道具）。
公会系统：中级，集合多人兵力的兵营。没有公会任务。公会内简单的消息发布。
地图系统：中级，有的有图片，有的是数字和列表。表现了一定的距离关系。
Ebs模式的游戏：
经济系统：初级，通过战斗获得道具和资源。没有打工，没有生产。有商店，拍卖行不健全。道具不丰富。
消耗系统：战斗。继续战斗。
消息系统：初级，站内短信息。
任务系统：初级，不断的战斗。
公会系统：初级，简单的玩家集合。没有公会任务。公会内简单的消息发布。
地图系统：初级，没有地图。或者地图就是几个连接。没有距离关系。
mmRPG模式的游戏：
经济系统：初级，通过战斗获得道具和资源。没有打工，没有生产。有商店，拍卖行不健全。
消耗系统：战斗、合成。
          附加型的人物养成。
消息系统：中级，站内短信息，局部聊天室，全局聊天室。
任务系统：中级，战斗任务，传递任务，合成任务，升级任务（其实也是战斗任务）。
公会系统：初级，简单的玩家集合。没有公会任务。公会内简单的消息发布。
地图系统：中级，有地图。有距离关系。地图关系比较复杂。
经营类模式的游戏：
经济系统：中级，有生产场所自动产生资源。有打工，有生产。有商店，拍卖行。
消耗系统：比赛任务、生产场所获得更好效率。
              附加型的人物养成模式。
消息系统：初级，站内短信息。
任务系统：中级，比赛任务，传递任务。
公会系统：初级，简单的玩家集合。没有公会任务。公会内简单的消息发布。
地图系统：初级，简单地图。有的有距离关系，有的是简单的图片连接。
上面写的等级，只是一个大概的概念，仅作参考。
个人观点是，初级的系统有可能在投入较少的情况下，获得质的提升。
中级的系统，很难获得更高的提升。当然，牛叉的人例外。
四、完善旧有模式，开发新的模式
Ogame模式的游戏，从系统的角度看，能获得提升的地方不多了。因此都是在比美术，比运营。
还没听说哪个小公司，因为运营ogame模式的游戏盈利颇多的。盈利的都是大公司，一年几百万，上千万的都有。
Ebs模式的游戏，能获得提升的地方满多的。但是都不是核心的消耗系统的提升。而是其他系统的提升。
消耗模式不断的打怪。本身有一定的硬伤。游戏的平衡很难保证和保持。但如果小公司运营，还是有可能盈利的。包括无心宠物，EBSII，做好了。只是广告收入都很可观的。运作得好，一年10万20万，问题不大。但是不能跟大公司运营的Ogame模式游戏比。
mmRPG模式，提升空间很大，投入很大。竞争对手很强大。竞争对手，就是有客户端的网络游戏。这也是mmRPG模式网页游戏的硬伤。
收益上，看平台本身够不够大，够大的话，能维持。平台小了。等着倒闭。不推荐个人或小公司介入。不过还是那句话，牛叉的人除外。
经营类模式，有一定提升空间。(其他不太清楚也不太懂)
再回头看看六大系统。
经济系统 消耗系统 消息系统 任务系统 公会系统 地图系统
其中，区别最大的是消耗系统。其他5个系统都有一定程度上的雷同。
因此，个人开发者，以及小开发团队或小公司。
五、要想在竞争中脱颖而出，可以向着四个方向发展。
一、通过策划，让原有的系统的模式产生新的游戏感受。
如： web航海类游戏。基本上都是对Ogame模式的修改值得借鉴。虽然是航海游戏，但核心模式没变。比较巧妙的把Ogame模式转化为了探险类的游戏。
这类修改，将6个系统重新进行了一定的包装。对新玩家有较强的吸引力。但对老玩家，效果不一定好。因为模式并没有改变。
这个方向，需要策划相当的强悍和敏锐。
二、开发新颖的消耗系统。或者说游戏性较高的小互动游戏。
比如：七日工作室开发的病毒游戏。(该连接有一定时效性，最新连接在 上。七日工作室群：70996701)
因为一个扩展性良好的消耗系统，可以很方便的放入到已有的游戏中。并且其自身也可以演化出很多新的消耗系统。
比如病毒游戏，通过它的模式，可能演化为，房地产抢土地的游戏；