feat: Damages Display

[aLIEzsss4]

No description provided.

[github-actions]

Deploy preview for vercel-autochessia ready!

✅ Preview
https://vercel-autochessia-jd11d32ur-aliez.vercel.app

Built with commit 2cfab1f.
This pull request is being automatically deployed with vercel-action

[aLIEzsss4]

我认为需要更改现在的表结构，现在关于英雄的数据类型可读性可扩展性不是很完美。

假设把每个英雄都作为一个721，通过tokenid获得属性：最大血量、最大魔法、攻击、攻击距离、移动距离、购买金钱、售卖金钱、技能、等级、名称、动画地址、预览地址、物品、速度、状态:[商店、棋盘上、备战区、战斗中]、拥有者、x、y、等，

当处于战斗中时，tokenid不变属性增加:buff、乙方棋盘x、乙方棋盘y、对手棋盘x、对手棋盘y、对战者、当前血量、当前魔法。

假设把商店比喻成一个nft交易市场，每次刷新出来都会生成一批721，或者从库存的721随机筛选几个出来，增删改查都是通过tokenid来执行，不再依赖数组的index。

这样会更加易读，易扩展。

可能会修改的地方

Player: {
      keySchema: {
        addr: "address",
      },
      schema: {
        health: "uint8",
        streakCount: "int8",
        coin: "uint32",
        tier: "uint8", // start from 0
        exp: "uint32", // experience
        heroes: "bytes32[]",
        heroAltar: "uint64[]", // list heros that user can buy, creature id + tier
        inventory: "uint64[]",
      },
    },

Player的heroes、heroAltar、inventory 都返回tokenid，空站位英雄用0来表示

Piece: {
      // using uint8 in order to put all data into one slot of bytes32
      // 8+8+8+32+32+8+32+32+8+32+32=232 < 256
      schema: {
        x: "uint8",
        y: "uint8",
        tier: "uint8",
        health: "uint32",
        attack: "uint32",
        range: "uint8",
        defense: "uint32",
        speed: "uint32",
        movement: "uint8",
        maxHealth: "uint32",
        creatureId: "uint32",
      },
    },

Piece 添加主键tokenid 修改对应属性

Board: {
      keySchema: {
        addr: "address",
      },
      schema: {
        enemy: "address",
        status: "BoardStatus",
        turn: "uint32",
        // pieces in battle
        pieces: "bytes32[]",
        enemyPieces: "bytes32[]",
      },
    },

Board的pieces、enemyPieces 都返回tokenid

DPS: {
      keySchema: {
        tokenid: "uint32",
      },
     schema: {
        turn: "uint32",
        owner:"address",
        enemy:"address",
        physicalDamage: "uint256",
        magicalDamage: "uint256",
      },
}

DPS 基于tokenid来查询，不再依赖数组

[ClaudeZsb]

能否详细描述一下 “现在关于英雄的数据类型可读性可扩展性不是很完美” 的原因，在什么场景下遇到了什么问题，我没有看到目前设计存在的问题

[aLIEzsss4]

能否详细描述一下 “现在关于英雄的数据类型可读性可扩展性不是很完美” 的原因，在什么场景下遇到了什么问题，我没有看到目前设计存在的问题

可读性
使用 tokenId 来唯一标识每个英雄,可以避免依赖数组索引来区分英雄,提高可读性。
例如在棋盘上,可以直接通过英雄的 tokenId 来索引,而不需要记忆索引位置。

可扩展性

1. 对于 DPS 显示,有 tokenId 的话可以非常方便的统计每个英雄的伤害。
2. 固定的卡牌池子。
3. 可定制化的棋子，如果把每个棋子视为721，房主可选择一套棋子NFT来进行游戏。

总结一下,使用 tokenId 作为英雄的唯一标识,可以提高代码的可读性和可扩展性。
在不影响现有功能的前提下,增加 tokenId 属性是一个非常好的设计优化方向。

[ClaudeZsb]

首先必须肯定的是利用英雄nft构成一局游戏的英雄池，这是很有趣的事情。

其次关于你说的索引，这存在于购买英雄、删除仓库英雄、摆放英雄过程中，用索引的一个目的是将琐碎的计算任务从链上迁移到链下，如果不用索引，链上势必要先找到英雄在数组中的位置，才能继续后面的操作，而这个显然是可以在链下事先计算出来的。简单来讲跟合约交互用索引还是Id等价于通过Id计算英雄在数组中索引的任务是放在合约端还是前端。在链上使用数组来存储同类数据的前提下，这个计算任务无法避免。基于此，我们选择把这个计算任务放在链下的原因就变的很简单，因为链上计算要消耗更多地gas。

另外nft的tokenId不能简单的复用到我们的游戏，因为每个玩家都可能有剑圣，而且每个人可能不止一个剑圣，所以仅仅套用nft的tokenId是不足以解决我们游戏的问题，你仍需要附加一些信息组成在每局游戏概念下唯一的英雄Id。

关于你提及的可读性跟可扩展性问题。

1. 可读性，你大概指的是祭坛跟仓库中的英雄数据。有一点要清楚，就是我们的英雄是有creatureId的，但不携带等级信息，也就是说用creatureId不能唯一确定一个一级剑圣。所以我们使用了creatureId + tier（套接，不是数值加法）的形式来区分一级剑圣跟二级剑圣。你可能疑问是，都是一级剑圣时，没法区分，为什么不直接赋予每一个一级剑圣一个唯一的Id？当然可以在祭坛刷新出来的时候就创建一个拥有唯一Id的英雄或者在购买时，选择在放置在棋盘上时才创建也是处于节省gas的考虑。这里必须强调一个事实，就是棋盘上的英雄是具有唯一Id的，如果你的建议只是想要有唯一Id，那我们就不存在冲突了。祭坛刷新时不创建英雄我觉得不需要过多考虑，唯一可以争辩的点是在购买时创建还是在放置时创建。这个我们可以进一步讨论。
2. 可扩展性，我读下来这里你想要的就是唯一Id，已经有了，就是heroId或者pieceId。

[ClaudeZsb]

• pieceId is of type bytes32
• what about adding a column named target of type bytes32 that denotes which piece receives this damage.

[ClaudeZsb]

you better update this according to the new table schema or just clear it