企业官网建设流程全解析

简介：面向刚入门Unity游戏开发或希望进行二次开发的初学者，这份压缩包内含四个可运行的Unity 3D常用实例Demo源码。四个实例分别围绕基础移动与碰撞检测、UI系统与交互、粒子特效、物理模拟与刚体动力学展开，并延伸至动画控制器、光照阴影、C#脚本、场景管理、资源加载等常见开发环节，覆盖了CharacterController、Rigidbody、Animator、Canvas、SceneManager等高频组件的真实配合方式。通过学习源码，既能理解角色移动、碰撞响应、按钮点击触发、粒子发射等功能的实现思路，也能看清完整项目的模块划分与脚本组织方式，方便后续直接改造或迁移到自己的游戏Demo中。压缩包约439KB，整体小巧精炼，便于下载后立即打开练习。目前已有2348人学习，适合想通过小案例快速上手Unity开发，或准备做二次开发的初学者认真拆解与参考。

1. 为什么Unity3d常用实例源码里，总少不了这4个Demo

实际开发里，资源站最常见的那类 Unity3d 实例源码包，标题写着“4个常用实例源码-Demo”，解压开多半是一两个场景加一堆脚本。先给结论：这类包里的4个 Demo 通常是角色控制、对象池、UI流程和存读取，覆盖了从手感到进度的完整闭环。把它们真正装进自己的工程，比下载后只开场景点两下有用得多——很多人下回来跑两圈就关了，根本原因是没搞清每个模块的适用边界和参数出处。拿到这类源码，先别急着跑。打开项目第一件事看目录结构：脚本是否按模块分目录，场景里是否每个系统都有独立入口。一个可当作判断标准的经验是：任何一个模块单独拖进新工程、连线少于15分钟，才叫“常用实例”质量。下面按这个标准逐个过，适合手头正要拼一个小游戏项目、需要一套拿来即改的 Unity3d 入门骨架的开发者。

2. 实例源码1：Unity3d角色控制与相机防遮挡Demo

2.1 为什么角色控制要选 CharacterController 而不是 Rigidbody

CharacterController 是一个依靠 Move 和 SimpleMove 驱动、自带碰撞与爬坡约束的组件，不参与物理受力计算。对第三人称主角这类“要稳定手感、不要随机物理扰动”的场景，它是首选。Rigidbody 更适合需要受力反馈的物体：被击飞、载具、布娃娃。Demo 中如果角色用 Rigidbody 写，你会发现角色踩在台阶或斜坡上时，质心抖动会直接传导给相机，最终表现出来的就是镜头晃动、难以调平。

另一个选型理由是移动方式上的差异。CharacterController 的 Move 会把碰撞检测和滑动处理都做了，而 Rigidbody 需要你自己处理速度方向和碰撞反应的叠加。在“实例源码”这个定位下，被复制到不同项目里改动的频率很高，CharacterController 写法更接近“填参数就能跑”。理解了这一点，再看下面这份脚本时就不会觉得代码繁琐，它只是把输入、重力、旋转三者按固定顺序塞进了 Move。

2.2 一套可直接挂上的角色移动和相机跟随脚本

先看角色移动，这是整个 Demo 里最容易被抄错的部分。下面这段可以直接挂到带 CharacterController 的空物体上，主相机如果没有跟随脚本，它也会自动找一下：

using UnityEngine; [RequireComponent(typeof(CharacterController))] public class ThirdPersonMotor : MonoBehaviour { [Header("移动参数")] public float moveSpeed = 5f; // 米/秒，跑步速度 public float rotateSpeed = 10f; // 旋转插值速度 public float gravity = -9.81f; // 重力加速度 private CharacterController controller; private Transform cameraTransform; private Vector3 velocity; void Start() { controller = GetComponent<CharacterController>(); cameraTransform = Camera.main != null ? Camera.main.transform : null; } void Update() { float h = Input.GetAxis("Horizontal"); float v = Input.GetAxis("Vertical"); // 以相机朝向为基准计算输入方向 Vector3 forward = cameraTransform != null ? cameraTransform.forward : transform.forward; forward.y = 0f; forward.Normalize(); Vector3 right = Quaternion.Euler(0f, 90f, 0f) * forward; Vector3 inputDir = right * h + forward * v; if (inputDir.sqrMagnitude > 1f) inputDir.Normalize(); // 重力与地面判定 if (controller.isGrounded && velocity.y < 0f) velocity.y = -2f; velocity.y += gravity * Time.deltaTime; // 位移：水平方向 + 垂直重力 controller.Move(inputDir * moveSpeed * Time.deltaTime + velocity * Time.deltaTime); // 面朝输入方向，用 Slerp 做平滑转向 if (inputDir.sqrMagnitude > 0.01f) { Quaternion targetRot = Quaternion.LookRotation(inputDir); transform.rotation = Quaternion.Slerp(transform.rotation, targetRot, rotateSpeed * Time.deltaTime); } } }

这里的关键逻辑是把输入方向从“世界的 X/Z 轴”换成“相机的右方和前上方”。否则玩家按 W，角色只会冲向世界坐标的 Z 正方向，镜头一转就乱套。Quaternion.LookRotation(inputDir)会把角色模型的正面朝向输入方向，Slerp的作用是让转向不是瞬切而是带阻尼的转动，rotateSpeed越大，转向响应越快。

相机跟随这段建议在 LateUpdate 里写。因为 Update 里角色可能刚从旧位置移动到新位置，LateUpdate 能保证所有物理和角色逻辑完成后，相机再取最终位置，绝大多数相机抖动都源于这一步写错：

using UnityEngine; public class FollowCamera : MonoBehaviour { public Transform target; public float distance = 5f; public float height = 2f; public float smooth = 8f; public float collisionRadius = 0.2f; public LayerMask obstacleMask = ~0; // 会被当遮挡物的层 private Vector3 smoothVelocity; void LateUpdate() { if (target == null) return; Vector3 targetPos = target.position + Vector3.up * height; Vector3 back = -target.forward; float currentDistance = distance; // 用球体射线从角色头顶向镜头方向探测，命中则把距离压缩到碰撞点 if (Physics.SphereCast(targetPos, collisionRadius, back, out RaycastHit hit, distance, obstacleMask, QueryTriggerInteraction.Ignore)) { currentDistance = hit.distance - 0.1f; } Vector3 nextPos = targetPos + back * currentDistance; // SmoothDamp 比 Lerp 更顺滑，smooth 越小跟随越“重” transform.position = Vector3.SmoothDamp(transform.position, nextPos, ref smoothVelocity, 1f / smooth); transform.LookAt(targetPos); } }

SphereCast的起点在角色头顶，方向朝镜头后方。命中遮挡物时，hit.distance表示从起点到墙面的距离，用它减去 0.1 米防止相机与墙面穿模。collisionRadius值越大，相机越容易在门缝、窄走廊里提前拉近，通常 0.2 到 0.4 之间比较合适。

2.3 让遮挡物材质透视：相机被墙挡住时自动半透明

球体探测只能把相机拉近，解决不了“角色在墙后面看不见”的问题。常见做法是命中墙面时把遮挡物材质切到透明通道，术语上常叫作“材质透视”或“上层穿透看见下层”。下面这段做了一件看起来很聪明、但实际操作必须谨慎的事：

private Dictionary<Renderer, Material[]> backup = new Dictionary<Renderer, Material[]>(); public void FadeOut(Renderer renderer) { if (backup.ContainsKey(renderer)) return; // 注意：materials 会为当前 Renderer 生成材质实例，不会污染项目里的共享材质 backup[renderer] = renderer.materials; foreach (Material mat in renderer.materials) { // URP Lit 材质：切到透明表面类型，再调 renderQueue 和 Alpha mat.SetFloat("_Surface", 1f); mat.SetOverrideTag("RenderType", "Transparent"); mat.renderQueue = 3000; mat.EnableKeyword("_SURFACE_TYPE_TRANSPARENT"); Color c = mat.color; c.a = 0.35f; mat.color = c; } }

备份字典是必要的。只要相机离开遮挡区域，就应该把Renderer.materials恢复成原状态，如果直接改sharedMaterial，场景里所有用同一颗材质球的物体都会跟着变透明。角色身上的布料、半透明特效，还需要在obstacleMask里手动排除，不然 FadeOut 会把敌人、NPC 全变透明。

2.4 角色控制实例的参数对照表与两个典型坑

典型坑一：obstacleMask = ~0会把角色自己也当成遮挡物。角色身上的碰撞体和裙摆、武器碰撞都会触发 SphereCast，导致镜头距离被错误压缩。一般给角色单独建一个Player层，然后在 Inspector 里把obstacleMask勾选为Everything再手动去掉Player层。

典型坑二：角色在斜坡上时，controller.isGrounded返回 true 但下滑严重。这是因为 character controller 的slopeLimit默认为 45 度，超过会判定为斜坡。拿到的实例包如果处理不好这块，可以在控制器上直接把slopeLimit降到 30，把stepOffset保持在 0.3 米左右。

3. 实例源码2：Unity3d对象池Demo——高频生成与回收的标准写法

3.1 什么时候该用：看 Instantiate 频次而不是场景复杂度

很多初学者觉得“我场景里总共才50个敌人，用不上对象池”。真正决定要不要池化的指标是单位时间内的 Instantiate/Destroy 次数。每生成一个 GameObject，Unity 要分配托管对象、触发 OnEnable、初始化 Transform 层级；每销毁一个，又要触发 OnDisable 和 OnDestroy，还产生 GC 压力。子弹飞行类 Demo 里，一秒打出 15 发、每发存活 2 秒，峰值就是 30 个活跃物体加 30 次待回收的克隆体，频繁创建销毁时主线程就会周期性卡顿。

对象池的处理思路是把“创建/销毁”换成“从池里取/放回池里”。物体反激活时不真正释放内存，只是临时隐藏。这样免去了构造函数、OnEnable/OnDisable 反复执行的消耗，也避免了创建时触发阴影、烘焙等引擎内部逻辑的开销。

3.2 一个不依赖第三方插件的通用 GameObjectPool

常见做法是写一个最朴素的队列池，不用 Addressables 也能跑。把它挂到场景里任意空物体上，prefab 拖到 Inspector 上就能用：

using System.Collections.Generic; using UnityEngine; public class GameObjectPool : MonoBehaviour { [Header("池参数")] public GameObject prefab; public int prewarmCount = 10; // 启动时预热数量 public int maxCount = 50; // 允许同时活跃的最大数量 private Queue<GameObject> pool = new Queue<GameObject>(); void Start() { for (int i = 0; i < prewarmCount; i++) { GameObject go = Create(); go.SetActive(false); pool.Enqueue(go); } } public GameObject Get(Vector3 position, Quaternion rotation) { if (pool.Count == 0 && transform.childCount < maxCount) pool.Enqueue(Create()); if (pool.Count == 0) return null; // 已达上限，宁可不出也不卡顿 GameObject go = pool.Dequeue(); go.transform.SetPositionAndRotation(position, rotation); go.SetActive(true); return go; } public void Release(GameObject go) { if (go == null || !go.activeSelf) return; // 防止重复回收 go.SetActive(false); pool.Enqueue(go); } private GameObject Create() { GameObject go = Instantiate(prefab, transform); return go; } }

释放时先判断!go.activeSelf，这个防御能挡住大部分“打了一半报错说对象已销毁”的问题。transform.childCount < maxCount是简单的容量上限判断，超过后Get直接返回 null，调用方要自己处理空引用，这是刻意为之：把“子弹超出上限该往哪打”留给业务层决定，而不是池子默默吞掉。

3.3 对象池参数怎么调：预热数量、上限、回收时序

预热数量不要拍脑袋填。先在游戏里跑一场完整的战斗，观察 Profiler 中某个瞬间活跃物体数量的峰值，然后以峰值作为 prewarmCount。如果写的是敌人刷新逻辑，还需要把释放时机和敌人死亡动画绑定，死亡动画播完再回收，否则会出现敌人刚倒地就消失的穿帮。

3.4 把对象池接进 Demo 的推荐挂法与热更新注意

对象池直接挂在一个名为_PoolRoot的空物体上，池内所有对象都会作为它的子节点。游戏运行时打开 Hierarchy 面板，把_PoolRoot展开就能看到哪些对象是活跃的、哪些是隐藏的，比断点调试直观得多。这一步对排查“为什么对象没出现”“为什么对象不消失”非常有效。

还要提一个容易踩的场景：如果是从网上拿到的 minecraft 风格的 demo，高频方块生成改造时，很多人会把Instantiate直接替换成pool.Get，却忘了方块被破坏时仍然走的Destroy。这会导致池里永远空着，内存还是持续泄漏。正确做法是把方块的破坏逻辑里Destroy(gameObject)改成pool.Release(gameObject)，发射点和回收点必须成对出现。

4. 实例源码3：Unity3d UI 与流程管理的 Demo 状态机

4.1 UI 面板直接 enable/disable 的问题

小游戏项目里最容易失控的就是 UI 面板：开始界面、暂停界面、结算界面各挂一个脚本，互相用public GameObject引用。前两个面板这样写没问题，一旦加了暂停功能就出事。

问题集中在三处。一是Time.timeScale = 0后，如果玩家直接关闭暂停面板，忘了把 timeScale 恢复回去，角色会永远静止，而这类 bug 极难在第一次运行时就发现。二是多个面板同时引用同一个按钮事件，比如菜单里的开始按钮和暂停里的继续按钮都要切场景，逻辑分散后容易点错。三是 UI 界面之间互相等待，菜单要等 SettingPanel 的返回值，SettingPanel 又要等菜单关闭，一旦顺序不对就死锁。

4.2 GameFlow 单例与状态切换

常见做法是单独写一个 GameFlow 单例，把游戏状态收敛到一组枚举上，所有 UI 都只响应状态变化，不直接互相调用。下面这个是经过简化但结构完整的版本：

using UnityEngine; public enum GameState { Menu, Playing, Paused, GameOver } public class GameFlow : MonoBehaviour { public static GameFlow Instance; public GameState State { get; private set; } public int Score { get; private set; } public float PlayTime { get; private set; } public event System.Action<GameState> OnStateChanged; void Awake() { if (Instance != null && Instance != this) { Destroy(gameObject); return; } Instance = this; DontDestroyOnLoad(gameObject); SetState(GameState.Menu); } void Update() { if (State == GameState.Playing) PlayTime += Time.deltaTime; } public void SetState(GameState next) { if (State == next) return; // 退出前把 timeScale 恢复，避免从暂停直接回主菜单卡死 if (State == GameState.Paused) Time.timeScale = 1f; State = next; if (next == GameState.Playing) Time.timeScale = 1f; else if (next == GameState.Paused) Time.timeScale = 0f; OnStateChanged?.Invoke(State); } public void AddScore(int points) { Score += points; // 分数变化可以走单独的事件，UI 按需订阅 } }

DontDestroyOnLoad在这里是因为从主菜单切到游戏场景时，GameFlow 不能被卸载。注意Awake中已经做了单例去重，场景切回来时旧的 GameFlow 会被销毁，新场景里再放一个即可。Time.timeScale统一在 SetState 内部处理，外部任何脚本都不应该直接修改 timeScale，这是整个 UI 状态机能稳定运行的前提。

4.3 事件总线让 UI 与玩法解耦

把 GameFlow 与 UI 解耦的常见做法是加一个轻量的事件中心。它不做复杂的消息路由，只保存两个 C# event：

public static class GameEvents { public static System.Action<GameState> OnStateChanged; public static System.Action<int> OnScoreChanged; public static void RaiseStateChanged(GameState state) { OnStateChanged?.Invoke(state); } public static void RaiseScoreChanged(int score) { OnScoreChanged?.Invoke(score); } }

然后在 GameFlow 的SetState里调用GameEvents.RaiseStateChanged(State)而不是直接在 GameFlow 内去操作 UI。UIManager 在 OnEnable 时订阅事件，在 OnDisable 时退订，这一步必须成对，否则场景销毁后 UI 依然在响应事件会报 MissingReferenceException：

public class UIManager : MonoBehaviour { public GameObject menuPanel; public GameObject gamePanel; public GameObject pausePanel; void OnEnable() { GameEvents.OnStateChanged += HandleStateChanged; } void OnDisable() { GameEvents.OnStateChanged -= HandleStateChanged; } private void HandleStateChanged(GameState state) { menuPanel.SetActive(state == GameState.Menu); gamePanel.SetActive(state == GameState.Playing || state == GameState.Paused); pausePanel.SetActive(state == GameState.Paused); } }

把三个面板的显隐整合到一个方法里，优势是状态切换时只需要关注这一个方法的状态判定逻辑。以后新增一个设置面板，只需要加一行settingsPanel.SetActive(state == GameState.Menu)，不会影响其他界面。

4.4 状态转换表与验证用的日志

写进调试期日志很方便，可以直接在 SetState 里临时扔一条：

Debug.Log($"[GameFlow] {State} -> {next}");

观察日志里状态是否出现跳跃，比如Menu -> GameOver，那就说明有脚本绕过开始按钮直接改了状态，通常是新手直接在 Button 的 OnClick 里写FindObjectOfType<GameFlow>().State = GameState.GameOver造成的。只要所有切换都走 SetState，这种问题从一开始就不会存在。

5. 实例源码4：Unity3d 存读取 Demo——从 PlayerPrefs 到 JSON 存档

5.1 PlayerPrefs 能用多久，什么时候必须换

PlayerPrefs 是 Unity 自带的键值对存储，写法和读取都很简单，但它有三个硬限制：只支持 int、float、string 三类基本值；不适合存复杂结构，硬要存会把对象拼成字符串再解析；没有版本概念，游戏更新后旧存档缺字段会直接读崩。

所以需要把“配置写入”和“进度写入”分开。音量、画质等级、语言这些单项配置继续用 PlayerPrefs，角色等级、通关进度、背包物品这类复杂数据必须换成文件存档。文件存档的另一个好处是方便调试：打开电脑上对应目录就能看到 JSON 明文内容，手动改一档数据再启动游戏，也比在 Unity 编辑器里反复操作 UI 快得多。

5.2 一份 JSON 存档读写：可读、可改、可回滚

JsonUtility 是 Unity 内置的 JSON 序列化类，性能不如第三方库 Newtonsoft.Json，但零依赖，合适做 Demo 存档。下面这份结构把 SaveData 和 SaveManager 拆开：

using System; using System.IO; using UnityEngine; [Serializable] public class SaveData { public int version = 1; public string playerName = "Player"; public int highestScore = 0; public int level = 1; public float playTime = 0f; public string checkPoint = "Level1_Start"; }

再写管理类：

public class SaveManager : MonoBehaviour { private static string SavePath => Path.Combine(Application.persistentDataPath, "save.json"); public static void Save(SaveData data) { string json = JsonUtility.ToJson(data, true); File.WriteAllText(SavePath, json); } public static SaveData Load() { if (!File.Exists(SavePath)) return new SaveData(); string json = File.ReadAllText(SavePath); SaveData data = new SaveData(); JsonUtility.FromJsonOverwrite(json, data); // 简单兼容：旧档缺字段时补默认值 if (data.version < 1) { data.checkPoint = "Level1_Start"; data.version = 1; } return data; } }

Application.persistentDataPath在不同平台上指向不同目录，Windows 上一般是C:\Users\用户名\AppData\LocalLow\公司名\产品名，所以保存/读取都不要拼接绝对路径。JSON 文件的好处是可直接用记事本打开，改highestScore后重进游戏，就能省掉“反复打完整一关看结算”的验证时间。

5.3 版本号字段与 Editor 调试入口

version字段看似多余，实际上是存档第一道防线。数据表加列时，旧存档读取后走if (data.version < 2)补默认值，用户进度不丢。如果结构变化太大，还能走“旧档备份、新档重建”的兜底路线：

[ContextMenu("清空存档")] private void ResetSave() { File.Delete(SavePath); PlayerPrefs.DeleteAll(); Debug.Log("存档已清空"); }

[ContextMenu]会把“清空存档”直接加到 Inspector 组件的右键菜单里，在编辑器里一键重置，不需要每次手动去目录里删文件。这个方法不应该出现在正式包里，正式包可以用一个隐藏的“长按标题10次”彩蛋当作重置入口。

5.4 存档内容别放资源：材质球、视频流与配置分离

存档里只保存“值”，不保存“资源引用”。对应到实际做法：PBR 材质球、贴图、视频流这类资产，不能把Material对象或文件路径硬编码进存档。存档里存一个标识，比如"environment": "desert"，运行时再去资源系统里加载对应的材质球资产包或视频流地址。

网上常见的 unity3d 常用材质球资产包、PBR 材质下载，下载下来会有几十颗材质球。正确姿势是给每种场景一个字符串 tag，加载时用 Addressables 或 Resources.Load 按 tag 找资源。这样用户换了材质球、更新了视频文件，存档完全不用动。UI 设置里的音量、语言这类偏好继续留在 PlayerPrefs，存档文件只负责游戏进度。

6. 四个 Unity3d Demo 合体成一套小游戏脚手架：验证与收尾技巧

6.1 最小合体顺序和验证清单

四个模块合进新工程时，建议按“对象池 → 存档 → GameFlow → 角色控制”的顺序。先把对象池挂进场景，确认子弹生成和回收正常；再挂 SaveManager，让角色死亡后能够回档；接着放 GameFlow 和 UIManager，接好开始、暂停、结算三个界面的按钮；最后才把角色控制和相机脚本挂到玩家身上。每接一个模块跑一次，出问题的时间能缩到最短。验证清单只需要三行：能跑、能存、能恢复。进入游戏后走完“开始-暂停-继续-死亡”，然后File.Delete存档路径下的 save.json 再重进，确认能回到初始状态，这套脚手架就算立住了。

6.2 用 Profiler 和 Frame Debugger 做快速体检

合体后先打开主菜单 Window 下的 Profiler，切到 CPU Usage 面板，跑 10 秒战斗流程，重点看 GC Alloc。如果检测到频繁的 Instantiate 和 Destroy，说明还有代码绕过了对象池，在堆栈里找到调用点改掉。逐帧检查时可以配合 Frame Debugger，它能按绘制顺序列出所有 Draw Call，能直接看出相机 FadeOut 的透明材质是否触发了额外的渲染批次。给四个模块的关键函数加上Profiler.BeginSample和EndSample，性能数据就能直接定位到具体模块：

Profiler.BeginSample("GameObjectPool.Get"); GameObject go = pool.Get(pos, rot); Profiler.EndSample();

6.3 交付前清缓存与跨端导出

交付测试包之前，处理三件事：在构建设置里关掉 Auto Graphics API，避免部分设备上的图形特性差距；把开发构建的UNITY_EDITOR预编译开关保留下来的调试日志关掉；清空persistentDataPath和 PlayerPrefs，确保测试人员拿到的是全新状态。如果目标平台是鸿蒙或手机端，Unity 工程导出时可以按目标平台切 Build Target，常见做法是先用当前编辑器导出一个可运行的 Windows 包验证核心逻辑，再切 Android/HarmonyOS 导出对应产物。HarmonyOS NEXT 的 Unity 适配链路已经能直接产出 hap 包，团队内部习惯把公共代码拆成 hsp 动态共享包和 har 静态库，Unity 侧的 C# 业务脚本不需要为这三种后缀改逻辑。导出后用测试机跑一遍暂停、存读取、对象池大量生成那几步，确认没有平台相关的 API 差异，四个实例源码到这一步才算真正落地成了你自己的脚手架。

本文还有配套的精品资源，点击获取