思考
这种游戏果然应该渐进式开发，先设计好类容易导致各种各样的问题，像接口不一致和滥用智能指针的问题
编码过程
最近都在考试，没什么时间打这个，只能考完通宵肝一些
这一阶段实现了血条，主要是通过cocos::ProgressTimer实现，并将其添加为cocos::Sprite的子节点实现跟随
实现了攻击，攻击作为技能实现，利用了技能的抽象，然而并不有利于减少代码量，但是看起来更整齐
实现了死亡回城，再英雄更新时判断血量并回城重置
实现了泉水回血，通过判断单位位置和阵营，为了省时间仿照技能样式但不纳入技能范畴
遇到的问题
智能指针问题
之前我一直以为std::shared_ptr是一个非常强大的东西，随便用没有坑，能简化C++的内存管理，事实证明是我太天真了。考虑以下代码
int *pp = new int;
shared_ptr<int> sp1(pp);
shared_ptr<int> sp2(pp);其中sp1与sp2并不会共享引用计数，导致在代码块退出时pp所指向的内存单元被回收了2次，导致出错
智能指针shared_ptr设计是让代码中所有指针都由智能指针管理，不应存在裸指针，而指向现存对象的智能指针也应由智能指针创建，混用智能指针与裸指针容易导致各种各样的问题。
其实对象的引用计数管理可以仿照COM的IUnknown或者cocos::Ref的单根继承实现，手动释放和引用，有时虽然繁琐，但更清晰
由于设计上的疏忽导致我们的模型设计中大量存在shared_ptr，这存在着极大的隐患，并已导致程序崩溃(甚至导致我心态崩了)，但重构已是不可能的了，因此只能步步小心
模型设计问题
王者光耀这类游戏存在大量状态及状态转换，我之前妄想使用多态解决所有问题，但这也是不现实的，这类需求适合状态机实现，这是从一开始就出现的问题，然而中期我才意识到，已无力回天
总结
这次作业算是比较失败的一次作业，我作为队长，有一定责任，我进行了一些反思，在本次团队作业中，我主要有一下几点不足：
- 在团队作业初期没有进行明确合理的分工
- 设定目标时考虑过少，当时我认为的是“不试试怎么知道自己原来真的做不到”
- 没有设定明确的接口和代码规范，团队里的人各有各的思路，写出来的代码别人有时候不好看懂和对接
- 滥用不熟悉的技术
其实这也和我第一次带团队，经验和领导能力不足有关吧。今天在这里写下这些，希望以后能吸取教训，也希望以后看时，能发现自己有什么进步