企业官网建设流程全解析

1. 从零到一：为什么一个人也能做微信小游戏

去年年底，我把自己关在书房里整整三周，用Cocos Creator加TypeScript撸了一个微信小游戏出来。不是那种“Hello World”级别的Demo，而是真正上线、能跑通广告变现、日活稳定在几百的小产品。整个过程只有我一个人：策划、美术、程序、音效、运营，全包。这篇文章就是那次实战的完整复盘，我会把技术选型的逻辑、踩过的坑、以及那些文档里不会写的细节全部倒出来。

如果你是一个独立开发者，或者想尝试用业余时间做点小游戏副业，那这篇内容应该能帮你省下至少两周的试错时间。核心关键词就几个：微信小游戏、Cocos Creator、TypeScript、Canvas。我不会讲太多虚的，直接上干货。

先说结论：一个人做微信小游戏，技术栈选Cocos Creator + TypeScript是目前最稳的组合。为什么不是Unity？为什么不是Phaser？下面我会逐一拆解。

2. 技术选型：Cocos Creator、Unity还是Phaser

2.1 为什么我最终选了Cocos Creator

做微信小游戏，引擎选择是第一道分水岭。市面上主流方案有三个：Cocos Creator、Unity、Phaser。我三个都试过，最后留在Cocos Creator，原因很实际。

Unity的微信小游戏打包流程虽然已经比较成熟，但包体是个硬伤。Unity引擎本身运行时的体积就摆在那里，即便做了裁剪，首包也很难压到微信要求的4MB以内。你可能需要做分包、做资源远程加载，对于一个人来说，光是调通打包流程就能耗掉一周。而且Unity的WebGL导出在低端安卓机上的性能表现，说实话，不太乐观。

Phaser是纯JavaScript的2D引擎，轻量、上手快，Canvas和WebGL双模式。但问题在于，Phaser没有可视化的编辑器。你写个小游戏，场景搭建、UI布局、动画编辑全靠代码硬写。一个人做项目，时间是最贵的，没有编辑器意味着每个像素的调整都要改代码、刷新、看效果，效率太低。而且Phaser的TypeScript支持虽然可以配，但类型定义不够完善，写起来经常要自己补类型声明。

Cocos Creator就不一样了。它自带完整的编辑器，场景编辑、UI布局、动画曲线、粒子效果都是可视化的。TypeScript是一等公民，引擎的API全部有类型定义，写起来非常顺手。最关键的是，Cocos Creator对微信小游戏的导出支持是官方级别的，一键打包，自动处理了大部分适配问题。包体方面，一个简单的2D游戏，首包控制在2-3MB完全没问题。

提示：如果你之前用过Unity，转Cocos Creator大概需要两三天适应。主要差异在组件系统和节点树的设计上，但概念是相通的。

2.2 TypeScript带来的开发体验提升

我早期用JavaScript写过小游戏，那体验就像在黑暗中走钢丝。变量名打错了，运行时才报错；函数参数传错了，调试半天才发现。TypeScript把这些错误提前到了编译阶段，对于一个人做项目来说，这简直是救命稻草。

举个例子，微信小游戏的API调用经常涉及回调函数。用JavaScript写的时候，你根本不知道回调里该接收什么参数。TypeScript有完整的wx命名空间类型定义，你敲一个wx.，编辑器自动补全所有可用API，参数类型一目了然。这省下的查文档时间，累积起来非常可观。

另外，TypeScript的接口和泛型在管理游戏状态时特别好用。比如我定义了一个GameState接口，所有游戏状态都实现这个接口，切换场景时类型安全，不会出现“某个字段忘了初始化”这种低级错误。

interface GameState { score: number; level: number; isPaused: boolean; playerPosition: { x: number; y: number }; } class GameManager { private state: GameState; constructor() { this.state = { score: 0, level: 1, isPaused: false, playerPosition: { x: 0, y: 0 } }; } updateScore(delta: number): void { this.state.score += delta; this.checkLevelUp(); } private checkLevelUp(): void { const threshold = this.state.level * 100; if (this.state.score >= threshold) { this.state.level++; } } }

上面这段代码，TypeScript会在编译时检查所有类型，updateScore只能传数字，playerPosition必须有x和y。这种约束在项目变大之后，价值会指数级上升。

2.3 Canvas渲染与性能考量

微信小游戏的渲染底层是Canvas，但Cocos Creator会根据设备能力自动选择WebGL或Canvas 2D渲染模式。WebGL模式下，渲染性能好很多，但兼容性需要关注。Canvas 2D模式兼容性最好，但绘制大量精灵时帧率会下降。

我的策略是：优先WebGL，降级Canvas。Cocos Creator的构建选项里可以配置渲染模式，我一般选“自动”，让引擎根据设备判断。实测下来，2019年以后的中端安卓机跑WebGL都没问题，帧率稳定在55-60fps。

但有一个坑要注意：Canvas 2D模式下，motionStreak（拖尾效果）这类依赖混合模式的组件表现会不一样。我在一个跑酷游戏里用了MotionStreak做角色拖尾，WebGL下效果很炫，Canvas 2D下直接不显示。后来查文档才发现，MotionStreak依赖gl.BLEND，Canvas 2D不支持。解决办法是降级时用序列帧动画替代，或者干脆去掉拖尾效果。

注意：如果你的游戏大量使用了混合模式、Shader特效，务必在低端机上测试Canvas 2D降级后的表现。不要等到上线后才发现部分用户看不到特效。

3. 项目架构：一个人如何管理代码

3.1 目录结构设计

一个人做项目，最容易犯的错误就是“随手放”。今天把脚本扔在assets/scripts根目录，明天把预制体放在assets/resources下面，过两周自己都找不到文件。我吃过这个亏，所以后来定了一套严格的目录规范。

assets/ ├── scripts/ │ ├── core/ # 核心框架：事件管理、状态机、对象池 │ ├── game/ # 游戏逻辑：玩家控制、敌人AI、关卡管理 │ ├── ui/ # UI逻辑：弹窗、HUD、按钮事件 │ ├── utils/ # 工具函数：数学计算、时间格式化 │ └── config/ # 配置数据：关卡参数、数值表 ├── prefabs/ # 预制体 ├── textures/ # 图片资源 ├── audio/ # 音效和背景音乐 ├── animations/ # 动画剪辑 └── scenes/ # 场景文件

这个结构的好处是职责清晰。找代码的时候，先想“这是游戏逻辑还是UI”，然后直接进对应目录。core目录放的是与具体游戏无关的通用模块，比如事件总线、对象池，这些代码在下一个项目里可以直接复制过去。

3.2 事件驱动与模块解耦

小游戏里模块之间的通信，我强烈建议用事件驱动，而不是直接引用。早期我写代码，UI按钮直接调用GameManager.instance.startGame()，结果后来想改游戏流程，发现UI和逻辑缠在一起，改一处崩三处。

后来我引入了一个简单的事件总线：

type EventCallback = (...args: any[]) => void; class EventBus { private static events: Map<string, EventCallback[]> = new Map(); static on(event: string, callback: EventCallback): void { if (!this.events.has(event)) { this.events.set(event, []); } this.events.get(event)!.push(callback); } static off(event: string, callback: EventCallback): void { const callbacks = this.events.get(event); if (callbacks) { const index = callbacks.indexOf(callback); if (index !== -1) { callbacks.splice(index, 1); } } } static emit(event: string, ...args: any[]): void { const callbacks = this.events.get(event); if (callbacks) { callbacks.forEach(cb => cb(...args)); } } }

UI按钮点击时，只负责EventBus.emit('game-start')，游戏管理器监听这个事件，开始游戏。UI完全不知道游戏逻辑怎么实现的，游戏逻辑也不关心UI长什么样。这种解耦在后期加功能时特别爽，比如我想加一个“每日挑战”模式，只需要新增一个监听器，UI那边加个按钮发事件就行，不用动原有代码。

3.3 对象池：性能优化的第一课

微信小游戏运行在手机浏览器环境里，内存和CPU都有限。频繁地instantiate和destroy节点，会导致垃圾回收频繁触发，游戏卡顿。对象池是必须的。

Cocos Creator有内置的NodePool，但我更喜欢自己封装一个通用的对象池，因为NodePool只支持节点，而游戏里还需要池化其他对象，比如数据对象、子弹逻辑等。

class ObjectPool<T> { private pool: T[] = []; private factory: () => T; private reset: (obj: T) => void; constructor(factory: () => T, reset: (obj: T) => void, initialSize: number = 10) { this.factory = factory; this.reset = reset; for (let i = 0; i < initialSize; i++) { this.pool.push(factory()); } } get(): T { if (this.pool.length > 0) { return this.pool.pop()!; } return this.factory(); } put(obj: T): void { this.reset(obj); this.pool.push(obj); } }

子弹、敌人、飘字这些频繁创建销毁的对象，全部走对象池。实测下来，用了对象池之后，游戏在低端机上的帧率波动从±15fps降到了±5fps以内。

实操心得：对象池的初始大小不要设太大，否则启动时会有明显卡顿。我一般设10-20个，运行时按需增长。另外，reset函数一定要把对象的所有状态重置干净，否则会出现“复用的子弹还带着上次的伤害值”这种诡异bug。

4. 核心玩法实现：从Canvas绘制到游戏逻辑

4.1 角色控制与物理系统

我的小游戏是一个2D平台跳跃类玩法，角色需要跑、跳、踩敌人。Cocos Creator内置了物理系统，但对于这种简单的平台跳跃，用物理引擎反而麻烦。我选择了自己写一个轻量级的AABB碰撞检测。

角色的移动逻辑很简单：水平方向由输入控制，垂直方向受重力影响。每一帧更新位置，然后检测与地面的碰撞。

class PlayerController extends Component { private velocity: Vec2 = new Vec2(0, 0); private gravity: number = -980; // 像素/秒² private moveSpeed: number = 200; private jumpForce: number = 450; private isGrounded: boolean = false; update(dt: number): void { // 水平输入 let horizontal = 0; if (Input.isKeyPressed(KeyCode.KEY_A)) horizontal -= 1; if (Input.isKeyPressed(KeyCode.KEY_D)) horizontal += 1; this.velocity.x = horizontal * this.moveSpeed; // 重力 this.velocity.y += this.gravity * dt; // 跳跃 if (Input.isKeyPressed(KeyCode.SPACE) && this.isGrounded) { this.velocity.y = this.jumpForce; this.isGrounded = false; } // 更新位置 const pos = this.node.position; this.node.setPosition( pos.x + this.velocity.x * dt, pos.y + this.velocity.y * dt ); // 碰撞检测 this.checkCollision(); } private checkCollision(): void { // 与地面和平台的AABB检测 // 省略具体实现 } }

这里有个细节：重力值我设的是-980，这是模拟真实重力加速度（9.8m/s²）换算到像素单位的结果。但实际调的时候，我发现这个值让跳跃手感偏“重”，后来改成了-1200，跳跃更轻快。数值调优没有标准答案，多试几次，找到自己觉得舒服的值。

4.2 关卡设计与数据驱动

一个人做游戏，关卡设计是最耗时的部分。如果每个关卡都硬编码在代码里，改一个数字就要重新编译，效率太低。我的做法是：关卡数据用JSON配置，运行时加载。

{ "levelId": 1, "platforms": [ { "x": 0, "y": -200, "width": 800, "height": 40 }, { "x": 300, "y": -100, "width": 200, "height": 20 }, { "x": 600, "y": 0, "width": 200, "height": 20 } ], "enemies": [ { "type": "slime", "x": 400, "y": -150, "patrolRange": 100 } ], "coins": [ { "x": 350, "y": -50 }, { "x": 650, "y": 50 } ], "goal": { "x": 750, "y": 100 } }

关卡编辑器我用的是Tiled Map Editor，导出JSON，然后在游戏里解析。Tiled支持图层、对象组，可视化编辑，比在代码里写坐标高效十倍。解析逻辑大概一百行代码，一次性投入，后面所有关卡都受益。

提示：Tiled导出的JSON坐标系和Cocos Creator的坐标系可能不一致，注意做转换。Tiled的y轴向下，Cocos Creator的y轴向上，解析的时候要取反。

4.3 微信小游戏API接入

微信小游戏的API是wx命名空间下的，Cocos Creator构建时会自动注入类型定义。常用的API包括：

• wx.createUserInfoButton：获取用户信息
• wx.onShareAppMessage：分享
• wx.createRewardedVideoAd：激励视频广告
• wx.setStorageSync：本地存储

激励视频广告是变现的核心。接入流程不复杂，但有几个坑：

第一，广告实例要提前创建，不要等到用户点击按钮时才创建，否则加载时间会让用户等太久。我一般在游戏启动时就创建好广告实例，预加载。

第二，广告播放完成后的回调要处理好。用户看完广告，你要给奖励，但也要考虑用户中途关闭的情况。onClose回调里会告诉你isEnded，只有isEnded为true才给奖励。

class AdManager { private rewardedAd: any = null; init(): void { if (typeof wx === 'undefined') return; this.rewardedAd = wx.createRewardedVideoAd({ adUnitId: 'your-ad-unit-id' }); this.rewardedAd.onError((err: any) => { console.error('广告加载失败', err); }); } showRewardedAd(onReward: () => void): void { if (!this.rewardedAd) { onReward(); // 降级处理，直接给奖励 return; } this.rewardedAd.show().catch(() => { // 加载失败，重新加载后再试 this.rewardedAd.load().then(() => { this.rewardedAd.show(); }).catch(() => { onReward(); // 仍然失败，降级给奖励 }); }); this.rewardedAd.onClose((res: any) => { if (res && res.isEnded) { onReward(); } }); } }

注意：广告的onClose回调是全局的，每次调用show之前要确保没有重复绑定。我一开始没注意，导致用户看一次广告触发了三次奖励，差点被判定为作弊。后来改成每次show之前先offClose再onClose。

5. 打包发布与性能调优

5.1 微信小游戏打包流程

Cocos Creator的构建面板里选择“微信小游戏”，填好AppID，点击构建。构建完成后，用微信开发者工具打开build/wechatgame目录，预览、上传。

但构建只是第一步，后面还有几个必须做的优化：

包体压缩。微信小游戏首包限制4MB，超过就要做分包。我的做法是：首包只放核心玩法和必要资源，关卡数据、后续关卡的图片走远程加载。Cocos Creator支持配置资源远程服务器地址，构建时会把超过阈值的资源自动放到远程。

代码混淆。构建选项里开启“压缩代码”和“混淆代码”，能减小包体，也能防止别人轻易反编译。但注意，混淆后如果线上出bug，堆栈信息会很难看。我的做法是保留一份sourcemap，只在本地调试用，不上传。

纹理压缩。微信小游戏支持ASTC、ETC2等压缩纹理格式。开启后，图片资源体积能减少50%以上。但要注意，不同机型支持的格式不同，Cocos Creator会自动做兼容处理，构建时勾选“自动压缩纹理”即可。

5.2 性能监控与帧率优化

游戏上线后，性能问题会通过用户反馈暴露出来。我在游戏里内置了一个简单的性能监控，每5秒记录一次帧率，如果连续低于30fps，就上报到服务器。

class PerformanceMonitor { private frameCount: number = 0; private lastTime: number = 0; private lowFpsCount: number = 0; update(dt: number): void { this.frameCount++; const now = Date.now(); if (now - this.lastTime >= 5000) { const fps = this.frameCount / ((now - this.lastTime) / 1000); if (fps < 30) { this.lowFpsCount++; if (this.lowFpsCount >= 3) { this.reportLowFps(fps); this.lowFpsCount = 0; } } else { this.lowFpsCount = 0; } this.frameCount = 0; this.lastTime = now; } } private reportLowFps(fps: number): void { // 上报到服务器，记录设备型号、场景等信息 } }

根据上报数据，我发现低端机上的主要瓶颈是粒子特效和DrawCall过高。优化手段包括：减少同屏粒子数量、合并纹理图集、使用cc.Macro.CLEANUP_IMAGE_CACHE清理图片缓存。

5.3 常见问题排查速查表

实操心得：微信开发者工具的“真机调试”功能一定要用。模拟器上跑得好好的，真机上可能完全不一样。特别是触摸事件和音频播放，模拟器和真机差异很大。我每次发版前，至少在三台不同档次的安卓机上真机测试。

6. 变现与运营：一个人如何让游戏活下去

6.1 广告变现的节奏控制

小游戏的变现主要靠广告：激励视频、插屏广告、Banner。但广告不能乱放，放多了用户直接卸载。我的策略是：

激励视频放在“复活”、“双倍奖励”、“解锁新角色”这些用户有明确需求的地方。用户主动选择看广告，接受度高。

插屏广告放在关卡结束后的结算界面，但频率要控制。我设置的是每三关弹一次，而且如果用户刚看过激励视频，这次插屏就跳过。

Banner广告放在主菜单底部，不影响游戏操作。但Banner的收益很低，主要是填充。

注意：微信小游戏对广告频率有规定，过于频繁的广告弹出可能导致审核不通过。具体限制可以在微信官方文档里查到，这里不展开。

6.2 用户留存的小技巧

一个人做运营，没预算买量，只能靠产品本身。我做了几件事来提升留存：

每日签到。连续签到奖励递增，第七天给一个稀有角色。这个功能开发成本很低，但留存效果明显。我的数据是，加了签到后，次日留存从25%提升到了35%。

排行榜。好友排行榜利用微信的开放数据域，展示好友分数。攀比心理是留存的重要驱动力。但要注意，开放数据域的渲染和主域是隔离的，需要用wx.getOpenDataContext来操作。

分享奖励。分享给好友，双方各得一次复活机会。这个功能要小心，微信对诱导分享打击很严。我的做法是：分享按钮不强制，用户可以选择分享或看广告，两者选其一。

6.3 数据埋点与分析

没有数据，运营就是盲人摸象。我在游戏里埋了几个关键事件：

• 游戏启动
• 关卡开始/结束
• 广告展示/完成
• 分享点击
• 签到

每个事件带上用户ID、时间戳、关卡ID等参数，上报到自己的服务器。然后用简单的图表工具分析。比如，我发现第三关的流失率特别高，达到60%。去玩了一下，发现第三关的难度曲线突然变陡，很多用户卡在这里。后来调整了第三关的敌人数量和平台间距，流失率降到了35%。

7. 独立开发者的时间管理

一个人做游戏，最大的敌人不是技术难题，而是时间。白天要上班，晚上和周末才能写代码。我的经验是：

固定时间块。每天晚上9点到11点，雷打不动写代码。不要等“有灵感”再写，灵感是写出来的。

任务拆分。把大功能拆成小任务，每个任务控制在2小时内能完成。完成一个划掉一个，有成就感，也能看到进度。

先完成再完美。美术资源先用占位图，音效先用免费素材，等玩法跑通了再替换。我见过太多人卡在“找一个完美的角色立绘”上，结果游戏永远没做完。

每周发一个版本。哪怕只是修了一个bug，也要发版。保持节奏，避免项目烂尾。

实操心得：我用Trello管理任务，分“待办”、“进行中”、“已完成”三列。每周日晚上规划下周任务，每天睡前更新进度。这个习惯让我在三个月内完成了第一个上线版本。

8. 后续扩展方向

这个项目跑通之后，我总结了一套可复用的框架：事件总线、对象池、关卡数据驱动、广告管理、性能监控。下一个游戏，我只需要换美术资源和玩法逻辑，框架层直接复用。目前正在做的是一个合成类小游戏，预计开发周期能压缩到一个月以内。

另外，TypeScript的类型系统在大型项目里的价值越来越明显。我最近在尝试用TypeScript的装饰器来简化组件注册，虽然Cocos Creator的装饰器支持还有限，但方向是对的。等这个合成游戏上线后，我会再写一篇关于装饰器实战的分享。

如果你也在做微信小游戏，或者准备入坑，我的建议是：先做一个最小的可玩版本，上线，看数据，再迭代。不要憋大招，不要追求完美。小游戏的窗口期很短，快速验证比什么都重要。