炉石传说 C# 开发笔记(6月底小结)

炉石传说的开发,已经有30个工作日了。

关于法术的定义方法,有过一次重大的变更:法术效果是整个炉石的核心,正是因为丰富的法术效果,才造就了炉石的可玩性。

原来构思的时候,对于法术效果没有充分的理解,所以只将效果数据做成了常数,例如 造成5点伤害。

随着更加深入的解除,发现还有 毁掉你的武器,对所有随从造成武器攻击力的伤害,这样的话,效果是一个 表达式

然后考虑到,有些追加效果,例如,对某个随从造成2点伤害,如果这个随从没有死,则抽一张牌,

这里就牵涉到了根据条件追加效果的处理。

同时,德鲁伊的抉择系列,有的是主动让用户选择效果,有的是根据战场形势自动计算使用效果,这些也是原本没有考虑到的。

经过权衡之后,将数据定义表格进行了重构。

(旧的法术定义)

炉石传说 C# 开发笔记(6月底小结)

(新的法术定义)

炉石传说 C# 开发笔记(6月底小结)

新的表格对于法术的定义更加详细具体,每个种类的法术都有自己不同的字段。

同时在法术的使用流程上,也加入了更多的思考,并且将这种思考落于设计书。先进行了设计,然后将成熟的设计转化成代码。

对于炉石这样流程复杂,规则诡异的东西,一定要彻底做好设计!!设计的时候发现问题,修改成本是1,开发的时候修改成本是10,测试的时候修改成本是100

炉石传说 C# 开发笔记(6月底小结)

接下来的一段时间,大概截止到6月底,将是做单体测试的时间。将整个架构进行必要重构后就要进行测试了。

对于代码的重构,包括对于名字空间和代码目录的重构,花了一些时间整理了名字空间和代码结构,让正确的代码文件放在争取的地方。

让正确的方法出现在正确的类里面。Engine是总的空间名称,下面有Card,Effect,Client,Server等子空间。

炉石传说 C# 开发笔记(6月底小结)

炉石的测试,最难的就是对于结算的测试和规则的测试。平心而论,炉石的结算规则还是非常模糊的。

1.如果奥术飞弹的第一发将一个随从打死了,随从的亡语是召唤一个随从,那么,这个时候进行召唤操作吗?召唤出来的随从也是奥术飞弹的目标吗?

如果是的话,每一个奥术飞弹的结果都要结算,如果不是的话,3发结束后进行结算。

炉石传说 C# 开发笔记(6月底小结)

如果是全体型的烈焰风暴呢?

肯定是对所有随从造成伤害后再一次性结算了。

炉石传说 C# 开发笔记(6月底小结)

2. 叫嚣的中士

如果场上没有其他随从,有时候这张牌是不能上场的?iPad的时候,以前的版本一定会让你选择一个施法对象。

3.如果带有召唤战吼的随从入场,遇上满员的时候,该怎么处理呢?

炉石的很多规则不是很清晰,所以开发的时候,可能需要做两手准备,或者能让用户自定义,让这个项目的核心更接近于一个引擎,而不是一个炉石定制的东西。

上一篇:[bx]和loop指令


下一篇:提高Linux运维效率的30个命令行常用快捷键