【构】从游戏Buff谈装饰者模式那些事儿
来源:互联网 发布:java web创意项目 编辑:程序博客网 时间:2024/04/30 04:12
隔了好久,来写这篇文章。
明天发版,所以随便写了两句。
考虑这样的问题,Player有个属性,防御力,int defence。有各种情况可以增加防御力,那么应该怎么处理呢。
最简单的,类Player里面增加一个属性。
public class Player{ protected int defence; public int Defence { get { return defence; } set { defence = value; } }}
任何需要改变防御的地方呢,可以用Player.Defence = xxx来设置。
现在有两个系统,一个是装备Armo,一个是Buff,Armo按百分比增加防御,Buff在一定时间内增加防御。
按照上面的方法计算防御,如下所示:
player.Defence *= Armo.DefAddedPercent;
player.Defence += Buff.DefAddedValue;
好了,现在装备和Buff都生效了。
player的defence值也发生了变化。
但是,这个会出现问题。
首先,装备和buff的前后关系,会影响到最终defence的数值!!!
基本上没有策划会这么设计。
其次,Buff结束或者装备卸下,会导致无法恢复到之前defence的数值!!!
这尼玛基本上会导致玩家在讨论区大肆讨论了。
嗯,问题出在哪里?
因为同一条数据,被三个模块同时修改,这三个模块互相并不知道对方的存在。
把上面的代码改成如下方式就能改变现状。
public class Player{ protected int defence; public int Defence { get { return ComputeDefence(this, buff, armo); } }}
此时,外界不能直接修改defence的值。而外界获得defence的值,如何获得则被封装到ComputeDefence方法中。该方法同时处理player原始数据,buff的加成,armo的加成。这样,只要计算方法不改变,其他三个模块只作为参数传入。互相不会影响。
0 0
- 【构】从游戏Buff谈装饰者模式那些事儿
- 【构】游戏命令模式的那些事儿
- 【构】游戏状态机的那些事儿
- 游戏的那些事儿
- 从咖啡谈装饰模式
- 设计模式那些个事儿
- 观察者模式与装饰者模式相遇的那些事
- 游戏buff的设计
- 【游】游戏Buff机制
- 从装饰者模式到Context类族
- 从装饰者模式到 Context 类族
- 棋牌游戏网站支付接口那些事儿
- 戏说模式之装饰者模式(游戏)
- 从U_I_C去H_K_B_U 上课那些事儿
- 从《明朝那些事儿》说开去
- 从乌云看企业安全那些事儿
- 游戏中BUFF的实现
- 从装饰模式到aop
- 生成有数字和字母生成的不重复的验证码
- 开发神器-Android Studio插件
- HDU 5012 Dice
- iOS开发中如何实现app作为外设被连接的功能?
- Java Exception 捕获和展示
- 【构】从游戏Buff谈装饰者模式那些事儿
- 前端架构之简洁的工作流
- more--每天一个-02
- Python - 迭代(for...in...:)
- iOS tableView点击分区下拉单元格特效
- 机器学习复习——KNN
- 《C语言程序设计》课后编程题选讲(ch2)
- Python
- Java 动态代理机制分析及扩展