为了准备GGJ，提前熟悉一下Unity的使用。做一个平台跳跃原型。

非常trivial，基本上就是让ai写一下然后改改（因为我的cursor免费额度用完了，所以用的trae），过程就不说了。说几个可能有趣的点。

1. 使用3d的渲染系统和2d的碰撞系统。

2. 玩家检测在不在地板上的方法是，在脚下放一个groundCheck对象，然后检测这个对象周围一个半径内是否和groundLayer层的东西碰撞。（当然也可以直接用玩家坐标来算。）

isGrounded = Physics2D.OverlapCircle(groundCheck.position, groundCheckRadius, groundLayer);

3. 玩家和别的东西默认会有摩擦力，可能导致平地走不动。需要创建一个Physics Material，把它设置为很光滑，然后赋给玩家。

4. transform好像没有克隆方法，如果你想复制一个东西此时的位置给另一个，可以用transform.position。不要直接赋transform，这不创建新对象，会跟着跑。

5. 土狼时间之类的手感优化，代码写起来是很容易的。手感优化的难点应该在于测试和迭代吧。

6. 无论是材质还是什么别的Asset，都在Assets目录下再开一层，别侥幸认为同类只会有一两个就放在外面。免得到时候把你Assets搞得乱糟糟。

7. 类似上一条：给所有东西取个名字，越早越好，因为你会需要复制粘贴它们。看到我的Cube (18) 能绷住的估计不是程序员。（反正，需要被复制粘贴的东西，就稍微弄漂亮一点。）

总体来说，明显能感觉到Unity确实是在碰撞检测方面非常方便的，写这么个东西会比自己手搓快很多，而且不容易出很数学的bug，另外可以不用动脑子就改的方面也多。不过它也确实是明显会限制思维的，我会自然而然地不去思考能不能同时有多个玩家，玩家能不能在实体空间和反空间中穿越，以及更多我还没想到的想法。另外，就之前写扫雷的体验而言，Unity在那一块似乎并没有什么优势，毕竟逻辑全部外包给C#了，Unity只负责一个渲染，然后扫雷这种游戏的渲染又不是很适合ECS。之后如果要写推箱子，逻辑估计还是外包给C#，Unity的碰撞检测又是一点都用不到，我估计要用pygame甚至C++写原型了。

我觉得我之前对于用什么引擎这件事有点过度内耗了。引擎只是工具，遇到什么需求就用什么，一个高手应当能自如地使用各种工具。说实话，我自认为在代码这一块我已经勉强算个高手了，不该把过多的注意力和决策力再放在引擎这种事情上了。更加延申地说，我不该把过多的注意力放在「某种构想能否实现」上，而应该放在「我有什么构想，我如何迭代我的构想」上了。

话是这么说，但是我积压的几个灵感又是卡在了「没有实现出来」这一环上，只能说自己行动力有待训练。下一个我可能会做一个推箱子原型，并写一个推箱子「可否过关」计算器。这应该是一个简单的动态规划，可能可以加入一点点剪枝。这应当是一个考验性能的事情，所以我现在计划用python，Unity，C++各写一遍，比对一下大家的性能差异。（这种类型的实验我经常看到一些程序员会做，但自己之前很少做，主要是懒，不愿意做重复性的事。但是为了避免走弯路，早点低成本地知道谁的性能更好，我有必要做这件事。发在开发日志上，也让别人可以看到吧。对我来说，也算是某种自我突破了。）