冬眠包子的博客

1. 需求出现  最近项目有了新的需求, 需要敌我双方英雄各自带领数十(百)个小兵对冲, 乱战. 在之前的方案基础上去掉特效后效等进行测试, 发现性能开销简直惨不忍睹, 帧数只能勉强维持15-20的样子, 200个英雄+小兵的情况下CPU大概有40ms的耗时, DrawCall200多个. 分析后发现开销基本在处理动画和drawcall上.2. 解决方案  针对上面的两个问题, DrawCall过多很容易联想到GPU Instancing, 因为小兵的mesh和材质都一样, 不过有一个问题, 小兵使

  这几天学了不少优化相关的课程, 趁还没忘完把脑子里还记着的整理一下= =. 所有资源导入(Importer)相关的都可以自己写导入类继承AssetPostprocessor处理, 然后自动化生成导入报告, 一旦发现资源有问题根据报告找对应人员. 但是对于一些小的, 相对没那么规范的团队, 属实是想的太美了, 最后还是美术来找你让你帮着查问题. 所以我的做法是在所有preprocess阶段都不处理, 后面包装成一件优化之类的按钮, 有问题直接报出来当场修改.动作Animation Type首先

  CGDC的独立游戏开发会听了一些独立游戏开发者关于解谜游戏的创作，结合自己的想法整理了一些关于剧本和解谜的东西，仅供娱乐。  一个最简单的解谜游戏流程其实和侦探小说一样，主人公受到某人的委托，开始调查某件事，通过收集信息，进行推理，解开谜题，最后得到真相。这其中收集信息，推理，解开谜题的一系列循环动作就是解谜游戏的核心，不仅要设计好谜题，巧妙填充以推进游戏流程，还要和整个剧本背景贴合不能过于突兀。剧本主题每一个故事都需要一个主题，需要在游戏前期通过某种方式来交代给玩家。主题基本决定了一个游戏的整

  3D游戏中, 一般会需要一个小地图挂在某个角落来提醒玩家位置, 资源位置, BOSS位置等等. 小地图是场景的略缩图, 同时这个小地图应该是实时刷新的, 用于更新玩家在地图中的位置.为了实时把玩家在场景中的位置反应到小地图上, 首先我们要创建一个新的摄像机放在场景的正上方用于渲染整个场景范围. 摄像机投影方式改为正交, 范围根据场景可移动范围大小调节. 新建一个render texture并且把摄像机输出设置为它, 在UI层级挂一个Raw Image, 把我们刚才创建的texture挂上去, 这是

1. 背景 考虑到成本与风险问题, 绝大多数游戏中的AI其实并不属于真正意义上的AI, 其中并没有对应机器学习算法的设计和AI的训练, 而是按照一定规则写死的, 因此游戏AI中最常见的是有限状态机和行为树. 有限状态机(Finite State Machine)定义了某个对象有限个状态, 通过各种条件或事件来实现状态的转换. 有限状态机的优点是理解简单, 每一种状态都是一个节点, 发生的任何事...