AIK网页游戏 设计【策划精品】

webgame的设计思路（一）--服务器数量预估 2

webgame的设计思路（二）--数据库表结构划分 3

webgame的设计思路（三）--地图模块设计思路 4

webgame的设计思路（四）--玩家数据的数据库设计 7

webgame的设计思路（五）--整体架构和总结 8

web策略类游戏开发(六)缓存概述 9

Onceuponatime(一个web游戏的实现方法+源代码) 11

1体系结构 14

2．开发思路 15

(四)一个可以承载万人在线的架构 18

(二)WebGame事件 19

(三)多线程下数据库并发更新的处理 22

(五)数据库表设计 26

webgame的设计思路（一）--服务器数量预估

服务器数量预估

在线人数预估：

在项目设计之前，需要先对运营后的服务器人数做一下预估，预计激活人数300w，活跃人数40w，同时在线10w。而服务器的设计极限则在激活人数500w，活跃人数60w，最高同时在线15w。

数据参考：

这里之所以预计这么低的激活人数，是从整个服务器考虑的。《热血三国》是将不同的用户放在不同的服务器里，所以单一服务器的激活人数不会对服务器压力产生太大影响。而如果将所有玩家统一到一组服务器里，则会导致用户表访问压力过大。偏低的激活人数靠定期清理不活跃账户来实现。

数据库服务器数量估计：

服务器在搭配上，一般分为db服务器和web服务器。在这之前的运营中，通常按照1:1的方式来配置数据库和web服务器，而实际情况可以使1:2的配置比例。不过在单一世界的设计里，单台db服务器肯定无法满足需求。之前设计过一款策略类webgame，在运营时，每秒sql数为在线人数的1~1.5倍。不过这个测试数据，是在没有钱全面应用缓存的情况的数据，在新系统里，如果全面应用缓存，并采用类似于Memcache的软件提供数据缓存，这样数据库的访问压力将可以得到极大的缓解，因此我们暂定吧每秒sql数暂定为在线人数的1倍。正常情况下数据库的访问压力应该为10wsql/秒极限数据应该为15wsql/秒。

数据库使用mssqlserver2008，在这之前的一个策略类webgame项目，对一台CPU为E5520核的服务器上做压力测试，得到的数据如下：

Sql数

5k

CPU

50%

硬盘IO

0.5M(突发3M）

网卡流量

30Mbit/s(100M网卡）

按照上面的分析，在正常情况下，我们需要为整个系统提供20台db。Web服务端按照1:1和db做搭配，也将安排20台，预计3个机柜的服务器。

webgame的设计思路（二）--数据库表结构划分

数据库表设计：

因为要把这么多访问量分担到不同的服务器里，原先的数据库表设计肯定不会合适。初步的想法是根据游戏的逻辑模块，将不同模块的数据库表拆分到各个服务器里，如果按照上面的服务器预估得到的结论是4~6组服务器，实际上这个方案还是可行的。但如果是20组服务器的话，除非是一台服务器一张数据库表，但这的设计会造成数据表太分散，在处理事务的时候，会跨多个数据库

策略类webgame一般的主要模块为：建筑物和资源、军事、英雄、物品、帮会、交易、地图。根据这些模块的应用场景，可以将数据库表分为2种类型，一种是属于玩家的数据，另外一种是公共数据。

1.属于玩家的数据是指玩家个人说拥有的基地、资源、军事单位、物品等数据，它们都是围绕着玩家而产生的。

2．公共数据则是指由多位玩家共同组合而产生的数据，例如：账户信息、帮会、地图等。

这里划分两种数据的目的是在于他们的数据库表的划分。对于公共数据，则采用单一服务器，单一数据库表处理的方式来处理。例如帮会模块和地图模块就准备分别用3台服务器来存储各自对应的数据库表。而对于玩家的数据，则根据用户ID采用一定的划分方式，将玩家数据打散到各个服务器里（http://blog.zhaojie.me/2010/03/sharding-by-id-characteristic.html）。

（数据表的结构划分）

用户表和其单表的设计思路：

这里所说的单表是指在逻辑上部队数据库表做拆分，程序在访问时只访问一个数据库。当然这只是逻辑上的单一，根据实际上的访问压力，可以将数据库文件作水平切割分布在不同的文件分区和服务器里。这部分的数据库表设计继续沿用之前的设计方案就可以了。

对于用户信息，帮会信息等数据，实际上插入和更新的频率不会太高，更多的是在查询上，因此这部分的设计重点应该是在缓存上。从以前的资料里得知Memcache服务器每秒可以响应4w次的读请求，用一台Memcache就能处理好用户和帮会信息的缓存处理。

webgame的设计思路（三）--地图模块设计思路

地图模块：

地图在传统策略类webgame里都是以平面的方式展示和存储的。地图的移动都是在这个平面上实现。但一般来说，平面地图的设计容量都会有一个上限，一般来地图多为400*400，他的人数上限就是16w，实际上服务器容纳3~5w人后，整张地图就会显得很拥挤了。如果要想容纳几百万人在线，平面地图的尺寸就需要扩容得相当大了，这样玩家从地图中间移动到边缘的时间会相当恐怖，因此平面地图在这里不是很合适。因此，地图不能用平面来构造，必须是立体的方法构造。在这里我设计了两组方案：

立体平面空间：

如上图所描述的，立体平面空间，就是把多块地图一层层叠加在一起，形成一个立体的空间。这样如果用户不够，再增加一个新的平面就行。游戏的背景可以根据需要做调整（例如整个世界是被大海隔开的5片大陆组成，在这5片大陆之外，还有其它的超位面空间，这些空间自身是互不相连的，但是可以通过传送阵进行位面传送）。这样做的好处是，用户容易理解，以往用户的操作习惯不用改变，毕竟都是在平面地图上战斗。只不过要做跨位面的战斗的移动计算上会存在问题（逻辑上的问题：是否允许跨大陆的远征军）

用户坐标的表示方法：地图层次、x坐标、y坐标

数据库设计方案：

采用了层次结构，只需要增加一个地图层次的字段，这个地图表就能沿用。（参考字段：ID、地图层次、X坐标、y坐标、地图类型、玩家ID、城池ID）

虽然说，加入了一个地图层次的字段能解决地图的表示问题，不过，因为整个游戏世界是单一世界的服务器，当所用地图信息存储到一张表的时候，这数据量就不容小视。在这之前做webgame项目的时候，整张地图是预先生成好数据库记录的，当有玩家加入游戏的时候，就去修改表里的玩家ID和城池ID。同时因为地图大小只有400*400，整张表也就16w条记录。但如果是要做一个承载500w人的服务器，那地图的尺寸最好是要800*800，并且地图的层次为15~20层，就算最小的15层，按照原先的设计思路，至少需要预先插入960w条记录。

数据量看上去比较夸张，不过对于SqlServer来说也不是处理不了，并且我们还将计划把地图表单独用一台服务器来处理，其压力远小很多。不过也不能不考虑当发生性能瓶颈时的优化处理。优化的方法有两个：

1． 拆分：按照地图层次，把这张表拆分成15~20张表，或者拆分到15~20个数据库里

2． 用疏矩阵存储：地图不预先生成用户的地图信息，而是有玩家加入时才插入数据。这个方案在服务器早期人数比较少时会得到良好的性能效果，但当用户人数达到一定量时，还是避免不了因为记录函数过多而导致而外的开销。

全立体空间：

全立体空间就是取消了平面的坐标显示，用户都是在一个三维的立体地图里战斗。好处是地图不用那么分散，在移动计算让很好处理，存在的问题就是游戏在显示的时候，如何表现地图的三维效果会比较困难。

用户坐标的表示方式：x坐标 y坐标 z坐标

数据库存储方案：

三维空间的数据库表设计结构可以和上面的表一样，而且也只能采用疏矩阵的方式存储，因为做成三维空间后，可表示的位置的记录数更多了。

可移动基地在全立体空间的设想：

早在两年前，看过《超时空要塞F》的时候，就产生了一个想法http://blogs/yahle/archive/2008/05/27/1208355.html，就是玩家的基地是可以移动的。玩家的母舰在游戏的过程中，已一定的速度在整个世界里移动。

可以移动体系的设计要点：

1. 用户的基地可移动

2. 用户基地只能拥有一个（武林三国、travian都能建立多个）

3. 空间坐标由x坐标 y坐标 z坐标 组成，并且坐标的值应为小数

4. 同一个坐标里运行多个玩家存在，玩家的航线交叉并不会造成影响（只是为了方便计算减少判断过程）

5. 移动的数据通过后台定时刷新

a) 每个短周期(1~60s)在内存里更新坐标

b) 每个长周期（10~100个短周期时间）将坐标的数据更新的数据库

6. 攻击舰队移动的时间是按照2个阶段来进行的

a) 第一个阶段是从母舰移动到目标坐标的时间

b) 第二个阶段，在快到达时（前60分钟），做一个判断，判断攻击舰队的雷达能否搜索到目标的母舰坐标，能则做攻击坐标的新修正，如果不能则继续按照原先的坐标点移动。以上判断将每隔1分钟做一次，直到到达目标坐标点。如果到达目标坐标点仍然无法视为攻击失败，舰队返回

7. 舰队的移动距离和舰队所携带的能量有关，超过移动范围的坐标，舰队是无法出发的。

8. 部队和母舰应该是可以进行空间跳跃实现长距离的移动，不过空间跳跃需要在制定地点消耗大量的能量才能实现。

9. 默认情况下，母舰移动速度为1格（x、y、z坐标）/天。

10. 默认舰队的雷达查询范围为1格

11. 默认母舰的雷达查询范围为3格

webgame的设计思路（四）-- 玩家数据的数据库设计

数据库的划分

在游戏里数据交互最频繁的还是玩家的数据，他的访问量是一台服务器所不能解决的，因此我们考虑将这部分数据分担到多台服务器里。分担的方法还是做水平切割，但这次不使用数据库自身的切割功能，而是在应用逻辑层上对数据库进行切割。根据用户的ID取模后写入对应的服务器里。

服务器1

用户ID % 服务器数量 = 0

服务器2

用户ID % 服务器数量 = 1

……

预计每台服务器能提供6k~8k的在线用户访问，预计一共需要16台服务器。考虑到服务器的进一步扩容问题，在初期规划时，建议规划为32个数据库，每台服务器可以先放3~5个数据库，等服务器用户人数上来后，再将数据库拆分到不同的服务器里。

用户数据库各个模块的设计

玩家基地里的建筑物，资源，物品，英雄等相关表，基本上都是玩家独立拥有的，不存在和其他玩家交互的情况，因此这些表的设计继续沿用之前的设计就可以了。

军事模块

军事模块分为部队表，部队创建事件表和战斗事件表。部队表和部队创建事件都是玩家自己内部的事情，把相关的数据和玩家其他数据放在一个数据库里就行了，但是战斗事件表则会设计到两位或者多为玩家则会比较复杂一些。

战斗事件表通常记录的是A玩家（城池）对B玩家（城池）的攻击，里面有攻击部队，到达时间等信息。这个条记录和A放在一起，那么B在查询自己被攻击的记录时，就需要访问32个数据库，反之，和B放在一起，这A查询自己部队的攻击情况时，就需要遍历32个数据库。如果和用户表一样单独把这张表拿出来，用单独的一个服务器来处理，则会导致表过大，查询会变慢以及战斗服务器的压力过大。

在之前的项目，战斗服务器处理每场战斗大约是100ms，也就是每秒能处理10场战斗。当然你也许说可以用多线程来进行，但是使用多线程后，战斗事件的顺序可能会点到，影响用户的战术安排。

在这里，我设想，将一个表设计改为2个表：攻击事件表和被攻击事件表。这两个表的结构一样。加入A玩家发起对B玩家的攻击，那么将攻击事件加入A玩家所在服务器里的攻击事件表，在B玩家服务器里，将数据插入被攻击事件表。然后每个数据库对应一个战斗服务器程序，这个程序在已被攻击事件表为依据，进行攻击计算。在计算完成后，在同时删除2个表里的数据。

好友模块

好友表本身就可以分为2个表，已某位玩家ID为主键和对应玩家放在同一个数据库里。但是好友申请则需要另外考虑了。如果申请的申请方不可见自己发出的申请，则只需把申请记录和被申请玩家放在一个数据里。但如果需要可见，则会麻烦一些，一种方法是参考战斗表的设计思路，分为申请表和被申请表。还有一种方法就是把申请表独立出来，所用用户的申请都放在这张表里。作为我个人，我倾向于后面的一种方法。

用户邮件表设计

用户邮件虽然是属于2位用户之间的交互数据，但从整个系统的角度上来说，用单一的一张表放在单独的服务器里会更简单一些。因为邮件表的内容基本为只读内容，只存在插入和读取功能，并且用户访问的频率不是很高，可以很方便的在逻辑层和web层作缓存。

webgame的设计思路（五）-- 整体架构和总结

总结：

虽然对于单一世界的webgame思考了很多，但到最后细化写成文字，也就只有这4篇短文。不是说不想深入细节去讨论，而是发现如果不做一些具体开发就没法深入写下去，因此本系列文章页就在这里点到即止，希望能给大家一些启发。

web策略类游戏开发(六)缓存概述

既然是概述，就没有太多详细的东西，本文主要针对asp.net开发环境。

webgame需要缓存的内容包括

1.游戏的配置信息

2.玩家的信息

对于游戏配置信息，通常是指游戏里一些固定不变的信息，例如建筑物每次升级时需要多少资源，需要多少时间等数据，这些数据当然可以写死在代码里，但通常这些数据应该放在代码外，要么是以文件形式存放（xml或者txt)，要么就是放在数据库里。这部分数据的缓存很好做，只需要在应用开始时，统一做一次加载就可以了。一般来说，做过1年开发的同学都知道这种数据应该用单例模式来加载和使用，这点对java同样适用。当然做成静态属性也是可以的，只要把握好加载的时机就可以了。这里还顺便说一下，如果游戏的配置信息存在交叉访问（索引），则要注意两者之间的加载顺序。或者对交叉访问的部分不做索引，每次都动态的访问（查询）。

对于玩家的信息，则有一些说头了。基本上，现在的.net项目都做成3成结构+ORM访问。缓存的对象应该是游戏的实体对象。同上实体对象和数据库表之间都是一一对应的，这点没什么好多说的。以玩家或者村庄对象为了，它们的索引通常是ID，只需要创建对应的Dictionary 字典对象用来存取数据就可以了。

Dictionary playerMap = new Dictionary();

public Player Getplayer(int ID)

Player ret;

if (playerMap.TryGetValue(ID, out ret))

return ret;

ret = 从数据库里获取玩家对象(ID);

playerMap.Add(ID, ret);

return ret;

上面是一个基本的用于从缓存里访问玩家对象的方法。这点对大家来说，都不算很难，有点经验的同学都能写得出来。

下一步如何更新这个缓存就是这个缓存系统才是webgame的麻烦地方。

我们缓存的对象和web应用的对象不一样，它存在着随时变化的可能，并且当他发生变化时，需要能及时反馈给用户。

web应用我们以blog为例，当某位用户添加了新文章到cnblogs的首页，可能不会立即被其他用户看到，因为cnblogs首页的缓存信息还没有被修改。通常根据需要这些缓存信息可能会是1分钟，也有可能是10分钟，只有当缓存过期了以后，系统才会生成新的首页内容。其目的是减少首页的数据库查询访问量。

webgame游戏则不太一样，我花资源升级，就希望在页面上能立即看到变化，因此，当我们完成某项业务逻辑操作后，需要人工的更新资源对象的缓存。

try

//  游戏逻辑处理

//  数据库数据提交

缓存更新();

catch (Exception ex)

//  日志处理

按照通常的做法，每次逻辑操作都包含在一个事务里面，如果逻辑操作失败时，则可以对事务做撤销处理，尽量避免数据异常。

当然，这个也不是绝对的，前两天在QQ上谈论到缓存更新的问题时，某位同学帖出了他的代码，代码里，缓存的更是是在数据库事务提交之前。如果提交发生失败，则整个游戏系统已缓存的数据为主。这个问题咋一看来，和我们的思路不一样，我们就认为这样做有问题，后来回家的路上仔细的想了想，其实这样做也不无道理，因为它是在数据库提交之前更新缓存，也就是说，如果发生错误，唯一可能错误的地方就是写数据库时写失败了。但如果整个游戏系统是以缓存数据为准，只要游戏逻辑在计算时没发生错误，将错误的数据写入缓存，那么就算当前的数据修改提交到数据库失败了，数据还有可能在下一次修改时，提交一份正确的数据到数据库。整个系统不会因为数据库瘫痪了而无法运行。这点感觉和网游的服务器设计思路近似，毕竟对于网游来说，不可能每次玩家的操作都将数据写回数据库，玩家的数据都以在服务器内存里的数据为准，以定时的方式将内存数据会写到数据库。

其实这两种设计思路的差别就在于，数据是以数据库为中心还是以内存数据为中心。对与web系统来说，自然是以数据库为中心。从网游的角度来说，自然以内存数据为中心。而webgame是这两大系统的结合，其数据访问思路自然综合了这两种观点，具体到某个游戏，则需要根据游戏的需要而加以取舍了。

除了以字典为主的缓存设计外，还有一个重要的缓存对象的设计需要说一下，那就是地图。目前常见的Webgame（Travian，武林三国）都是以一张400*400的世界地图为玩家的交战地图。通常是一次性全部加载到内存里。存放的格式，自然是以x,y轴坐标为依据的二维表里。虽然首次加载是数据会比较慢一些，内存占用的空间会多一些，但当玩家查看地图页时，你会发现页面生成的数据比从数据库里获取相应数据要快很多。再加上现在服务器内存动则4G，8G的。则几十兆的地图数据还是毛毛雨了。

Once upon a time(一个web游戏的实现方法+源代码)

Once upon a time

Once upon a time是前几天项目小组成员发过来，类似杀人游戏但比杀人游戏更好玩的多人游戏。这两天有空，用vs2005将游戏写成一个web游戏练练手，不过小组里相应平平，估计是在web上面玩的时候速度太慢（俺们的测试都在不停的催促“打字快点，打字快点”）。因此在网上玩了几次就搁浅了，准备周末到茶室大战几轮。现在在这里把游戏的实现过程以及源代码发布以下，有兴趣的网友可以找几个朋友周末聚聚玩玩这个游戏。

1．游戏的玩法：

游戏的名字叫做：Once upon a time,简称OUAT

OUAT首先需要的是至少一百张要素卡和五十张结局卡。要素卡上写的故事所必需或者不必需的一些要素：比如“国王”、“公主”、“魔法解除”、“意外的转折”等等。而结局卡上则写着各中各样的结局：比如“从此他们幸福地生活在一起”、“他回到了家里，和父母团聚”、“他们就一直那样跳舞，一直到现在都没结束”等等。

OUAT理论上需要2－无穷大的玩家数量，不过按照标准配置，是5名玩家。

1 首先所有玩家各自抽取一张结局卡和五张要素卡，抓在自己手里。

2 决定中断优先权顺位，通常是以讲叙者的右手边为最优先，然后逆时针排序。

3 上一轮的胜利者（如果是第一轮则通过骰子来决定）开始讲故事。

4 讲叙者需要以“很久很久以前”为第一句，任意发挥，讲一段故事。故事的长度不限，不过通常需要起码三段话。这段故事中，必须包含讲叙者手里一张牌上的要素。当讲完故事以后，讲叙者把用到的要素牌亮出来，放出牌堆，表明这张牌已经消耗掉了。

5 讲叙者讲完以后，其他玩家则观察自己手里的牌。如果讲叙者刚才的故事里出现了自己牌中的要素，那么就可以申请中断。然后所有中断者按照优先顺位依次亮牌。如果大家公认这张要素牌可以中断，那么讲叙者自己抓一张牌，中断者把中断用的要素牌丢入牌堆，继续（必须）接着讲叙者的故事讲；如果大家工人这张要素牌不能终端，那么中断者把这张牌丢入牌堆，另外抓两张牌；如果没有任何人表示中断或者中断全部失败，讲叙者可以继续讲故事。

6 每一段故事，只允许消耗一张要素牌。相应的，每一段故事，其他玩家也只有一次机会进行中断。

范例：

比如玩家A手里抓了“牧羊女”、“剑”、“受伤”、“失而复得”与“变形”

玩家B手里抓了“狼”、“谷仓”、“愤怒”、“朋友加入”和“死亡”。

A首先讲：“在很久很久以前，有一位【牧羊女】生活在一个幽静的小村庄，她很漂亮，大家都叫她弥塞娅。她的父母双亡，从小就是个孤儿，可是她一直很快乐地生活着，大家都喜欢她。”

然后A宣布这一段故事结束，并亮出自己的【牧羊女】牌，表明这张要素牌消耗掉了。

这时候，B宣布“中断”，然后亮出了【死亡】，宣称A的故事里出现了死亡的要素。

中断通过，因为A叙述里出现了“她父母双亡”。

A抓一张牌【决斗】，B则接着A的故事往下说（注：中断卡也被视做消耗掉了，不纳入故事情节）

B接着讲：她每天的工作就是放牧，可是，一直有一个困难困扰着她，因为森林里住着一只【狼】，经常潜入村子里来偷吃羊羔。

然后B宣布这一段故事结束，并亮出自己的【狼】，表明这张要素牌被消耗掉了。

A宣布中断，并亮出了【受伤】，并解释说狼偷吃羊，这应该有受伤的情况发生。

大部分玩家表示不同意，因为【受伤】并没有在B的故事里得到体现，有些牵强。于是驳回。A把【受伤】丢入牌堆，另外抓了两张。

（注：中断的合理性界定非常重要。一般来说，只能中断故事里明确提及到的要素，如未提及，即使可能有隐含的逻辑联系，也不能进行中断。比如A讲“他们结婚以后，六十年里他们一直幸福地生活在一起”B试图用【交配】来中断。尽管这六十年里他们可能H过，但是也可能没H过，A文没有提及，所以B驳回。而C用【夫妻】来断，【结婚】和【夫妻】有必然联系，因此中断成功）

7 当其中一位玩家把自己所有的要素卡都消耗光以后，就开始进入结局阶段。他必须承接先前的故事讲三段情节，每一段都停下来看别人是否要中断。如果这三段都无人中断，那么他亮出自己的结局卡，念出来作为结局。

（注：结局三段情节不需要出示卡片，但是讲叙者必须要把结局和前面的故事联系起来，构成一个完整的故事，符合逻辑。如果太过生硬，将会遭到全体玩家的反对，要罚两张卡）

8 游戏的目的就是尽快消耗掉自己的要素卡，尽量不被别人中断，首先讲完结局的人获得胜利。

以下是游戏中的经典事例：

A 这一次的故事，一开头就被转到了李世民和少林武僧，而大家手抓到的全是童话牌。轮到玩家甲讲，甲百般无奈，只好硬着头皮讲“李世民正打的兴起，却惊动了地下沉睡的上古巨人夸父，夸父一脚下去，把李世民踩成了肉酱。”然后亮出了自己的要素卡“巨人”。玩家乙随即宣布中断，并亮出了自己的要素卡【变形】。

“哪里有什么变形啊？”大家问。

“李世民变成了肉酱。”

“………………”于是全体通过。

B 这一次的故事讲到主角被巫师追杀，获得了一把神兵。玩家甲顺利地进入了结局阶段。他的第一段故事是：“主角不停地打不停地打不停地打，轰下了邪恶的巫师”。无人中断，狡猾的他一看这段话里的要素没人能中断，就采取邪恶的规避手段，故伎重演：“主角主角不停地打不停地打不停地打，轰下了其他所有邪恶的巫师”。这时候，玩家乙宣布中断。

所有的人都在猜想：“第一段和第二段的要素完全一样，什么卡能够中断第一却不能中断第二呢？”

这时候玩家乙从容亮出了自己的要素卡：【兄弟姐妹】

C 玩家丁抽到了一张【堂会】，这是我增补进去的。不幸的是，第一个讲故事的玩家选择了星战背景，于是在整个故事里，玩家丁就不停地在哀求别人。