讲道理NAS是今年的618买的，折腾完就想写篇博客记录下，结果就愣是拖到了双十一😂
迫于自己的个人文件越来越多，一直想把2011年拥有手机以来拍过的所有照片系统性地整理起来，再加上现在台式机已经换成了全固态，买一台NAS放到家里就提上了日程。
其实两年前装修的时候就已经在考虑了，只不过那时候资金正紧张，算了笔帐，NAS加硬盘的成本还是有点高，就暂时搁置了。
时间来到了2021年，购物车里一直躺着西数HC320和群晖920+，结果4月份突然冒出个奇亚币，矿老板们疯狂买硬盘挖矿，眼睁睁看着硬盘从1300涨到了接近3000……果断放弃，继续等硬盘回归正常价格。
后来的事情已经知道了，奇亚币崩盘，硬盘逐渐开始降价，差不多618的时候终于降回了21年4月的水平，果断下单。
地块渲染主要使用了RenderBatchGroup来避免过多的GameObject，并辅助以有BurstCompiler加持的裁剪函数以加速渲染。
目前有个需求是，我们可以在地图上绘制若干片不同类型的区域，对于每种区域，地块需要有不同的颜色叠加，我们需要给每个地块设置一个颜色属性。
所以目前就无法使用SRP Batcher来辅助合批了，因为这玩意目前并不支持通过MaterialPropertyBlock来设置PerObject的属性（给同一批次的每个渲染对象设置不同的属性）。当然SRP Batcher支持设置PerMaterial的属性，因此遇到使用同一个Shader的不同材质时，就可以对其进行合批，我会在之后其他元素的渲染时利用到这个特性。
我最终使用的还是传统的GPU Instancing的方案，这样就可以满足目前的需求了。
自从18年刚开始有这个想法到现在已经差不多两年半了，然而连一个Demo都没拿出来😂总结了一下，项目的进程大概分为了三个阶段：
18年5月，决定自己做一个模拟经营类的游戏。最初的想法是用尽量新的酷炫的技术来开发，当时Unity的DOTS刚出来（当时还没有DOTS这个名字），简单了解了下发现ECS的设计模式很适合于模拟经营（我设想的方向是类似《监狱工程师》这种场景种同时存在着大量单位在运动的感觉，而不是《边缘世界(Rimworld)》这种只有少量角色但每个角色的行为都有精密的设计，总之就是“大规模”）。当时已经有Entitas这个第三方的UnityECS框架了，不过既然Unity官方在推，即使还是早期预览版，我还是对官方框架的前景非常看好的。
18年5月到11月，平时工作也比较忙，也没啥时间做项目，所以进度推进还是很慢。然后最致命的是，Entities库在早期的更新频率非常快，API的变更也非常快，经常过一个月更新一下新版发现各种API都改名了或者直接取消了，写起来就很痛苦。
这倒不是Unity的锅，人家在论坛里一开始就强调过，现在还处于早期预览阶段，对于某种需求，目前存在着多种实现方式。官方会观察各位开发者的反馈，最终只会留下一种方式，其他的会被取消（在这里有持续讨论有关API的易用性）。
再加上ECS的配套功能非常缺乏，而且思维还没来得及转换到面向数据的设计思想，进度推进就更慢了。
接触Unity的DOTS其实已经有差不多两年时间了，当年刚开始研究的时候甚至还没有DOTS这个说法，期间其ECS库的API各种变化，不过到目前来看基本上稳定了，所以决定今天把自己的理解整理出来，便于回顾查阅。。。
DOTS全称Data-Oriented Technology Stack，官方中文名叫多线程式数据导向型技术堆栈（来源于官网），顾名思义这是个“技术栈”，这里面包含了多个技术：
需要我们编写业务逻辑代码的部分都在第一项”ECS”里面，所以之后的介绍大多都会围绕如何（以面向数据的思想）书写基于ECS的代码。
博客貌似已经荒废了半年了233
时间回溯至2019年8月。。我换了一家新公司，一上来就忙成doge，也就一直都没时间写博客，这期间倒是也有好几个话题可以写，然而工作繁忙+懒癌晚期也就一拖再拖。
上一篇博客提到的更方便的评论提醒，用的东西叫做Bark，之后有空再说吧。
事情的起因是上个月本站依赖的提供访问量统计和评论后台存储功能的LeanCloud由于某些原因域名故障了几天。
之后虽说是回复了，但是必须需要实名认证才能继续使用他们的服务了。所以说我一想，反正之前在LeanCloud上跑的业务也十分简单，也就是统计下阅读量，保存下博客评论啥的，好像完全可以托管在自己的服务器上嘛，同时也更灵活，想对自己的数据做什么直接就可以操作，不用再去套一层SDK了。
说干就干。
由于我并不是web相关的程序员，于是上网随便搜索了几篇文章，简单看了下，首先所有的url都以https://api.inspoy.cc/开头，https+专属二级域名，既美观又显得专业233，为了之后的扩展性，这次定了以下几个：
参考了阮一峰大佬的这篇文章大致是遵循了RESTful API的设计准则。目前是API的第一个版本，且只有博客的功能，所以URI都是以/v1/blog/开头的233
造轮子真开心hhh
我就是很享受准备工具的过程，感觉就像是在玩游戏一样233。所以说给现在在做的游戏鼓捣一套自动化流程就变得很有趣了。
那么打算做些什么呢~
首先就是Unity的打包了，这样每次提交代码后都能收到是否打包成功的反馈，并且每次打包完毕后都会把包体复制到指定的共享目录中，我在工作电脑上随时可以拿到最新的PC整包。
其次，我在项目里写了不少单元测试（Framework的每个功能基本上都写了），我想知道每当我修改了代码之后，这些测试是否还能通得过，这些信息我也需要及时收到反馈。
还有一个就是代码质量检测了。像是哪里偷偷藏了一个TODO，哪里可能有潜在的BUG了，哪里有坏味道了之类的。这些都是技术债，所以我需要随时看到检测结果，并及时修复掉。
这次说摄像机，还是把对应的Wiki地址发出来：摄像机系统
我这个游戏采用的视角是一种类似各大RTS游戏的操作方式，玩家可以操作的参数有镜头平移，镜头高度和环视角度三个。其中镜头的实际平移的方向由输入的原始平移向量和环视角度决定，而镜头高度决定了镜头的俯视角度。
