游戏中的商城和抽奖系统设计 ...

1 / 4游戏中的商城和抽奖系统设计GameRes 发布，转载请注明出处和作者作者：猴与花果山 http://bbs.gameres.com/home.php?mod=space&uid=7393 最近两天的设计遇到了一些商城和抽奖相关系统的设计，之前执着于游戏乐趣的设计却一直冷淡了这两块系统，事实上真的动起手来却发现有时候在这两块的系 统设计和制作中，存在很多混乱的东西——太多需要整理成机制的东西一直没有去思考，以至于需求堆多了之后写死的垃圾代码和数据表的列数都在骤增。于是总结 了一些关于这两个系统的设计和思考，随笔记下。商城系统背后的供货系统的设计 最早和大多系统策划的理解一样，我也觉得商城就是一个买东西的地方，最近新加入团队的策划妹子设计了商城系统后，发现自己的一个错误——忽略了在商城背后还应该有一个“供货系统”。 供货系统是一个什么玩意儿？顾名思义，也就是你商城里面卖什么东西的系统。其实乍一想，不就是配一张表填点东西和价格进去就行了么？但事实上真不是这 样简单的，看完了详细设计后，我发现其实这个供货系统背后有一个不算很复杂的机制存在。（为了避免一些问题，于是决定图全用 Windows 自带小画家而不 是 Office 软件制作）。 2 / 4买入系统：一个 Currency 与 GameItem 或者 Currency 转换的过程，也就是通常我们都 能想到的买入，不论是买入钻石还是用钻石买金币、金币买道具、钻石买道具，都是通过 Currency（钻石、金币、RMB）来购买道具 (GameItem)或者金币、钻石（Currency）。供货系统：这其实是在读表（我们假设这个表名为 MarketMall），从表中读取（或者说过滤出）一 批道具是要在商城进行贩卖的，当然这里并不是直接就开卖这些道具了，最早我是这么错误的理解的，但是现在发现由于活动等的需要，其实读取这个表只是第一 步，而读取这个表的本身意义只是将这些要贩卖的道具从整个世界全部种类的道具中归纳过滤出来，或者直白点说就是“缩小排查范围”。货源到库存货源：当读取表后，我们有了货源，货源与道具不同的地方在于，货源应该有一些道具没有的信 息，这些信息也就是建立这个 MarketMall 的最初意义，我们需要将其中的一部分放入库存货源。通常情况下，策划会有类似需求就是：几点到几点卖什 么、卖的东西轮流在切换；什么日子特别卖什么；每周的什么时候卖什么。那么这里就是根据当前服务器的时间从“货源”中过滤出一批来。这里的过滤，其实是一个机制的核心点所在， 如果只是初步理解，你会想到的是“策划往往需求的是某个时间段”，但是如果从一个游戏设计师的角度出发，思考结果是什么？“策划也许会要求：当玩家满足某 个条件的时候，可以购买什么”，举一些简单的例子：当玩家完成某个副本后可以购买A，当玩家在游戏中结婚后可以购买 B，当玩家在游戏中消费满 998 元之后 就可以购买 C。那么我们可以看出，其实这个过滤条件并非只有“时间段”这么简单，于是，我们在这里穿插一个脚本给策划，当然因为时间段是最常用的，我 3 / 4们仍 然应该把时间段作为表的通用列放在 MarketMall 里面，以提高判断效率（虽然地球人感觉不到）。库存货物到柜台货物：这里就是将过滤的东西告诉客户端的过程，但是之所以添加出这一步来，其实我是将他 们记录在了服务器内存中，一旦当客户端提出申请要购买东西的时候，我优先看这个表里面是否有申请购买的道具，并且判断和理性，如果不合理，那么这个表就脏 了，我需要重新计算，并告诉服务器错了，如果该道具合理，那么我认为这张列表仍然是干净的。 在这个设计环节中，有一个小小的技巧——因为目前大多手游并没有必要去做心跳，所以服务器并不知道客户端在线，因此不可能做到服务器广播给客户端，那 么其实我们应该让客户端去敲服务器的门——客户端计算时间到点了、或者登陆的时候敲服务器的门，提醒服务器该看看东西脏了没。 之所以去设计这样一个机制，其实还是考虑到大多时候运维人员并不乐意去为你维护这种活动数据表，并不是工作不认真，而是每次上百台服务器搞一次，出错率又高，时间开销又大，劳命伤财，不如在设计师这里就预先安排掉一些该做...