从2015年决定开坑，到现在已经将近两年。
最开始的打算是，以最容易坚持的方式做出成品，是敏捷开发的思路。
随着回合逻辑、移动逻辑以及部分UI等功能的完成，我开始感到力不从心。高度的耦合使我没办法继续接着做下去。
于是项目开始第一次重构。期间受到一些大神的指点，学习了一个回合制游戏应该有的程序框架。这时我开始渐渐明白设计对于一个工程的重要性。
紧接着不久，Avalon又推荐了我一个在Asset Store上面的战棋游戏框架，这个框架十分有借鉴意义。于是，在学习了这个框架之后，我把其中的一些思路应用在了本作中，算是第二次重构。
现在已经算是毕业季，最近的事情也比较多。但目前来看，情况应该已经大致稳定。
于是就有了本贴。
其一，记录开发流程，方便对工程的掌控。
其二，方便各位随时了解开发进度，更加透明，也更加方便我们之间的交流。

【2017-5-17】
关于框架的设计。
从最初做移动开始，到接下来做技能，意识到技能需要拿出来进行抽象包装。
保证角色使用技能，效果由技能决定。
最终决定分为三层。
角色在最上层负责如何使用，向技能获取信息。
技能在中间层，包含技能的全部效果。
最下层是每个逻辑的具体实现，封装成一个个模块，供技能调用。
如此分层的理由是：技能中有许多共用的逻辑，比如创建范围，比如传入角色修改某项数值，等等。
可以确定，技能是玩家角色和AI角色的最小调用模块。
但是，技能的调用是一个过程，不是瞬间的一个方法。其中AI与玩家又有不同：AI可以在一开始决定所有对技能的数据输入，而玩家则是逐步对技能进行数据输入，并且UI只为玩家服务。
所以，在技能中，应该明确玩家的技能调用方式和AI的调用方式。
玩家对技能的调用是泛型的，即并不知道玩家会调用哪一种技能，所以需要在角色层制定一种统一的技能调用方式。
AI对技能的调用取决于列表中有什么技能，并且代码决定最终调用的技能类型。
玩家数据由技能主动获取，AI数据由AI传入（是否合适？）。
输入格式不必统一（玩家方面由技能决定，于是可行。AI方面需要按种类划分技能，规定有限个输入格式）。

【2017-5-18】
游戏中如：移动、休息、恢复查克拉、忍术、忍具、甚至是回合结束时候确定面向朝向，都可以视作技能，按照技能的做法来做。
最初一批尝试几个典型的技能：移动、休息、恢复查克拉。
它们的输入部分各不相同：
移动从创造移动范围开始，会根据焦点，不停显示可视路径，最终输入确认信号，完成输入，角色开始移动。移动完成后，此模块终止。
休息不需要输入，只需要确认是否休息。
恢复查克拉需要一个int类的输入，将查克拉恢复至多少。这个数据，玩家方面从UI获取，AI方面主动对技能输入。
同时，休息和恢复查克拉会有防御力的Debuff，包含了Buff系统的实现。
将这些效果综合，就可以批量生产其余大部分技能。如各伤害类忍术忍具，只需综合移动部分创建范围的实现与恢复查克拉部分改变属性数值的实现、毒飞镖可综合移动部分和Buff。
所以现在更重要的是找出具有典型作用的技能进行设计与实现，确定技能实现框架、编写流程以及调用规范。

【2017-5-22】
UI分为两部分。
一部分是全局的UI，由UIManager中实现管理。
另一部分是技能部分的UI，属于技能调用的一部分。由各个技能实现。
由于开发经验不丰富，我不知道这样分离是否合理，但目前暂定这种实现方式。
今天出现了另一个问题。
关于技能引用的释放时机。
目前的做法是一旦技能完成后立刻释放引用。但是一旦释放便无法做技能重置。
可能更好的做法是只有技能在Reset的时候返回True并释放引用。
这样就能保证，在下一个技能开始之前，可以自由重置技能。
对技能体系的思考：
SkillManager应该担任更多的工作，比如区分常规操作和角色技能，设置更多的容器区分技能种类等等。之后再向UIManager输出，以供生成UI界面。

【2017-5-22】
最近看到了贴吧中关于伤害公式的讨论。
感谢@洛·云 所做的相关工作。
对于数值这块儿我一直没什么研究，最近才了解了一下。
好像是大致分为乘算和加算两种方式。
而在本作中，我个人更倾向于做简单的加算，也不设置过多的参数与逻辑，也不一定追求一定与原作一致。
但是基本的一些功能要实现，如：背后伤害加成、属性伤害等。
目的是够简单，容易控制和设计。

【2017-5-23】
关于角色动画的解决方案：
可想的动画状态其实并不是很多，如果不追求过高的表现的话。
角色Idle动画、角色移动动画、角色拳击动画、角色施法动画、角色受击动画等。
角色模型现在已经有了，接下来需要对角色进行骨骼绑定蒙皮（可能会有难度）。
之后再录制动画。
如果难度没有想想中的大，会考虑根据法术录制不同的动画。
如果难度太大。。可能会做取舍。

【2017-5-24】
Skill类加入Transform character
确认是可以抽象的条目。
Confirm方法必须有，用于确定执行改变，并终结OnUpdate方法的执行。
但是这一条却无法抽象到Skill类中。
因为无论是玩家的或是AI的Confirm的参数列表都会因技能的不同而不同，无法确定。
枚举状态机仍无法抽象，按技能需求自行定义。
关于ShowUI：
因为AI部分不需要ShowUI，所以在Init中判断当前Player的类型是否为HumanPlayer。
从而确定是否显示UI部分。
Check的位置按技能需要进行放置，不固定。
接下来是制作回合结束部分的逻辑，以技能的形式，对应各角色的“回合结束”按钮。
Unit中添加bool unitEnded。
修正借鉴框架中RoundManager的EndRound方法，执行技能时调用，根据游戏的进行状态判断EndRound的执行方式。比如：是只有部分玩家回合结束还是所有玩家都执行完成。
之后接着实现了Rest的部分逻辑。
以上两个新实现的技能均不完整，仍需完善和打磨。

【2017-5-25】
PlayerNumber很有程序风格的从0开始递增。
场景添加佐助。
目的是：完善敌人与盟友对当前角色影响的逻辑，更好的完成回合结束逻辑。
修改UnitManager，使其自动识别场景中的角色并添加至容器。
Unit中修改bool unitEnded为属性，public get private set。

【2017-5-25】
本作的回合结束与借鉴的回合框架的回合结束有些区别。
回合框架的回合结束依赖全局的UI按钮作一次性结束。
而本作中每一个角色都有各自的回合结束按钮，所结束的是当前角色的当前回合。
所以需要修改一些逻辑。
关于技能引用释放的时机：
推翻之前的假设，需要依据技能而定。因为有些技能在confirm之后不适合再做reset了。
AI由于没有具体实现，先由玩家角色代为Play，具体就是AIPlayer中仍掷RoundState状态为WaitForInput。
好处是方便调试。
至此回合结束功能大致完成。仍需后续完善。
接下来会继续完成会和流程逻辑，加入最后的方向选择“技能”和选择回避忍术忍具“技能”。

【2017-5-26】
顺序是先进行方向选择，再进行回避忍术选择，之后结束回合。
方向选择功能在重构之前的项目中是已经完成了的。
需要配合重构后的项目架构，把之前项目中的逻辑移植过来。
在大致完成方向选择功能移植之后，又出现了一些新的问题。
方向选择功能不进行引用释放，重置功能在本技能内部完成重置。
方向选择功能包含了下一步骤的选择回避忍术的UI部分。确保可以在UI显示时回退。
所以Reset状态也不一定返回true。
在UI选项进行时，玩家有三条路可走：Reset技能、使用回避忍术以及不使用回避忍术结束回合。
玩家方面是UI引导，AI方面是AI从可选列表中自主选择，并且不需要Reset。
接下来应该是回头做基本忍术。
典型：忍者组合拳、分身术、瞬身术、变身术。
在这些忍术完成之后，框架的基本形态应该就可以确定了。

【2017-5-27】
端午节调休，接着更。
接下来实现术·忍具列表以及忍者组合拳。
Skill中分离出UnitSkill，UnitSkill继承Skill，多了level和description。
继续分离出Attack。
Range中分离出MoveRange与SkillRange。
SkillRange部分在重构前也已经实现。
分离的目的是减少重复工作，这点很重要，关乎以后再添加一个新忍术所需要的工作量。
这么看下来，想要实现术·忍具列表以及忍者组合拳，还需要很多工作。

【2017-5-31】
思考了关于Attack层抽象的必要性。。
暂时觉得。。可能没什么必要。。于是删除。
设想是这样的：由于系统预设技能的特殊性，所以Skill中可抽象的内容并不多。而UnitSkill包含了除开连续技这样的特殊技能外一个技能在运行时候的大部分常规流程逻辑，关键信息通过具体的类来传入。
忙活了半天，但是却并不能进行显式测试。
接下来会添加上术·忍具的UI界面，实现忍者组合拳。

【2017-6-1】
毕设打印。。请假一天。

【2017-6-2】
技能或许分别存在于不同的容器，但它们都能在skillList中找到，因为CharacterAction最终会在这个列表中寻找并执行技能。
添加了术·忍具的UI界面。
实现了忍者组合拳的范围创建和hoverRange的正常显示（由原先的检测鼠标改为现在的事件触发）。
角色们之间的互相伤害还没有做，往后放一下。
接下来会添加各技能对回合结束或者secondAction的连接，以完成整体的回合流程。（重构前的进度）