修为普及贴：DB(数据库)读写速度是如何影响游戏设计的？

z11190

三千世界，有一界游戏界。

相传这一界一切凭实力说话。而划分实力的标准有四个档次：练气期新人，筑基期老手，结丹期高人，元婴期老怪。每一个档次对应不同的修为与境界。每个档次的提升都有不同的劫数。有人终其一生都不得提升。

于是江湖之中，有关可以提升修为的秘籍，提升境界心法，那是万金难求啊。当然如果可以拜元婴期老怪为师，那超凡脱俗也是指日可待。

只是萝卜就这么多，幸运儿当然就很少。那些吃上萝卜的大白兔，不见得比你聪明，真的；心智比现在的你强，那也是真的。不过后天的心智，我们可以追。追修为，追境界。

只不过境界这个东西，有点大音希声，大象无形。

玉柱老怪说：ZT2是：浪漫交友，激情PK。。  就这么描述，你说说你能看出些神马，能学到些神马？

追修为就相对容易了。今天的这门功法讲的是一个初级法术：数据库读写速度会影响游戏设计吗？
----------------------------------------------
答案：当然啦！！！！这种矛盾就好像你想10内秒拷贝完1T的AV，但你的硬盘只有弱爆的读写速度，你情何以堪？而且365天每时每刻你的硬盘都以最快的速度进行运算，你受得鸟吗？万一烧掉了，你的呕血收藏怎么办？用户怎么办？

假设一款已运营的游戏，目前面临数据库读写速度过高，需要再投入硬件（增加成本）的尴尬。作为设计者可以先从设计本身去观察这个问题。

第一步：找出频繁需要读写的数据。切记：超级频繁读写的数据一定是该数据变化时就保存进数据库的。比如经验!
但有些数据不需要有变化就立即保存进数据库。比如：装备的当前耐久度数值。【如果收费点不包括耐久度的话】

第二步：从频繁需要读写的数据里筛选哪些可以转变保存方式。由原来的“变化时保存”改变为“角色下线时保存”

再拿“耐久度”来说，如果你的游戏里，耐久度就是个鸡肋，而又恰巧不小心是“变化时保存”，那你可以想想：万一服务器宕机回档，玩家肯定在意级别掉了，物品不见了，可他们会有多在意这耐久度？如果后果可以承受，就改吧！

第三步：从频繁需要读写的数据里筛选出哪些数据其实可以被别的数据索引。

举个例子：如果每升一级是系统自动配点，那么角色的基础属性完全可以通过“等级属性模板表”索引出来，所以这类基础属性的数据是不需要进数据库的。

相对来说，第三部比较复杂。需要对底层深入了解，才能庖丁解牛。
--------------------------------------------------------------------

好啦，这个法术就讲到这里，相信诸位道友会在项目初期进行游戏逻辑设计的时候，迫不及待地释放这个法术给自己加BUFF。







[em20]

Miller

呃。。我是这么理解的。。貌似和你的方向是反的。首先最理想的情况下，例如无突发状况且存取速度无限，所有数据肯定都是要存的，都在玩家下线的时候存。
于是第一个问题，一定有遇到突发事件的可能，例如服务器宕机。这是就要求所有数据都即时存储。
于是第二个问题，数据吞吐量一定有瓶颈，例如硬盘读写速度，DB检索速度等。这就要求有选择的数据即时存取。

所以你考虑问题第一顺位一定是将你所有功能按照宕机了数据没了可以接受的程度排序，最不可接受的，享受第一待遇高频率存，最无关紧要的，选择不存。中间可以划分若干个档次，按照资源总量（DB的能力）去考虑哪些要存哪些不存。

土匪猫

楼主说的是数据库数据存储管理机制。

这个貌似是主程序，服务器程序，制作人需要关心的事情。

因为存储策略的不合理，导致以下几个后果：
1.服务器异常当机导致的用户关键性数据丢失。
2.存储策略不合理，带来数据服务器的压力过大。
3.存储策略不合理，带来内存，系统硬件资源压力过大。

对于一般的小策划来说，这个知道了也就是知道了。木有神马用处的。
一般能搞起来的公司，服务器程序，主程序，制作人都会有这个概念。
木有这个概念的，基本木有侥幸搞成的可能性。

你发到策划论坛，有神马用意？

mosuo

我靠，楼主好不容易弄个有技术含量的帖子，看完喷了。

现在做三层结构的很少了吧。

一般会分四层，可视层-逻辑层-持久层-数据层。其实大多数是4层半。

楼主看看MVC模式和OOP思想，还有数据持久层的东西。立即保存进数据库，好像普遍很少这么做了吧。

hymjpg

SS的加速卡模式值得同学们去复习～