游戏中的物品交换逻辑抽象
如果总结一下游戏的内部逻辑，或许会让游戏变得很无趣，不过程序员大概会很高兴，比如说我。
如果把用户的各种信息都抽象成“物品”、“个数”，那么所有的游戏逻辑都是用户之间的物品交换。
为了方便描述，我来自定义一套语法表示这种交换。这里用的是类BNF语法，如果没耐心可跳过。
物品交换 := 物品描述 “=>” 物品描述
物品描述 := 物品描述 “+” 单个物品描述 | 单个物品描述
单个物品描述 := 用户 “(” 物品 “,” 数量 附加属性 “)”
物品 := 物品名称 | 物品函数
物品函数 := rand “(” 物品列表 “)”
物品列表 := 物品列表 “,” 物品 | 物品
附加属性 :=”,” “{” 附件属性列表 “}” | “”
附加属性列表 := 附加属性列表 “,” 属性 | 属性
属性 := 属性名 “:” 属性值
数量 := 数字 | 数字函数
数字 := 非负整数 | MAX
数字函数 := auto_change “(” 初始值 “,” 每秒变化步长 “,” 边界值 “)”
| max “(” 数字列表 “)”
数字列表 := 数字列表 “,” 数字 | 数字
函数说明：
- rand代表在一系列物品名称中返回任意选一个物品名称。
- MAX代表该物品最大数量值
- max代表从一系列数字中返回最大值
- auto_change代表从初始值开始，每隔1秒时间就加上步长，直到达到边界值为止不再变化。auto_change并非如其名一般会自动变化，而是在下次请求该物品数量的时候才计算当前值。步长可以为负。
希望不要看这些BNF晕了头……直接看例子其实也可以。
列举一下常见的游戏场景背后的数字逻辑：
- 用户A用100游戏币买一个桌子获得10点经验：
- A (游戏币, 100) => A (桌子, 1) + A (经验, 10)
- 注：这里把游戏币、经验都当做物品来处理，从程序角度来说这没有问题，虽然直观上有点怪。
- 用户A使用10点幸运点打开一个宝箱得到一个物品，这个物品是玩具1、玩具2、玩具3中随机的一个：
- A (宝箱, 1) + A (幸运点, 10) => A (rand(玩具1, 玩具2, 玩具3), 1)
- 用户A送用户B一个玩具，留言“my present”，获得10点经验：
- A (玩具, 1) => B (礼物, 1, {留言: my present, 关联物品: 玩具, 关联数量: 1, 时间: YYYY-MM-DD}) + A (经验, 10)
- B (礼物, 1, {留言: my present, 关联物品: 玩具, 关联数量: 1, 时间: YYYY-MM-DD}) => B (玩具, 1)
- 用户A在一号树坑种下一棵树，将在3000秒后长成桃子共4颗，其中最多2个可以被偷走，而B偷走了1个获得10点经验，A则收走了剩下3个，获得20点经验：
- A (树种子, 1) => A (成长中的桃子, auto_change(0, 1, 3000), {土地号: 1})
- A (成长中的桃子, 3000, {土地号: 1}) => A (私有桃子, 2, {土地号: 1}) + A (公有桃子, 2, {土地号: 1})
- A (公有桃子, 1, {土地号: 1}) => B (桃子, 1) + B (经验, 10)
- A (公有桃子, 1, {土地号: 1}) + A (私有桃子, 2, {土地号: 1}) => A (桃子, 3)
- 注：当任何一个可以看到桃子树状态的用户刷新状态且第二步中输入的数值满足要求时，第二步物品交换就会发生。
- 用户A接了一个任务X，用玩具1和玩具2，可以换得100游戏币和10点经验，任务有效时间为30,000秒，且A最多能接5个任务：
- A (可接任务, 1) => A (任务X, auto_change(30000, -1, 0))
- A (任务X, max(1, MAX)) + A (玩具1, 1) + A (玩具2, 2) => A (游戏币, 100) + A (经验, 10) + A (可接任务, 1) + A (已完成的任务X, 1)
- A (任务X, MAX) => A (可接任务, 1)
- 注1：A的初始可接任务设置为5就能限制A最多接5个任务
- 注2：第三步为取消任务逻辑
- 用户A将一个桌子从储物箱里面挪到1号房间，又从1号房挪到了2号房：
- A (桌子, 1) => A (桌子, 1, {x: 10, y: 0, room: 1})
- A (桌子, {x: 10, y: 0, room: 1}) => A (桌子, {x: 20, y: 10, room: 2})
仅仅通过这些很基本的物品交换逻辑，（理论上）就可以实现一个比较复杂的游戏数值逻辑了。只要实现一个服务，把所有这些可能的物品交换逻辑都放在某个配置里面，游戏核心就出来了。
这种做法也有不足，有些时候客户端需要从右边推导出左边的可选值就比较麻烦。比如物品1可以由游戏币或充值币其一换得，客户端需要根据物品1反查出游戏币和充值币各自需要的数量。这在技术上其实可行，只是需要花费更多精力去想明白里面的需求。
有话想说？请留下评论吧~~如果喜欢我的blog，欢迎订阅~~
评论
还没有任何评论。
留下评论