标签：style blog http color 使用 strong
炉石传说的开发，已经有30个工作日了。
关于法术的定义方法，有过一次重大的变更：法术效果是整个炉石的核心，正是因为丰富的法术效果，才造就了炉石的可玩性。
原来构思的时候，对于法术效果没有充分的理解，所以只将效果数据做成了常数，例如 造成5点伤害。
随着更加深入的解除，发现还有 毁掉你的武器，对所有随从造成武器攻击力的伤害，这样的话，效果是一个 表达式。
然后考虑到，有些追加效果，例如，对某个随从造成2点伤害，如果这个随从没有死，则抽一张牌，
这里就牵涉到了根据条件追加效果的处理。
同时，德鲁伊的抉择系列，有的是主动让用户选择效果，有的是根据战场形势自动计算使用效果，这些也是原本没有考虑到的。
经过权衡之后，将数据定义表格进行了重构。
（旧的法术定义）
（新的法术定义）
新的表格对于法术的定义更加详细具体，每个种类的法术都有自己不同的字段。
同时在法术的使用流程上，也加入了更多的思考，并且将这种思考落于设计书。先进行了设计，然后将成熟的设计转化成代码。
对于炉石这样流程复杂，规则诡异的东西，一定要彻底做好设计！！设计的时候发现问题，修改成本是1，开发的时候修改成本是10，测试的时候修改成本是100
接下来的一段时间，大概截止到6月底，将是做单体测试的时间。将整个架构进行必要重构后就要进行测试了。
对于代码的重构，包括对于名字空间和代码目录的重构，花了一些时间整理了名字空间和代码结构，让正确的代码文件放在争取的地方。
让正确的方法出现在正确的类里面。Engine是总的空间名称，下面有Card，Effect，Client，Server等子空间。
炉石的测试，最难的就是对于结算的测试和规则的测试。平心而论，炉石的结算规则还是非常模糊的。
1.如果奥术飞弹的第一发将一个随从打死了，随从的亡语是召唤一个随从，那么，这个时候进行召唤操作吗？召唤出来的随从也是奥术飞弹的目标吗？
如果是的话，每一个奥术飞弹的结果都要结算，如果不是的话，3发结束后进行结算。
如果是全体型的烈焰风暴呢？
肯定是对所有随从造成伤害后再一次性结算了。
2. 叫嚣的中士
如果场上没有其他随从，有时候这张牌是不能上场的？iPad的时候，以前的版本一定会让你选择一个施法对象。
3.如果带有召唤战吼的随从入场，遇上满员的时候，该怎么处理呢？
炉石的很多规则不是很清晰，所以开发的时候，可能需要做两手准备，或者能让用户自定义，让这个项目的核心更接近于一个引擎，而不是一个炉石定制的东西。
炉石传说 C# 开发笔记(6月底小结),布布扣,bubuko.com
标签：style blog http color 使用 strong
原文地址：http://www.cnblogs.com/TextEditor/p/3796930.html
