【策划】游戏中的商城和抽奖系统设计.docx
5页
玩耍中的商城和抽奖系统设计2023-2023 版内部资料 留意保管Planning scheme玩耍中的商城和抽奖系统设计最近两天的设计遇到了一些商城和抽奖相关系统的设计，之前执着于玩耍乐趣的设计却始终冷淡了这两块系统，事实上真的动起手来却觉察有时候在这两块的系 统设计和制作中，存在很多混乱的东西——太多需要整理成机制的东西始终没有去思考，以至于需求堆多了之后写死的垃圾代码和数据表的列数都在骤增于是总结 了一些关于这两个系统的设计和思考，随笔登记商城系统背后的供货系统的设计最早和大多系统筹划的理解一样，我也觉得商城就是一个买东西的地方，最近参与团队的筹划妹子设计了商城系统后，觉察自己的一个错误——无视了在商城背后还应当有一个“供货系统”供货系统是一个什么玩意儿？顾名思义，也就是你商城里面卖什么东西的系统其实乍一想，不就是配一张表填点东西和价格进去就行了么？但事实上真不是这 样简洁的，看完了具体设计后，我觉察其实这个供货系统背后有一个不算很简洁的机制存在〔为了避开一些问题，于是打算图全用 Windows 自带小画家而不 是 Office 软件制作〕买入系统：一个 Currency 与 GameItem 或者 Currency 转换的过程，也就是通常我们都 能想到的买入，不管是买入钻石还是用钻石买金币、金币买道具、钻石买道具，都是通过 Currency〔钻石、金币、RMB〕来购置道具 (GameItem)或者金币、钻石〔Currency〕。
Planning scheme供货系统：这其实是在读表〔我们假设这个表名为 MarketMall〕，从表中读取〔或者说过滤出〕一 批道具是要在商城进展贩卖的，固然这里并不是直接就开卖这些道具了，最早我是这么错误的理解的，但是现在觉察由于活动等的需要， 其实读取这个表只是第一 步，而读取这个表的本身意义只是将这些要贩卖的道具从整个世界全部种类的道具中归纳过滤出来，或者直白点说就是“缩小排查范围”货源到库存货源：当读取表后，我们有了货源，货源与道具不同的地方在于，货源应当有一些道具没有的信 息，这些信息也就是建立这个 MarketMall 的最初意义，我们需要将其中的一局部放入库存货源通常状况下，筹划会有类似需求就是：几点到几点卖什 么、卖的东西轮番在切换；什么日子特别卖什么；每周的什么时候卖什么那么这里就是依据当前效劳器的时间从“货源”中过滤出一批来这里的过滤，其实是一个机制的核心点所在 ， 假设只是初步理解，你会想到的是“筹划往往需求的是某个时间段”，但是假设从一个玩耍设计师的角度动身，思考结果是什么？“筹划或许会要求：当玩家满足某 个条件的时候，可以购置什么”，举一些简洁的例子：当玩家完成某个副本后可以购置A，当玩家在玩耍中结婚后可以购置 B，当玩家在玩耍中消费满 998 元之后 就可以购置 C。
那么我们可以看出，其实这个过滤条件并非只有“时间段”这么简洁，于是，我们在这里穿插一个脚本给筹划，固然由于时间段是最常用的，我们仍 然应当把时间段作为表的通用列放在 MarketMall 里面，以提高推断效率〔虽然地球人感觉不到〕库存货物到柜台货物：这里就是将过滤的东西告知客户端的过程，但是之所以添加出这一步来，其实我是将他 们记录在了效劳器内存中，一旦当客户端提出申请要购置东西的时候，我优先看这个表里面是否有申请购置的道具，并且推断和理性，假设不合理，那么这个表就脏 了，我需要重计算，并告知效劳器错了， 假设该道具合理，那么我认为这张列表照旧是干净的在这个设计环节中，有一个小小的技巧——由于目前大多手游并没有必要去做心跳，所以效劳器并不知道客户端，因此不行能做到效劳器播送给客户端， 那 么其实我们应当让客户端去敲效劳器的门——客户端计算时间到点了、或者登陆的时候敲效劳器的门，提示效劳器该看看东西脏了没之所以去设计这样一个机制，其实还是考虑到大多时候运维人员并不情愿去为你维护这种活动数据表，并不是工作不认真，而是每次上百台效劳器搞一次， 出错率又高，时间开销又大，劳命伤财，不如在设计师这里就预先安排掉一些该做的事情。
X 次抽奖中必定有 Y 次出 Z 种物品的设计这是现代筹划设计抽奖转盘的时候常见的需求〔现在连转盘都吹牛了，这世界……〕——“我有一个极品装备，期望玩家抽 1000 转盘，确定能抽到 1 个， 脸 好点的可能 1、2 次就有了，脸黑的要到第 1000 次”其实假设我们把这个问题简化到这步来做，这是在给自己找麻烦，从玩耍设计师的角度来看这个问题， 其 实是“我有 Z 种物品，他们分别会在 X 次抽奖中出 Y 个”，固然其中的 X 和Y，应当是最小次数的最小公倍数，比方a1 物品要在 30 次内必定出 1 个，a2 物品要 在 17 次内出 2 个，那么此时，X=510，Z=[a1,a2]，Y[a1]=17，Y[a2]=60这种设计我们不能承受传统的针对每一次抽取来做转盘，或许好的数值筹划能够设计出来〔在我看来，数值设计师应当是那种当我写了一大段规律和简洁的算法 之后，我告知他他能想到某个我没听说过的数学算法，完善解决这个问题的人，不是那种只能推推加减乘除4 则运算的〕，但我想我的力气不够，我才用代码的方式 解决这个问题：假设我们掉落的东西构造是：DropItem = {ItemIds:Array
之所以承受 IntArray 来，这是考虑到每次抽取可能会抽到多个东西的状况，假设确定每次就掉一个，那么就可以不用 Array}而上面说到的掉落物，我们整理一个构造就是：LootItem = {ItemIds:Array
var lastIndex:Int = 0; //上次落在第几次抽取上var setTimes:Int = 0; //已经成功放上转盘了多少个了while (setTimes < loopCount && turntableSet < X){lastIndex = Math.round((lastIndex + Math.random*X)%X); if (canPutHere(lastIndex )==true){ //主要负责推断转盘这个坑能否放奖品了，写法各异，略putLootToTurntable(loot.ItemIds); //这个主要负责把东西放上转盘，写法各异，略setTimes += 1;turntableSet += 1;}}}这样，我们已经把全部“重要抽取”放进转盘里面了，至于空的坑，就用“不重要的奖品”去填充了，具体做法各异，略。
