讨论群:     827072601
爱发电:     https://afdian.net/@taohuayuan
任务板:     https://trello.com/b/StForyw7/taohuayuan
twitter:      https://twitter.com/zephyr1125
wiki:          https://taohuayuanwiki.a2hosted.com
discord:    https://discord.gg/sMuKYE6

这段时间效率有点低下唉，但还是要回顾一下，实在鸽的太久了，先放一个视频展示一下吧。

https://www.bilibili.com/video/av49807216/

简单说呢，就是终于以ECS的基础，完成了具体游戏逻辑的第一部分：规划与建设。以及正式的UI开始实装。

已知问题：

• 角色动作固定，始终播放行走：因为ECS目前还不支持SkinnedMeshRenderer。等支持之后会去制作站立/行走/建设等动画的切换。
• 玩家角色与所有角色一样：原因同上。实际要有纸娃娃换装，在以前的日志里展示过。
• 不同角色行走路线重复：以后会根据寻路增加微调来丰富不同角色的路线。
• 篝火白模：就是还没做完嘛！

这个视频拿出来看的话还是非常简陋的，不过从一个项目结构的角度来说，相当于是一个从底层架构转入内容开发的里程碑啦!撒花~

另一方面这段时间做正式版UI做的比较糟心，试图找一些现成的框架，但是因为我有键盘/手柄双支持的特殊要求，基本上没有能很好支持的，大部分都面向移动游戏。于是只好自己写，然后就更加感觉到了UGUI特别的原始...还有一些怪怪的毛病，最后只好下载开源的UGUI代码改了改覆盖过去。等我写完之后整理出一个框架，说不定能拿去卖钱了=。=

接下来呢？

接下来，会继续完成玩家的基本操作：生产、拆除、取消。同时从篝火开始逐步一个个实现游戏内元素的逻辑。到这个阶段devlog应该会比以前死磕程序底层的时期要好看一些了。

PS:说到程序底层，这两天有了一个新的想法，顺便聊一下：

ECS改造期间，有一项重要的优化，就是使用Job系统把工作分散到多线程，Unity官方称之为Jobify。然后在我实际制作过程中，我意识到有一种情况似乎是无法Jobify的：

举个例子而言，比如一个System的功能是分派工作给角色们，因为工作与执行者需要一一对应，那么如果这个分派过程做成多线程的话，每个线程必须要了解到其他线程分配给了谁，从而避免自己重复分配，然而作为同步执行的多线程Job，这从逻辑上就是不可能的。

一般的说，我可以这么总结为：如果一个过程的运行条件需要读取他自己的运行结果，那么这个过程是无法Jobify的。

想法可能并不成熟，我还在官方论坛上发了贴，地址在https://forum.unity.com/threads/it-seems-i-found-a-little-principle-of-jobify.663736/。还被Unity CTO回复了，不过我觉得他对我的理解有误，可能是因为我渣英语的关系……