|
|
文/rasskiller
随着区块链概念的火热,区块链游戏的话题被讨论的也越来越多。说实话将来的区块链游戏形式可能谁都看不清楚,借此笔者想谈谈自己设想中的区块链游戏形式。
一、区块链游戏的前景如何？
笔者以前认为：“区块链游戏一定是最先落地的区块链项目。”随着最近思考的深入,我觉得这个说法有问题,应当改为：“利用游戏开发经验和游戏设计理念开发出的区块链应用一定是最先落地的区块链项目。”
这里有两点：其一,区块链游戏的形态应该不是目前任何一种游戏形式的直接移植；其二,游戏行业的经验能够让这个应用最先落地。
第一点的论述就不具体展开了,应该没有什么异议。第二点的思考过程是这样的：
- 区块链生态中存在着大量和链外数据通讯的环节,显然,比起大量需要和物理现实世界通讯的项目,与虚拟世界通讯显然更容易实现。
- 区块链生态设计不是简单的10%手续费,以国家税收设计为例,存在着在哪些领域收税,不同的对象收税的比例,福利的设计,对贫困人群的财富转移等问题。而分布式自治社区具体规则的设计难题,显然为了提升1%的数据而不惜修改整个新手流程或者重调游戏数值框架的策划们,比大部分潜在竞争者更有设计经验上的优势（按照这个逻辑来说,或许税务局的工作人员更有优势？只能期待他们不要过来降维打击了）。
- 游戏项目可能是所有可能的区块链项目中回本周期最短的项目。如果思路不对,立刻砍掉或者调整。如果思路正确,最先收回投资成本。
二、区块链游戏可能的方向？
区块链+游戏的结合方式很多,在整个游戏产业链的许多环节都可能存在结合的可能,例如类似于steemit设计一种游戏推广形式。任何一个游戏在推广前先发一个币,然后所有自愿为新游戏做广告都可以获得这个币,最终厂商将营收的80%回购所有的推广币,或许这样的项目在将来也能站住脚跟。
但是本文想讨论的区块链游戏,仅限于“虚拟资产上链”这样一个思路。这并不代表诸如反外挂,电子竞技联赛,游戏推广去中介化,游戏开发资金募集等方向没有前途,只是笔者能力有限,这些方向更加扑朔迷离,只能暂且避而不谈。
三、区块链游戏的具体形态？
就“虚拟资产上链”这个构想而言,游戏在运行过程中,必然会有厂商和游戏老鸟从游戏中获得回报,说白了就是钱。假如这些钱的出现就是某些菜鸟玩家的损失带来的,那这个游戏就是交易所的变种,不能算得真正的游戏。
笔者心目中区块链游戏的具体形态,首先它应当是一个支持UGC的游戏。菜鸟玩家付出的钱,来换得老鸟玩家UGC的价值,从而加快游戏进程,老鸟玩家获得的钱,应当是UGC创造的价值。至于游戏厂商嘛……总归会需要抽点手续费,也算是设计了整个游戏玩法所创造的价值所在吧。
举个例子,假如一个游戏是类似于炉石的游戏。厂商如果卖卡,那就不符合这里提出的标准了。卡应当以较为便宜的价格或者免费的方式卖出,玩家建立卡组,若卡组的胜率较高,玩家可以出售卡组,且游戏可以规定没有购买该卡组的玩家,不可以用完全一样的卡组出战。以上仅为说明思路,并不代表笔者认为直接卖卡牌的思路不好。
四、区块链游戏的游戏体验？
目前的区块链游戏都存在着响应超慢的问题,不禁让人想起以前用netants下载网络资源的日子。在笔者看来,区块链游戏的架构可能需要做如下改动
- 游戏仍需要中心化服务器。
- 中心化服务器的逻辑类似于普通游戏的前端,只展示理论上可能的结果。
- 链上数据与合约类似于普通游戏的后端。
- 当链上数据和中心化服务器数据不一致时,以链上数据刷新中心化服务器数据。
假设游戏环节中有一步为抽卡,笔者大致能想到的流程设计如下：
- 中心化服务器产生一个随机数A并发送给玩家。
- 玩家基于该随机数再输入一个自己想到的随机数B（这个随机数产生过程可以通过一个第三方插件完成,玩家也可以选择输入自己的生日等幸运数字）。
- 中心化服务器基于A&B(此处是将AB字符串拼接在一起),并计算该值的hash256值,展示计算结果并根据计算结果将卡牌数据提前写入中心化数据库（此时玩家感觉已经获得了卡牌）。
- 将过程3发送至链上进行计算,最终计算完成后检验中心化服务器上的数据。
- 游戏官网上公布随机数和卡牌掉落的所有逻辑细节,例如随机数<10000,掉落张飞,10000≤随机数＜20000,掉落关羽……
整个过程中,玩家的抽卡体验没有等待,最终结果也是完全公正的,毫无作弊可能。
不过,随着网速的快速提升,netants这个软件马上就淡出了网民的视野,说不定下一代公链就解决了响应慢的问题,那么游戏也不需要设计地这么蛋疼了。
五、云养鱼游戏设计。
说了那么多,如果自己不设计一个游戏可能也是说不过去的,那就在此献丑了。
游戏规则部分：
- 玩家账号对应一个鱼缸,鱼缸最主要属性包括：容量。实时属性包括：含氧量,食物量和粪便量。
- 鱼类,第一版设计10个品种,厂商只提供品种枚举为1的鱼类,其余9种鱼类都需要通过变异获得,鱼类的统一属性包括：体积,食量,耗氧,粪便速度。
- 海参,第一版设计4个品种,均只能由特定鱼类变异获得,海参统一属性包括：体积,食量（吃粪便）,耗氧。
- 海草,第一版设计4个品种,均只能由特定鱼类变异获得,海草统一属性包括：体积,氧气产量,食物产量。
- 鱼类,海参和海草也存在改变外观的参数。
- 至于鱼类繁衍过程,鱼缸扩容,付费的鱼缸清洗/增氧服务,额外的增加玩法的属性例如鱼缸盐度和鱼类的适合生存盐度,变异相关的参数,等请自行脑补,不再赘述。
程序架构：
大部分的计算都由中心化服务器完成,只有在繁殖,买入和卖出时,才需要合约介入和链上数据更新。链上验证的逻辑举例如下：含氧量=上次验证时的含氧量+（两次验证时间间隔）*（鱼缸内所有生物产氧量和耗氧量总和）。基本上和后端验证玩家体力的逻辑类似,不需要实时验证,只需要在玩家进副本前验证一次即可。若出现极为少见的链上数据和中心化服务器数据不匹配,则刷新中心化服务器数据。
希望的玩家目标：
- 2条鱼（这样就可以进行繁殖了）,需要额外的付费服务来清理鱼缸和充氧（可以考虑每天免费赠送玩家若干）
- 拥有某一个特殊外观的生物
- 鱼+海参+海草,但不构成生态,几个生物的属性相加,并不能进行无限循环
- 鱼+海参+海草+构成生态
- 构成生态+牛逼的外观的鱼
- 全品类的生物集齐
自认为这个构想还算比目前世面上能看到的游戏好玩些,在此声明此想法完全没有知识产权,哪位大佬想拿去开发就拿走吧。
有意者请在后台留言或者联系作者，作者微信号：grasskiller。
via：公众号“区块链游戏CryptoGames”
|
|
发表于 2018-3-28 17:00:12