• Dapp的PVP发模式--magic-maze-2d游戏解读


    前言:
      未来基于Dapp的游戏可能会多起来吧, 尤其是博彩类游戏, 由于区块链匿名特性, 加之数字货币不受国家监控, 几乎成了一个法外之地. 大量游戏团队都往之涌入.
      今天讲讲当前Dapp的一种游戏模式--pvp, 结合一个github上的开源项目magic-maze-2d来解读.

    简介:
      代码是从github上搜索到的, 它是基于波场(公链)来发布合约的.
      具体的github地址magic-maze-2d, 我这边权当搬运工了, 我觉得代码写的很好, 非常地敬佩作者.
      

    设计思想:
      pvp模式, 转变了之前人和平台博弈的局面, 转为人和人之间的博弈, 平台只作为组织者而存在. 这样游戏服务商可以承包大部分的业务逻辑, 而涉及数字货币的交易则由智能合约来管理. 公开透明, 玩家都能接受.
      继续借用作者的流程图:
      
      其合约的核心代码如下所示:

    contract MagicMaze {
    
     	// 用于创建房间(带着游戏房间信息的hash), 设定奖励规则
        function create(uint256 id, string memory name, string memory mazeHash) public payable {
            require(msg.value >= SERVICE_FEE);
            require(mazes[id].bonus == 0);
            bytes32 hash = stringToBytes32(mazeHash);
            mazes[id] = Maze(id, name, hash, msg.value, msg.sender, address(0), address(0));
            emit mazeCreated(id);
        }
        
        // 新玩家进行挑战注册
        function challenge(uint256 id) public payable {
            require(mazes[id].bonus != 0);
            require(mazes[id].challenger == address(0));
            require(mazes[id].bonus == msg.value);
            
            mazes[id].challenger = msg.sender;
            mazes[id].bonus += msg.value;
        }
    
        // 胜利者获取奖励(带着房间信息, 可生成hash, 用于验证)
        function takeBonus(uint256 id, string memory mazeInfo) public payable {
            require(mazes[id].bonus != 0);
            require(mazes[id].winner == address(0));
            require(mazes[id].creator == msg.sender || mazes[id].challenger == msg.sender);
            require(msg.value >= SERVICE_FEE);
    
            bytes32 mazeHash = sha256(abi.encodePacked(mazeInfo));
            if (mazeHash == mazes[id].mazeHash) {
                mazes[id].winner = msg.sender;
                msg.sender.transfer(mazes[id].bonus);
                emit winner(id, msg.sender);
            } else {
                emit falseClaim(id, msg.sender);
            }
    
            serviceCharge += msg.value;
        }
    
    }

      简单来说, 可以归纳如下:
      1. 玩家调用服务端创建房间, 后端根据房间信息+秘钥(MazeInfo), 生成hash, 返回给玩家.
      2. 玩家带着房间信息 + hash, 去智能合约创建房间(create).
      3. 有另外一个玩家来挑战, 先在智能合约中注册为该房间的挑战者(challenge), 然后和服务端交互确认, 如果胜利, 服务端下发房间信息和秘钥(MazeInfo)
      4. 赢家可以根据这个MazeInfo去合约中获取奖金(takeBonus).
      在整个流程中, 服务端都没有参与合约里奖池建立和提取, 而服务端相当于公平的裁判者.

    总结:
      这种pvp的模式, 平台不参与博弈, 只收取服务费. 而且挑战双方, 不需要同时在线, 可玩性极强, 感觉会流行一波, 不过PVP模式的游戏, 也是一个潜在的缺点, 就是有些不良平台会搞托(机器人), 这样即做裁判员, 又做运动员, 轻松赢得奖池.
      我还是相信大浪淘沙后, 最终会留下几款体验超好, 又值得信赖的精品.

  • 相关阅读:
    python3.0与python2.0有哪些不同
    python常用内置模块,执行系统命令的模块
    06python 之基本数据类型
    python语言简介、解释器、字符编码介绍
    http协议&接口规范&接口测试入门
    基于APPIUM测试微信公众号的UI自动化测试框架(结合Allure2测试报告框架)
    SQL注入工具sqlmap的注入过程记录
    unittest框架
    测试转型之路--学习ing
    Tomcat分析-启动过程
  • 原文地址:https://www.cnblogs.com/mumuxinfei/p/10728327.html
Copyright © 2020-2023  润新知