要点

地块渲染主要使用了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

DOTS全称Data-Oriented Technology Stack，官方中文名叫多线程式数据导向型技术堆栈（来源于官网），顾名思义这是个“技术栈”，这里面包含了多个技术：

1. Entity Component System(ECS)
2. C# Job System
3. Burst Compiler
4. And more(Physics, NetCode, Tiny…)

需要我们编写业务逻辑代码的部分都在第一项”ECS”里面，所以之后的介绍大多都会围绕如何（以面向数据的思想）书写基于ECS的代码。

前言

这也算是之前挖的一个坑，现在来把它填上

我在做什么

设想一下，如果万一哪一天有人在我的博客下面写了评论，我如何能第一时间得知这个消息并进行回复呢？折腾完这一波，我们就能实现：当有人发表了新的评论时，我的手机能立即接收到推送，并会自动将评论的内容等详细信息发送到我的邮箱；然后我回复之后对方的邮箱可以收到我的回复内容。

本文的重点就在于第一点：手机能立即接收到推送，当然除了有新评论这个事件，我设定了每天早上8点钟它会给我推送上一天的网站访问量，我好知道昨天有多少人访问了我的网站，当日最受欢迎的文章是哪一篇。

如上图，左图是每日报告，右图是新评论的推送通知。如果之后想在什么其他事件上加推送也很容易。

前言

博客貌似已经荒废了半年了233

时间回溯至2019年8月。。我换了一家新公司，一上来就忙成doge，也就一直都没时间写博客，这期间倒是也有好几个话题可以写，然而工作繁忙+懒癌晚期也就一拖再拖。

填坑

上一篇博客提到的更方便的评论提醒，用的东西叫做Bark，之后有空再说吧。

前言

事情的起因是上个月本站依赖的提供访问量统计和评论后台存储功能的LeanCloud由于某些原因域名故障了几天。

之后虽说是回复了，但是必须需要实名认证才能继续使用他们的服务了。所以说我一想，反正之前在LeanCloud上跑的业务也十分简单，也就是统计下阅读量，保存下博客评论啥的，好像完全可以托管在自己的服务器上嘛，同时也更灵活，想对自己的数据做什么直接就可以操作，不用再去套一层SDK了。

开工

说干就干。

接口设计

由于我并不是web相关的程序员，于是上网随便搜索了几篇文章，简单看了下，首先所有的url都以https://api.inspoy.cc/开头，https+专属二级域名，既美观又显得专业233，为了之后的扩展性，这次定了以下几个：

• [GET]/v1/blog/article/article_key - 获取指定文章的阅读量
• [PATCH]/v1/blog/article/article_key - 更新指定文章的阅读量，使数据库中的记录+1
• [GET]/v1/blog/comment/article_key - 获取指定文章的所有评论
• [POST]/v1/blog/comment/article_key - 在指定文章中发表评论
• [POST]/v1/blog/bugreport - 用于接收前端网页上报的报错信息

参考了阮一峰大佬的这篇文章大致是遵循了RESTful API的设计准则。目前是API的第一个版本，且只有博客的功能，所以URI都是以/v1/blog/开头的233

前言

造轮子真开心hhh

我就是很享受准备工具的过程，感觉就像是在玩游戏一样233。所以说给现在在做的游戏鼓捣一套自动化流程就变得很有趣了。

那么打算做些什么呢~

首先就是Unity的打包了，这样每次提交代码后都能收到是否打包成功的反馈，并且每次打包完毕后都会把包体复制到指定的共享目录中，我在工作电脑上随时可以拿到最新的PC整包。

其次，我在项目里写了不少单元测试（Framework的每个功能基本上都写了），我想知道每当我修改了代码之后，这些测试是否还能通得过，这些信息我也需要及时收到反馈。

还有一个就是代码质量检测了。像是哪里偷偷藏了一个TODO，哪里可能有潜在的BUG了，哪里有坏味道了之类的。这些都是技术债，所以我需要随时看到检测结果，并及时修复掉。

前言

这次说摄像机，还是把对应的Wiki地址发出来：摄像机系统

基本概念

我这个游戏采用的视角是一种类似各大RTS游戏的操作方式，玩家可以操作的参数有镜头平移，镜头高度和环视角度三个。其中镜头的实际平移的方向由输入的原始平移向量和环视角度决定，而镜头高度决定了镜头的俯视角度。

前言

今年的GDC2019上，Unity推出了基于DOTS（Data Oriented Technology Stack，面向数据技术栈）的物理系统，好像还是跟Havok合作的。反正就是为了配合Unity主推的DOTS的一套全新的东西。

现在（2019年6月初），可以选择用Unity现有的物理系统或者使用Havok，但是选了Havok之后运行起来会提示暂不支持，还要等到2019年夏天。

这套物理系统的东西很多很复杂，而我的游戏也暂时不需要真实的物理模拟计算，而是只需要最常见的鼠标点击事件，所以我就先只看了场景查询（射线检测）这一块。

前言

一看时间，距离第0篇发布已经过了超过一个月了😆，最近忙于享受福报，每天回到家就很晚了，完全没时间推动进度orz。

总之现在的功能还十分简陋，每篇就只写一个模块吧，这次是地块。