企业官网建设流程全解析

写在前面：我是Vibe Gaming的唯一成员，也就是老板、策划、程序、美术、测试和市场都长在我一个人身上的那种"一人工作室"。过去八个月，我从零做了一款微信小游戏，从立项、开发、接入微信能力到正式上线，踩过的坑比玩过的消消乐关卡还多。这篇东西不是来教谁做爆款的，而是把我一个人怎么把这摊事扛下来的真实过程、选型逻辑和能直接照抄的细节全部写出来。想认真做微信小游戏开发的独立开发者、想转型做小游戏的前端朋友，或者纯属好奇一个人怎么干一个团队活的，都可以看完。

在开始写技术细节之前，我先说一句可能不太好听的话：一人工作室最缺的永远不是时间和代码能力，而是判断力。判断做什么玩法、判断做到多简单能上线、判断哪些工作必须自己花钱外包、判断哪些数据看了也是白看。后面的所有章节，本质上都是在讲"判断"这两个字。

1. 立项：一个人的游戏工作室，选赛道比努力更重要

如果你已经决定要做微信小游戏开发，开工前第一件事不是打开引擎，而是把"我要做一个什么样的游戏"这个问题用一百个字写清楚。写不清楚，后面一定会失控。

1.1 为什么微信小游戏适合单人开发

微信小游戏在2024年其实早就不是蓝海，但也不是红海，更像是一片有暗流的湖。说它适合单人，核心原因有三个。第一是分发逻辑变了，微信的社交关系链让"小而美"的游戏有机会通过分享、群聊、排行榜获得自然量，而不是像App Store那样完全依赖编辑推荐和买量。第二是技术门槛刚刚好，Cocos Creator这类引擎把99%的兼容性和包体问题都处理掉了，一个人用TypeScript就能写出完整的游戏逻辑。第三是变现路径很短，从激励视频广告到虚拟支付，官方后台点几下就能接入，不需要开发者自己搭支付系统。

但"适合单人"不等于"随便做都能活"。微信用户的时间高度碎片化，用户对一款新游戏的平均耐心大概只有三到五分钟。这意味着你的核心玩法必须在这三分钟内传达出去，否则用户就划走了。休闲益智、模拟经营、轻竞技，这三个大方向是单人团队最容易做出成绩的，因为它们对美术资源的依赖相对低，对玩法机制的依赖相对高，而玩法恰好是一个人靠脑子和代码就能反复打磨的东西。

1.2 玩法定位：把一个"有意义的决定"做到极致

我见过很多独立开发者立项时喜欢说"我的游戏有Roguelike、有合成、有塔防、有剧情"。听起来很丰富，但对一个人来说，这等于同时挖四个井，每一个都挖不深。我给自己定了一个铁律：核心玩法只能有一个，所有系统都围绕它服务。

我的第一款游戏定位是轻量休闲消除，名字叫"像素叠叠乐"。核心循环用一句话讲就是：从三种颜色的方块中拖出一个放到网格上，三个以上同色方块连在一起就消除。听起来简单吧？但就这个玩法，我花了整整两周做原型和调整手感，让拖拽跟手、吸附反馈清晰、消除判定不会误触。真上线后数据最惊艳的反而是一个不起眼的细节——方块落点前的"预览虚影"，它让玩家不用反复试错，直接减少了15%的无效点击，也提升了留存。

这里想传达的经验是：不要一上来就设计复杂的成长线。你先做一个不用任何引导玩家就会玩的版本，放到朋友群里让他们试玩。如果大家能在没有教程的情况下撑过三分钟并主动说"再来一把"，核心循环就算成立了。如果做不到，别加功能，先改手感。

1.3 市场调研：别只看畅销榜，要盯着用户骂什么

立项前我花了一周时间，把微信小游戏榜、抖音小游戏榜前一百名都过了一遍，重点不是看谁火，而是看评论区。玩家骂"广告太多了"的游戏，说明它的留存可能是靠广告换来的；骂"卡死了"的游戏，说明性能优化有空间；骂"玩法跟XX一模一样"但还在玩的人，说明这个品类有真实需求，只是没有替代品。这是我判断要不要做某个方向的最重要依据。

一个人做市场调研不需要密密麻麻的Excel表，只需要回答三个问题：这个玩法类型里的头部产品有哪些？它们的软肋是什么？我做的版本能解决其中哪怕一个软肋吗？如果答案都是肯定的，就可以动手了。至于"这个方向未来会不会火"，那不是一个人该赌的事。先把眼前这一款做上线，比什么都强。

2. 技术选型：哪个引擎能让你一个人活下来

技术选型这件事，最容易踩的坑是"技术洁癖"。很多人选引擎时在意渲染管线和社区热度，却忘了前提是：你要在三个月内上线一款小游戏，而不是做一个3A大作。我最终选了Cocos Creator 3.8，理由很简单：它和微信小游戏开发环境的配合度最高，而且我一个人写的TypeScript代码既能跑在微信里，也能在浏览器模拟器里调试。

2.1 主流引擎在小游戏场景下的横向对比

先把观点放前面：没有完美的引擎，只有合不合适自己的场景。下面这张表是当时我的对比维度，仅供参考，具体版本以官方文档为准。

我自己其实是从Unity转过来的。不是Unity不好，而是用Unity做硬核单机和PC游戏很顺手，但一旦面向微信小游戏，那个包体体积和JIT问题就会让你抓狂。很多Unity开发者做了一个炫酷的Demo，结果构建出来主包十几M，连审核体积限制都过不了，还得回头砍资源，这个过程非常消耗一个人仅有的精力。

2.2 我推荐的工程基础配置

选完引擎，接下来就是把工程环境稳定下来。一个人最忌讳的是"把所有东西都放到脑子里"，哪怕你记忆力再好，三个月后也会忘记半个项目当初为什么这么写。我的工程基础分为四层：

• 代码管理：Git + 远程私有仓库，每次改动一个功能就提交一次，提交信息里注明"改了什么、为什么改"，而不是"更新"。
• 场景管理：用Cocos Creator的Prefab拆分子模块，不要把所有节点都堆在一个场景里，否则协作时你自己都会迷路。
• 资源管理：所有美术资源集中放在assets/resources目录下，通过动态加载加载，而不是把图片直接挂在场景上。这样后期做分包和热更会轻松很多。
• 开发工具：VS Code + TypeScript，配合微信开发者工具作为真机模拟调试点。我会在VS Code里写代码，在微信开发者工具里看运行日志，两边热重载配合起来，一个人也拥有了"多人协作"的效率。

顺便说一下编辑器版本选择。Cocos Creator的3.x大版本之间，项目结构迁移有时会发现很多废弃API。如果你和我一样是单人开发者，尽量在项目中期不要轻易升级引擎版本，除非有官方修复了致命Bug。稳定优先于新功能，这是一个人保住开发节奏的底线。

3. 核心玩法开发：从"像素叠叠乐"看最小可行产品怎么落地

这个章节是干货最密集的部分，我尽可能按真实开发顺序来拆解。不要被"像素叠叠乐"这个名字误导，它只是我给项目起的代号，实际成品是一个方块消除休闲游戏。

3.1 从空场景到第一个可玩版本：模块划分

第一版工程里，我连一张美术图都没有，全部用Cocos Creator内置的Graphics组件画方块。这样做是为了逼迫自己先把玩法逻辑跑通，避免陷入调UI漂不漂亮的泥潭。我把游戏拆成了三个核心模块：网格管理、输入控制、消除判定。

网格管理负责维护一块N行M列的二维数组，数组中每个格子可能为空，也可能存着一个方块的类型ID。输入控制负责把玩家的点击或拖拽坐标转换成网格坐标，并触发方块放置。消除判定负责在每次放置后检查是否形成三个及以上同色连线，然后标记、消除、下落补位，循环检查直到无法消除。

这套逻辑不复杂，但有一个关键点：不要把所有状态裸放在全局变量里。我定义了一个GameState类，专门保存当前网格、当前得分、当前可用方块类型。后续无论是做撤销、做重开、做存档，都只需要序列化这个类的实例。这个设计让我在后来的调试中省了大量时间，比如玩家反馈"死局了还得手动重开"，我直接在游戏结束界面加一个"检测无可用移动并自动重排"的功能，改起来非常快。

3.2 坐标转换与拖拽反馈：一个人也要讲究手感

微信小游戏里的触摸事件拿到的是屏幕坐标，而方块需要落在一个逻辑网格上，所以第一步是把屏幕坐标转成网格坐标。这一步看似简单，实际跑起来却会碰到坐标系不一致的问题。Cocos Creator的节点坐标是相对于父节点的，触摸事件是UI坐标，需要先用uiTransform.convertToNodeSpaceAR转成相对棋盘节点的坐标，再去计算落在第几行第几列。

这是坐标转换的简化版本：

// 把触摸点转换到棋盘节点下的网格坐标 function touchToGrid(touchPos: Vec3, boardNode: Node, gridSize: number): {x: number, y: number} { const boardUI = boardNode.getComponent(UITransform)!; const local = boardUI.convertToNodeSpaceAR(touchPos); const gx = Math.floor((local.x + boardUI.width / 2) / gridSize); const gy = Math.floor((local.y + boardUI.height / 2) / gridSize); return { x: gx, y: gy }; }

但坐标转换只能告诉你"手指在哪一格上"，真正决定手感的是拖拽过程中的视觉反馈。我在方块拖起来时做了三件事：方块随触点上移三分之一，目标格高亮显示，如果目标格非法则显示红色描边。这些反馈全部是瞬时的，不搞任何渐变动画。玩家要的是"我能不能放这里"的清晰答案，而不是一段流畅的旋转效果。

3.3 消除判定的完整实现思路

消除逻辑是所有消除类游戏的心脏。很多新手会写"检查每个格子周围有没有同色"这种递归算法，但递归在大网格上性能不好，而且容易写出死循环。我的做法是线性扫描，性能稳定且易于理解。

核心思路是：每次放置完方块后，先横向遍历每一行，找出所有水平方向连续>=3个同色块的格子，标记为待消除；再纵向遍历每一列，找出所有垂直方向连续>=3个同色块的格子，也标记为待消除。标记完成后统一消除，然后让上方的方块下落，补上空位，再重新扫描，直到某次扫描没有任何可消除的组合。

function findAllMatches(grid: number[][]): boolean[][] { const rows = grid.length; const cols = grid[0].length; const matched = Array.from({ length: rows }, () => new Array<boolean>(cols).fill(false)); // 水平扫描 for (let r = 0; r < rows; r++) { let start = 0; for (let c = 1; c <= cols; c++) { if (c === cols || grid[r][c] !== grid[r][start]) { if (c - start >= 3) { for (let i = start; i < c; i++) matched[r][i] = true; } start = c; } } } // 垂直扫描同理，这里省略 return matched; }

需要注意，同类游戏里会有"两个方向同时匹配到同一个方块"的情况，上面的布尔矩阵天然支持去重。标记完成后直接遍历matched，把所有为true的格子置空，再做下落和补位。补位时新方块从上往下掉，但不要真的让大量节点各做一堆位移动画，否则后续查询节点位置会非常麻烦。我最终实现的是"逻辑层先立刻刷新二维数组，视图层再用差分动画播放"，这样逻辑和表现解耦，测试时可以直接跳过动画快速验证。

3.4 难度曲线设计：简单，但要有挑战感

玩法通了以后，最容易被忽视的是难度曲线。如果一直随机生成三种颜色，高玩会觉得无聊，萌新会觉得眼花。我总结了一个适合单人项目的思路：前五关只用两种颜色，让玩家无压力上手；从第六关开始，每过五关增加一种颜色，同时降低新方块生成时连续出现同色的概率，避免一上来就是死局。这个曲线不是拍脑袋定的，而是我拿自己的试玩数据反复调的，前后改了十几版。

另一个重要的设计是"容错机制"：当系统检测到当前棋盘已经没有可消除的组合，就自动洗牌重排。这个功能既能让玩家觉得"系统很贴心"，又能避免因为规则设计失误导致的无解死局。实现时只需要遍历所有空位和所有可能的放置位置，检查是否能形成三连，如果不能，就触发洗牌动画。

4. 平台接入：微信登录、分享、广告和绕不开的合规配置

游戏本身做完，只相当于完成了一半，另一半是让游戏在微信这个平台里顺利运行并通过审核。这段经历的坑尤其多，我一个个拆开说。

4.1 登录与用户标记：先别急着弹授权

微信小游戏允许用户匿名游玩，但如果你想做排行榜、存档跨设备同步，就需要拿到用户的唯一标识。最经典的做法是用wx.login得到的code，通过云函数换取openid，再把这个openid作为玩家身份存储到云数据库里。注意，不要在新手引导阶段就强制用户点击"授权头像昵称"按钮，现在微信的隐私保护要求越来越严格，而且弹窗本身会打断游戏节奏，造成大量流失。

我的实际做法是：玩家进入游戏后走游客模式，只有在点击排行榜或尝试保存云端存档时，才引导用户点击"微信用户信息授权"按钮。这个调整让新用户的首日留存提升了大约8%，因为减少了一次极其容易引起反感的授权弹窗。

4.2 开放数据域：好友排行榜的正确姿势

微信小游戏的好友排行榜必须写在"开放数据域"里，它是独立于游戏主域的一个JavaScript环境，不能直接访问主域的逻辑。很多新手在这卡很久，其实核心要点就两个：主域通过wx.setUserCloudStorage把玩家分数写入托管数据；开放数据域通过wx.getFriendCloudStorage获取好友分数并渲染排行榜。开放数据域里只能操作sharedCanvas，不能碰主域的节点和场景。

如果你用Cocos Creator，主域和开放数据域是分开构建的，然后在开放数据域里使用官方提供的适配层。做排行榜时我建议只展示前50名和我的名次，不要搞复杂UI，因为开放数据域的渲染性能有限，节点一多真机会掉帧。

4.3 分享与回流：让玩家愿意主动分享，而不是被骗分享

分享是微信小游戏的天然优势，但也是最容易被平台盯上的地方。我第一次提交审核就因为在分享文案里写了"不分享就玩不了下一关"这种诱导性话术，结果被拒了。后来我把分享奖励改成"分享后获得一次额外道具"，并且完全由玩家主动点击，不阻断关卡流程，才顺利过审。

实际做下来我觉得，最健康的分享设计是给分享赋予"社交对比属性"。我做了"分享你的周报"功能：每周日晚生成一张包含玩家本周消除数量、最强连锁、好友排名的图片，玩家觉得好看、有面子，自然愿意发到群里。这一招获得的分享回流率比"分享得钻石"高出不少，而且更容易被用户接受。

4.4 广告接入：激励视频不是骚扰，而是玩法的一部分

做休闲小游戏不接广告，基本等于用爱发电。微信提供了Banner、插屏和激励视频三种主流广告形态。我的唯一选择是激励视频：玩家复活时看广告，游戏结束时看广告翻倍分数，关卡失败时看广告获得一次洗牌机会。全程不在游戏过程中强制弹任何插屏广告，因为插屏对留存伤害太大，单人游戏一旦留存崩了，后面怎么拉都拉不回来。

接入激励视频其实很简单：在微信公众平台创建广告位拿到广告位ID，然后在代码里创建RewardedVideoAd实例，监听onClose事件判断是否完整看完。这里有一个非常容易被忽略的坑：广告的onClose回调在用户中途关闭时也会触发，必须通过res.isEnded字段判断是否完整播放，否则会被玩家刷翻倍奖励。

const ad = wx.createRewardedVideoAd({ adUnitId: 'xxxx' }); ad.onClose((res) => { if (res && res.isEnded) { // 完整观看，发放奖励 grantReward(); } else { // 中途关闭，不发奖励 } });

4.5 合规配置：这些不做，审核等待期会让你怀疑人生

你可能觉得游戏做完了直接上传代码就能过审，但微信平台现在非常看重隐私合规。首次提交审核前，务必在公众平台后台完成《用户隐私保护指引》的配置，明确说明你收集了哪些信息、用于什么目的。特别是如果你用了云开发数据库存储用户的openid，就要在隐私指引里列出"用户标识信息"。

另外还需要注意素材合规，包括游戏名称不能蹭热门IP，图标不能带诱导性文字，截图中不能出现未接入的平台logo。这些细节我都在一次漫长等待中亲身经历过。花一个下午把这些整理好，比上线后收到整改通知再手忙脚乱要强得多。

5. 包体与性能：决定留存和口碑的生死线

微信小游戏对包体大小极其敏感。主包体积如果过大，加载白屏的时间就会成倍增加，而这期间用户随时可能划走。我的原则是：主包只放必须的核心代码和首屏UI，其他内容全部拆到分包或CDN。

5.1 包体控制：把"大不了放进去"换成"真的需要吗"

微信小游戏对主包体积向来卡得很死，我记得常见限制是4M，具体数值以微信公众平台后台显示为准。最初我把美术素材、音频、多语言文案全部塞进resources，构建完一看主包8M，直接被警告。后来我做了三件事：

• 把所有图片用TexturePacker打成图集，并统一用WebP格式，体积能省40%到60%。
• 音频全部转成低比特率M4A，背景乐控制在1M以内，音效控制在100K以内。
• 把游戏内教程、后续关卡、节日活动资源全部拆到分包里，通过wx.loadSubpackage按需加载。

这套组合拳之后，我的主包降到了3M以内，首屏从4秒降到2秒以内，留存肉眼可见地上升。

5.2 资源异步加载：不要在启动时把所有东西都加载完

一个人写代码时最容易犯的错误是"懒得起异步流程"，于是就让启动场景把所有资源都挂上去。这会导致启动时网络请求一大堆，加载进度条卡在70%很久。正确做法是：启动场景只加载核心棋盘UI和最基础的方块纹理；进入主菜单后再预加载下一步需要的资源；进入具体关卡时再加载关卡专属资源。

用Cocos Creator的resources.load按需加载就够了。我还在启动场景里放了一个假的进度条，但实际上是按已加载资源数量动态计算的，这样玩家不会因为进度条不动而流失。

5.3 渲染性能：减少节点比优化drawcall更直接

对于休闲小游戏，性能瓶颈通常不在GPU，而在CPU，尤其是节点的创建、销毁和遍历。我的屏幕上有最多上百个方块，如果每次消除都销毁节点再新建节点，帧率会有肉眼可见的卡顿。

解决思路是对象池。在游戏启动时预先创建一批方块节点存入对象池，消除时把方块"移到屏幕外"并隐藏，需要时再从中取出来复用。这个改动让游戏在低端安卓机上的帧率从35帧提升到55帧左右，效果非常明显。另一个容易被忽略的点是避免遍历时使用getChildByName，这个方法内部会遍历所有子节点，一帧里调用几十次就是灾难。我会在初始化时把子节点引用缓存到一个数组里，后续都用索引访问。

5.4 用真机性能面板验证，而不是用模拟器自嗨

很多性能问题在微信开发者工具里完全看不出来，一上真机就原形毕露。我的习惯是每完成一个功能就把游戏跑在安卓和iOS各一台低端机上，打开微信开发者工具的vConsole和性能面板，观察CPU占用和内存变化。如果发现某段逻辑导致CPU飙到70%以上，我会立刻定位是动画、物理还是渲染问题。单人开发容易高估模拟器的性能表现，所以必须坚持真机验收。

6. 运营视角：一个人如何用数据驱动迭代

游戏不是开发完就结束了，恰恰相反，上线才是开始。一个人做运营，最忌讳的是"我觉得玩家喜欢什么就改什么"，必须有数据支撑。但一个人也没那么多精力做复杂的BI系统，所以我用了一套极简的埋点方案。

6.1 轻量埋点：不花一分钱也能看漏斗

我的需求很简单：知道每天的活跃用户数、启动次数、关卡开始数、关卡完成数、复活看广告次数、分享次数。微信公众平台后台本身就有前两项，剩下的我自建了一张日志表，通过云函数批量写入云数据库。客户端在本地缓存事件，每30秒或触发关键节点时上报一次。这样写的好处是代码量很少，且不依赖任何第三方SDK，也不用担心隐私合规问题。

埋点事件命名上我踩过一个坑：一开始随便写"level_start""win"这种短名，后来想分析"哪个关卡流失最大"才发现当初没记录关卡ID。后来我统一成level_start_{levelId}、level_finish_{levelId}、revive_ad_click、share_success这种结构，查询麻烦减少了一大半。

6.2 最小可行数据分析法

一个人没时间看复杂报表，我就盯三个核心漏斗：

1. 新用户进入游戏到完成第一关的转化率：如果低于50%，说明新手引导或开局难度有问题。
2. 第一关完成到第二关开始的转化率：如果骤降，说明第一关的正反馈不够。
3. 看广告复活的次数除以游戏失败次数：如果比例极低，说明广告位设计不合理或奖励不诱人。

一次版本更新后，我观察到第一关完成率只有38%，怎么调难度都没用。后来我拿几台手机真机走了一遍流程才发现，第一关棋盘尺寸在iPhone SE上显示不全，最下面一行被安全区挡住了，很多玩家根本看不到第一个上手提示。定位到这个问题后，我用安全区适配把棋盘整体上移，第一关完成率直接恢复到67%。这种数据反馈是单纯靠感觉调玩法永远发现不了的问题。

6.3 迭代节奏：小步快跑，但别把玩家当小白鼠

我基本保持每周一个小版本、每个月一个没有大Bug但新内容足够的版本。小版本修Bug和优化手感，大版本加新玩法或新活动。这里想提醒的是：不要因为数据一时不好就频繁推翻玩法，玩家需要时间适应。每次更新最多调整一个核心变量，比如改移动速度，就不要同时改消除奖励和配色，否则你根本不知道是哪个改动影响了数据。

7. 踩坑总结：那些让我夜不能寐，最终却帮了大忙的问题

最后这部分是我最想写的，因为全是真金白银买回来的经验。我只挑最重要的五个坑，希望你看到以后不会重蹈覆辙。

7.1 第一个坑：过度设计让项目拖了三个月

我最早想做的游戏叫"奇幻合成商店"，设定里有合成、有经营、有剧情、有任务、有装扮。原型做了三个月，连可玩的核心环都没跑通。后来我狠心砍掉全部经营和剧情，只保留合成消除一个玩法，两周就做出了可玩版本。这件事让我学会一句话：一个人的工作室，砍掉一半功能，等于提升一倍完成度。

7.2 第二个坑：资源管理混乱导致构建失败

早期我图省事，直接把美术从网上下载的PSD里一个个导出png，文件名乱七八糟，有的叫"11.png"，有的叫"方块最终版2.png"，Cocos Creator的资源UUID一旦变化，场景引用全部断掉。修复这颗雷花了我一整天。后来我强制自己使用规范的资源命名（模块_类型_用途），并且把原始设计稿和最终资源备份到网盘，不再原地覆盖。整个过程非常枯燥，但后来再也没有因为资源问题浪费过时间。

7.3 第三个坑：分享文案踩线，审核被拒

当时为了让玩家点击分享按钮，我写了"分享到群里即可解锁神秘关卡"，审核同学一眼就看出是诱导分享，直接发回修改。这还不是最惨的，最惨是我没有预留备选文案方案，被拒后临时改文案又审核了三四天，错过了周五的流量高峰。从那以后，我的每个版本都会额外准备三套不同的分享文案，并且全部遵守"不诱导、不夸大、不强迫"的原则。

7.4 第四个坑：测试只测满分机型，忽略了低端安卓

开发过程中我一直拿iPhone 12测试，手感流畅得不行。结果第一轮小范围测试时就有一批安卓用户反馈"掉帧严重，像幻灯片"。我借了一台几年前的安卓低端机试了一下，才发现方块消除时粒子特效和阴影叠加导致渲染负担翻倍。最后我把特效数量和阴影层级全部削减，又做了对象池，才算稳住帧率。现在我的自测清单里永远包括一台低端安卓机。

7.5 第五个坑：一个人扛不住所有情绪，必须建立外部反馈源

做游戏最孤独的不是凌晨两点还在修Bug，而是改了一整版功能后没有人告诉你它到底好不好玩。我后来建了一个几十人的玩家群，把每个版本的测试包丢进去，让大家"往死里骂"。群友的一句真实抱怨，比我自己默默想三天更有效。我还和一个同样是独立开发的朋友约定，每周视频沟通一次，互相看对方的版本，给出不带滤镜的评价。这种外部反馈源是一人工作室极其重要的心理支撑，也是保证方向不跑偏的导航仪。

最后再说一个小技巧：在正式上线前，你可以把游戏图标和启动页当成一个小型A/B测试来做。很多一人开发者把精力全放在玩法上，却不重视图标和名称，可它们决定了玩家在游戏列表里愿不愿意点进你的产品。我当时准备了三个风格的图标，通过朋友群投票选出一个，又临时改了游戏名称，让名称直接包含玩法关键词。上线后点击率比初版提升了不少，这个改动花不到半天，回报却非常可观。

一个人做微信小游戏，说白了就是不断做选择，再不断为自己的选择买单。上面这些内容没有一条是网上的标准教程，而是我一步一步踩出来的经验。如果你也正在做或者准备做一人小游戏项目，希望这篇东西能帮你少踩几个无所谓的坑，把有限的精力放在真正重要的事情上。