开发日志02：我确定这是一群bug（自我检讨）

#聚光灯gamejam开发者日志

by 修bug修得有点破防的寒师

这是一个写代码破防的抱怨＋用ai写代码和在unity写代码的一些注意事项+我要开始承认开发过程中作为领导者我还是有做得不好的地方+改进计划

我不行了吧，后半夜不报错的代码早上一起来再编译一次就全都红了，到底什么环节出了问题？？？

还好，大部分只需要把ai给的示例删掉或者在前面加using指令就能解决,还有的是因为缺少数据，还有的是因为定义成了static所以没法继承

用表格管理脚本（你可能注意到了这里有多个事件中心，为了提高代码准确性，我分功能向ai提问，因此需要后期将每个功能中ai生成的事件中心进行合并）

记得改高级保存选项，否则在untiy里全都是菱形问号

现在的代码结构还是不太干净，数据层和操作都混在一起，完全是按照游戏实际操作区域去划分的，这种划分方法其实特别的想当然

所以我要放弃这个屎山了，先去做本来就需要重新写一套代码的新手教程，后面再慢慢改。

*开发小技巧总结，在我过去的比赛里，我经常想当然地以为小型项目我们只有一个程序的时候，不需要特意关注程序的进度，因为程序会自己把控数据结构，最后交付的时候能跑得动就可以，但是这次自己写程序发现，首先要在赛前就找框架写的比较干净的程序去写程序或者说人多的时候优先让这样的选手去当主程，其次在过程的监督中一定不要把进度简化为“做完了第一关”这样的颗粒度，这个颗粒度还是太大了，策划的策划案往往是线性的，只标注步骤（如图）

然而其实每个步骤之间是有很多功能的，因此就算从把交付颗粒度从“做完某一关”改成“做完某个步骤”其实这个颗粒度也是太大了，最好就是精细到“做完了某个gameobject的Mgr”（但是是不是又太细了），精细到“实现了某个功能”就好，然后把功能对应的最小元件名称，交付物，验收标准做好（其实怎么拆分也是个大工程），这样才能避免程序员在项目中作为一个“黑盒”静默地脱离了整个开发集体的情况出现。

每次开发接近尾声的时候我总能看到作为程序的队友们苦改bug，也许一开始规范好交付元件，做好数据层和代码层的隔离，这些问yifuluxi题就不会发生，我要承认这是我参加了很多次比赛但始终把自己放在策划或者pm的舒适区里，避免了解程序架构所导致的。现在因为不得不自己写程序去”face the music“，我才终于在自己的错误里理解了行业内或是教材所说的一些针对长期项目的程序工作规范是多么的重要。

回朕车以复路兮，及行迷之未远。

对了，关于跟美术沟通，我也有一些事情没有做好，我以为规定好命名规范就不会出现太大的问题，但是美术在设计的过程中想要添加新的视觉效果的时候，往往就没法跟策划案一开始聊好的组件名称一一对应，比如背景如果为了更好的视觉效果从一层变成了两层，想要添加一些小动画，增加新的组合示例，想要多做一套字体等等，都会产生新的无法命名的素材。我应该在一开始除了规范好命名规则和表格以外，教会美术如何给组件分类和创造性命名，防止出现”这么组合“这种奇怪的名字。

还有，美术的实际交付人和美术资源的完成往往是不同的人，我一开始想当然地说，每个美术元件我都已经拆的这么细了，应该就能一个人画完一个组件了吧，然后美术同学表示：难道不应该一个人勾线一个人上色吗？我一想对啊，刚好两个人一个比较全能，另一个上色苦手但是设计能力很强，也许这种分工才更好，但是考虑到给文件改名字这些dirtywork还是要分一下，所以还是在表格结尾加了”交付人“的选项。

开发到现在，还没跟大家介绍过我们讨论的玩法和美术风格，留到下期再说吧！