游戏开发

在开发2D游戏的时候，不同的设备分辨率下，经常需要将背景以高或以宽来适配。如果以高适配，即背景图的高度填充整个屏幕，然后去缩放宽度。最终效果图如下 ...

在开发2D游戏的时候，对于图片的 Mesh Type 设置我们应该选择 Full Rect 还是 Tight 呢？ ...

最近在接入Topon广告聚合SDK是，导出XCode工程后，编译报了一堆错误，搞了好久，这里记录一下解决过程。 ...

Unity ios导出XCode工程后，通常需要手动设置签名，就像下图中的样子。只要简单的两部设置，就可以自动选择我们想要的签名。 ...

在 Unity 项目中接入Sigmob 时，遇到很多问题，他们的文档写的也不是很清楚，特别是对于 Android 开发没有很深入了解的情况，读起来很困难，这篇博客记录了详细的 Sigmob 广告 sdk 接入过程。 ...

Boids 可以理解为类似鸟群的东西，就是多个个体之间的相互作用。在游戏开发中经常会用到。例如 RTS 游戏，控制一个坦克战队，如何保持行进方向的一致性，以及坦克之间互相有一定有间隔，又不会间隔太大，这里就可以使用 Boids 相关的理论来实现。 在众多这方面的文章中，基本上会涉及到三个方面，跟随、分离、聚合。跟随，就是说整个群体有一个行进的大方向。分离，则是个体与个体之间有一定的间隔，不至于发生碰撞。而聚合，就是个体不能离群体太远，不能脱离群体。 对于上面提到的三个方面，简单来说，就是一个力的叠加。 跟随 一个鸟群往哪个方向飞，可以假设有一只领头的鸟，其他的鸟跟随这只鸟的方向。知道领头的鸟的方向，知道自己当前的飞行方向，就可以计算出应该向中个方向施加一个力，可以使自己的方向，偏向于领头的鸟的方向。 分离 分离，是要保证个体之间不要离的太近，不要发生碰撞。先考虑两个物体的情况，假设要使物体 A 远离物体 B，只要从 B，向 A 施加一个推力，就可以将 A 推离 B。那如果 A 要同时和 B 与 C 保持距离呢？一样的，只需要从 B 和 C 分别向 A 施加一个推力，这两个的合力，就是 A 远离 B 和 C 的方向。同理，不管 A 要与多少个物体保持距离，只需要从每个物体出发，向 A 的方向施加一个力，就可以将 A 推开。 上面只考虑了 A 远离其他物体的情况，如果每一个物体都要与其他物体保持距离呢？一样的，只需要从每一个其他物体，向自己的方向施加一个力，这个合力，就是自己运动的方向。 聚合 为了保证个体不脱离群体，还需要一个聚合力。就是将个体自身，推向群体中心的力。 分离的力和聚合的力一定程度上抵消，从而达到个体之间即保持了距离，又保证了每一个体不脱离群体。 下面的代码是我的一个小游戏项目中的，其中只用到了分离和聚合。只要懂了原理，就可以根据具体的情况灵活变通，达到自己想要的效果即可。 using UnityEngine; using System.Collections.Generic; using System.Collections; public class GamePlayFlock : MonoBehaviour { public static List<GamePlayFlock> flockList = new List<GamePlayFlock>(); public static void StartAllFlock() { for(int i = 0; i < flockList....

在 APK 包上传到一些应用市场时，通常要求开发者对 APK 进行签名，下面记录一下签名步骤。 ...

友盟游戏统计 SDK 可以很方便的统计一些游戏数据。使用他们的自定义事件，来统计自己项目关心的数据。现在接入 SDK 已经比以前方便了很多，不需要再导出 Android 工程去修改 Java。下面将一步一步详细说明。 要使用友盟 SDK，一共有以下几步 在友盟后面新建应用 在友盟后面建立自定义事件 下载并导入 SDK 调用 SDK 1. 在友盟后面新建应用 首先注册账号，然后进入友盟工作台。↓ https://www.umeng.com/ 然后点击上面的产品，移动统计 ↓ 点击添加应用 ↓ 然后填写应用信息，下面是我随便填的，根据自己的应用信息填写即可（随便填也没关系）↓ 点击注册后，将跳到下面的页面，这里我们只要关注这个 AppKey 即可，其他的不用管。这个 AppKey 会在 Unity 中用到 ↓ 2. 自定义事件 建立好了应用后，就要想好我们想要统计哪些数据。例如，有多少用户点了开始游戏，有多少用户点了 观看广告，有多少用户观看广告结束，等等，这些都可以统计。 所谓的统计，也就是使用自定义的事件名，在不同的地方调用一下友盟的代码。所以接下来我们就建立自己想要统计的数据事件。 在应用页面，点击我们刚才新建的应用 ↓ 然后依次点击 设置 -> 事件 -> 手工添加 ↓ 我们下面先定义一个统计游戏开始的事件，事件 ID 是这个事件的唯一表示，会在 SDK 调用时用到，显示名称是让我们自己知道这个事件是干嘛的。然后点击确定 ↓ 添加完后的事件，会显示在事件列表中。接下来我们再添加一个统计事件，例如游戏结束。↓ 现在我们已经有了两个事件，当然，还可以添加更多，统计更多数据。这里为了演示，就只添加两个。↓ 3. 下载并导入 SDK 建立好了事件，就可以在项目中使用了，首先要将友盟的 SDK 导入工程中。去友盟的 SDK 页面下载 SDK https://developer.umeng.com/sdk/u3d，这里我们下载 Unity3D 的。 下载下来的是一个 ZIP 压缩包，解压后，依次找到里面的 Unity3D -> analytics -> analytics_unit3d_x....

在游戏开发的过程中，整个项目的资源管理是很重要的一部分。涉及到与美术、策划等同事的协作，以及资源的打包，和后续运行时资源的更新，加载，卸载，内存管理等方面。规划好资源的的各个目录存放，以及资源的分类，会为后续的开发工作节省不少时间。这一篇博客主要来聊一下到资源的存放问题，而 AssetBundle 打包，以及运行时的更新和资源管理，将在后面的博客中详细说明。 资源类型 一个游戏项目，涉及到的资源主要有 配置数据、图片、模型、材质、Shader、字体、音频、视频、动画Clip、Prefab、Animator Controller、Timeline、场景文件、Lua脚本 等。 关于协作 首先说一下协作问题。在游戏开发的过程中，美术的同学需要将资源直接提交到建立好的项目中的指定目录中，一般来说，提交到哪个目录，是由程序的同学来决定，具体哪个目录，要根据后续的资源打包以及管理等方面决定。美术的同学提交的资源一般就是模型、动画、贴图等。 而配置数据，则通常由策划同学来提交。配置数据的方式有很多种，常用的例如 Excel，有的项目是直接将原始的 Excel 文件放到工程中，而有的是将 Excel 数据转成其他格式再放到项目中。改表由策划同学来着手操作，在配表的过程中，除了数值，可能也会涉及到一些资源路径，例如有一些图片，是要动态加载的，那么路径也就配在某个模块的相关配置表中。而这些路径配在表中的资源，通常也由策划同学根据不同的系统来操作资源的位置。当然，首先会有一个父目录，在这个父目录下，策划的同学可以自由操作资源的位置，然后将资源的路径配置在数据表中。 还有一个很重要的部分是UI，对于UI来说，如果不打图集，放入项目目录中的都是一个一个的散图，则可以由UI部分的同学直接将UI的图提交到指定的UI父目录下，父目录下的子目录，根据不同的模块来划分，共用的同可以放到一个公用的目录中。对于图的移动操作，都要在 Unity 中进行操作，防止 Prefab 上的图片引用丢失。如果UI使用 TexturePacker 这类工具打成一张图集，则可以由程序同学来做，在开发某个模块时，顺便将对应UI的图打成一张图集，原始的UI图就不必放到工程中，放在外部的一个美术的资源目录即可。 资源存放 接下来，就说一下各个资源怎么去划分。在运行时，需要手动加载的资源，一般有下面这些，Prefab、图片、音频、视频、动画Clip、Animator Controller、配置数据 等，Prefab 这个不用多说。而图片，主要是UI上的一些动态的图，例如头像，或者其他一些需要根据数值，来显示不同的图。动画Clip 可以做成动态加载，也可以直接放到动画状态机中，根据实际情况决定。Animator Controller 也要根据情况决定。配置数据一般需要动态加载。而像 Prefab中用到的材质，贴图等，一般不需要我们手动加载，我们只需要加载 Prefab 即可。 这些需要动态加载的资源，我们可以放在一个父目录下，例如这个目录就叫 Prefabs，然后在 Prefabs 下面建立各个子目录，或者多级子目录来存放不同的资源。如下图 上面的图中只是大概划分了一下，每一个目录下，都可以再次建立子目录，子目录下还可以再细分子目录，具体还需要根据实际项目来划分。 上面图中的目录，是用于存放那些我们需要动态加载的资源，还有一些不需要我们动态加载的资源，例如美术同学上传的原始FBX，以及模型使用到的材质，贴图等等。对于这些资源，我们可以再建立一个目录，例如叫做 RawResources。在这个目录下，我们也需要清晰地去划分子目录，要清楚地知道哪一个目录放了什么资源，哪一些 Prefab 会引用这些资源，后面写 Bundle 打包模块时，可能会用得到。 关于 AssetBundle 问题 在打包 AssetBundle 时，Unity是可以自己处理依赖关系，例如我们可以不用管 RawResources 中的东西，只把 Prefabs 目录下的资源打包，而Prefab引用的原始资源，例如贴图，材质等，会自动打进Bundle，不需要我们手动管理。但是这样有一个问题是，对于共用的资源，会造成重复包含。看下面的图 上面的图中，两个 Prefab 引用了同一个材质，而材质，引用了一张贴图。如果我们将 PrefabA 和 PrefabB 分别打成一个Bundle，而让 Unity 自己处理依赖打包关系，那么就会出现 PrefabA 所在的 Bundle 中包含了材质和贴图，而 PrefabB 所在的 Bundle 中，也包含了材质和贴图。这样就造成了 Bundle 文件占用空间变大，在运行时，占用内存变大。...

写 Shader，到底是在做什么？Shader 就像一个拥有魔法的黑箱，我们最终从它那里得到的，是像素的颜色。而得到的是什么样的像素颜色，则取决于我们丢进黑箱里的是什么东西，以及使用的魔法咒语是什么。丢进同样的东西，使用不同的魔法咒语，得到的像素颜色也是不一样的。输入顶点的坐标，光线方向，以及自定义的颜色，使用不同的计算方式，得到的像素颜色是不一样的。使用同样的计算方式，丢进一个纯色颜色值，和丢进一张纹理，得到的像素，也是不一样的。 如果把整个 Shader 比作一个函数，那么顶点位置，自定义的颜色值，纹理，灯光等这些就相当于函数的输入参数，而 Shader 中写的各种计算，用的各种算法，都是对输入的那些参数进行操作，而最终生成的，就是颜色值，也就是相当于函数的返回值。把 Shader 想的简单一点，就是输入需要的东西，进行计算，得到像素值。 这篇博客，还是关于光照模型的，接下来我们首先总结一下常用的光照模型。 Lambert (兰伯特) 光照模型 在之前的博客中说了漫反射的实现，实现漫反射用到的模型，叫做 Lambert (兰伯特) 光照模型。Lambert 实现出来的效果，一旦入射光向量与材质表面的角度大于90度，那么得到的漫反射颜色就会全部变为黑色，没有任何明暗变化效果。 Lambert 光照模型公式: 最终颜色 = 直射光颜色 * 漫反射颜色 * max(0, dot(光源方向, 法线方向)) 其中，直射光颜色，漫反射颜色，都是我们自定义的变量。 Half Lambert (半兰伯特) 光照模型 Half Lambert 是在 Lambert 模型的基础上，做了微调，也就是将光源方向与法线方向的点乘结果，从原来[-1, 1]，映射为 [0, 1]，这样原来背光面，也会有明暗效果。 Half Lambert 光照模型公式: 最终颜色 = 直射光颜色 * 漫反射颜色 * (dot(光源方向, 法线方向) * 0.5 + 0.5) Specular (高光反射) 这里的高光反射使用了 Phone 模型，的原理很简单，想象一束光射向某个点，然后反射出去，我们的眼睛同样看向那个点，当我们的眼睛看向那个点的方向，与光线反射的方向，越接近时，进入我们眼睛的反射光则越多，也就是更亮。看下面的图 很明显，当视野方向与光的反射方向夹角越小时，也就是说进入眼睛的光越多，所以那个点也就会越亮，这就是高光反射的原理。所以高光反射，实现起来也就很简单了，只要拿到视野方向，拿到直射光的反射方向，就可以求出最终的颜色值。 Specular 光照模型公式: 最终颜色 = 直射光颜色 * 反射光颜色 * pow(max(0, dot(反射光方向, 视野方向)), 光泽度(gloss)) + 漫反射颜色 + 环境光颜色...