企业官网建设流程全解析

简介：一套基于 Cocos Creator 2.3.3 开发的猜成语游戏项目工程包，面向希望用真实案例上手 Cocos Creator 的初中级开发者，涵盖环境搭建、UI 界面设计、成语题库管理、随机出题与答案判断、排行榜、音效动画及发布全流程，可作为 2D 游戏整体实现的学习蓝本。压缩包共 2765 个文件，约 18.74MB，含大量 JSON 成语数据、png 美术资源、prefab 预制体、js 逻辑脚本和 mp3 音频，并带 meta 元数据及 effect/plist 动画配置，目录结构完整，便于按模块检索与二次开发。目前已有 1241 人学习下载。通过这套资源可以拆解一套可运行的猜成语游戏：成语数据以 JSON 形式存储，出题、输入判断、计分与排行榜更新逻辑由 js 脚本实现，预制体可直接拖入场景复用；同时可从资源组织方式与事件响应写法中掌握 Cocos Creator 项目结构和常见交互设计思路，适合作为实战练习或二次开发基础。

1. 猜成语游戏不是套模板：Cocos Creator 2.3.3 项目的真实构成

拿到这份猜成语游戏资源时，别急着把它拖进 Cocos Creator 按运行键。解压后你会看到一堆 .bin 文件和 chengyu、rank 两个关键字，这更像是一个半成品工程的构建产物，而不是带场景的完整源码。我的建议是把这份资源当成一份开发说明书看：环境用 Cocos Creator 2.3.3，玩法是随机出成语、输入答案、判断对错、记录分数，真正的技术点集中在 UI 动态生成、题库读取、状态管理和 Android 打包适配。它能帮你把 Cocos 的 UI 系统、资源加载和事件驱动串成一条完整的开发路径，适合已经会看 Cocos 文档、想做出第一个能跑的游戏的新手，也适合需要快速搭建答题类玩法原型的熟手。接下来的章节，我会按实际开发顺序，把每一步的取舍和踩过的坑讲清楚。

2. 搭场景不是摆节点：先定分辨率与锚点，再谈动态 UI

2.1 创建项目与场景层级：竖屏分辨率、Fit Height 与节点规划

Cocos Creator 2.3.3 新建项目选空模板还是 2D 模板区别不大，反正场景里只有一个 Canvas。猜成语这类答题游戏，操作集中在屏幕中下方，建议把设计分辨率定成 720×1280，竖屏，单位是像素。在 Canvas 的 cc.Canvas 组件里把 Fit Height 勾上，Fit Width 不勾。原因是答题游戏的内容纵向长，横向上只需要保证背景不露白边，Fit Height 可以保证纵向内容完整，横向通屏。很多人直接把项目分辨率改成自己想要的数字，不改适配策略，结果小屏手机上按钮跑出屏幕，这就是典型的适配翻车。

节点层级我一般这么定：

Canvas ├─ BG (Sprite) ├─ Title (Label) ├─ AnswerPanel (Node, 承载答案格子) ├─ TipLabel (Label) ├─ InputBox (EditBox) ├─ ConfirmBtn (Button) └─ ScoreLabel (Label)

每个节点的锚点尽量统一，按钮和提示信息用 (0.5, 0.5)，背景也用 (0.5, 0.5)，这样位置调整时心智负担最小。Cocos 的 UI 系统按节点树渲染，后加入的子节点会覆盖在前面的节点上面，所以背景放在最前面，提示和操作按钮往后放。这一层不写代码，先把场景结构定清楚，后面动态生成的节点才有明确的挂载点。另外一个很多人忽略的点：Canvas 下的节点位置计算是从屏幕中心开始的，不是左上角，所以"放在屏幕上方"意味着 y 正值，而不是负值。

2.2 用预制体动态生成答案格子：减少手工节点，提升复用性

网上很多猜成语教程把答案格子一个个手动摆到场景里，这种做法在不同屏幕宽度下非常容易错位。我一般只做四个答案格子的预制体，每个字单独一个框，玩家看到空框数量就知道成语字数，观感比纯文本框好很多。具体做法是把格子做成 Prefab，在代码里根据题库字段的长度实例化，然后交给 cc.Layout 自动排列。

createAnswerCells(wordCount) { const panel = this.node.getChildByName('AnswerPanel'); panel.destroyAllChildren(); // 清掉上一题残留 for (let i = 0; i < wordCount; i++) { const cell = cc.instantiate(this.cellPrefab); cell.parent = panel; cell.getComponent(cc.Label).string = ''; } }

这段代码的逻辑是：先拿到 AnswerPanel 这个空节点，把上一次生成的子节点全部清掉，否则新题会叠在旧字块上。然后根据 wordCount 循环实例化预制体，挂到 panel 下。cellPrefab 是在编辑器里做好并拖到脚本 properties 上的资源。注意这里没有手动设置坐标，因为 panel 上挂了一个 cc.Layout 组件，类型选 HORIZONTAL，子节点会自动从左到右排列，并且自动适配间距。

如果你要手动控制格子间距，可以在 Layout 的 spacingX 里设置，比如 20 像素。这样生成出来的格子不会因为面板宽度变化而堆积到一起。比起手摆节点，预制体方案的好处是换字体、换背景框颜色时只改一处。我习惯把 cellPrefab 的锚点设为 (0.5, 0.5)，尺寸固定为 120×120，这样在各种分辨率下视觉比例稳定。

2.3 输入框与按钮的事件绑定：用 editing-did-ended 而不是 text-changed

答案输入用 cc.EditBox，可以直接放在场景里，也可以通过代码创建。我推荐在场景编辑器里放好，然后通过节点引用获取组件。EditBox 有三个重要参数：输入模式、最大长度和返回值类型。输入模式设成 SINGLE_LINE，最大长度设 12，四字成语就算带上多余标点也够，returnType 设 DONE，这样安卓上软键盘的确认键显示"完成"而不是"换行"，体验更自然。

事件绑定方面，常见错误是监听 text-changed 事件去实时判断，这样玩家用拼音输入法选字时，中间态的字母串也会触发判断，导致误判。我会用 editing-did-ended，也就是玩家结束编辑后才触发判断逻辑。

this.editBox.node.on('editing-did-ended', this.onInputEnded, this);

第三个参数 this 是回调的 target，在 cc.Class 中不传 target，回调里的 this 会丢失。onInputEnded 里只需要一行关键代码：this.editBox.string拿到用户输入，然后去空格，交给后面的判断函数处理。Cocos Creator 2.3.3 的事件是挂在节点上的，也可以在编辑器事件面板配置，但代码绑定更可控。我见过有人在编辑器里绑了回调，后来改了节点名导致绑定失效，这种隐性问题排查起来很费劲，所以这里选择代码管理。

如果要让输入框在界面显示时自动聚焦，可以调用this.editBox.setFocus()。注意 setFocus 只能在节点激活状态下调用，否则没有效果。实际项目中自动聚焦并不是必需的，因为玩家可能先点提示按钮再看输入，强制弹键盘反而挡视线。这里改成点击输入框再弹出即可。

3. 成语题库的读取：从 bin 资源到 JSON 数据的落地姿势

3.1 项目里的 chengyu 与 bin 文件到底该怎么处理

下载包里带了 chengyu、rank 这样的命名，还散着一堆 .bin 文件。在 Cocos Creator 2.3.3 的构建结果里，.bin 是资源序列化后的二进制内容，可能是音频合并包、图片合图或者 Asset Bundle 的一部分。如果你拿到的只有这些 bin，没有工程源码目录，那这些文件是没法直接拖回编辑器引用的。我的建议是不要花时间研究怎么解包它们，而是把题库整理成一份 JSON 放到项目里自己用。

成语素材本身是可再整理的文本资源。常见做法是把每条成语的答案、解释、拼音放在一个 JSON 数组里，字段清晰，后续加载和检索都方便。bin 文件如果是音频素材，也没必要强行复用，找几个几十 KB 的短音效更容易控制体积。真正在发布的包中，项目里的 JSON 也会被 builder 转成二进制格式，外部看不到明文，所以不改动 bin 不影响发布安全。

3.2 封装一个 DataManager：异步加载、缓存与随机出题

在 Cocos Creator 中读 Resources 目录下的资源，推荐cc.resources.load。加载是异步的，数据无法在 load 返回后立刻使用，必须等回调。我习惯把题库封装成一个 DataManager 单例，全局只加载一次，之后任何场景都能直接取。

const DataMgr = { _list: null, load(cb) { if (this._list) { cb(null); return; } cc.resources.load('data/chengyu', cc.JsonAsset, (err, asset) => { if (err) { console.error('题库加载失败', err); cb(err); return; } this._list = asset.json; cb(null); }); }, getOne(ignoreIndex) { if (!this._list || this._list.length === 0) return null; let idx = Math.floor(Math.random() * this._list.length); if (idx === ignoreIndex) idx = (idx + 1) % this._list.length; return { data: this._list[idx], index: idx }; } };

load 方法先判断 _list 是否已经存在，已加载就直接回调，避免在场景切换时重复读取磁盘。资源路径是data/chengyu，不带扩展名，因为 Cocos 会根据资源类型自动找后缀。getOne 方法返回随机一条数据，同时把索引暴露给调用方。调用方把上一次的 index 传进来时，getOne 会向后取一条，避免连续两题相同。如果题库数量只有几十条，这种简单处理够用，不需要做真正的洗牌算法。

使用 DataManager 的脚本通常在 onLoad 里调用：

DataMgr.load((err) => { if (!err) this.initGame(); });

initGame 里才去生成题目界面，不要在自己的 onLoad 里直接读题库字段，因为那时数据还没回来。这是新手最容易踩的异步顺序坑。

3.3 数据清洗：只保留四字纯汉字，过滤异常条目

从网上整理的成语题经常混入拼音、括号、英文翻译，比如"一清二楚（yī qīng èr chǔ）"。这种脏数据不洗，后续判断和显示都会出问题。我在 load 回调里立刻做清洗和转换，只保留真正需要的字段。

this._list = asset.json .filter(item => { if (!item.answer || typeof item.answer !== 'string') return false; const s = item.answer.replace(/\s/g, ''); return s.length === 4 && /^[\u4e00-\u9fa5]{4}$/.test(s); }) .map(item => ({ answer: item.answer.replace(/\s/g, ''), explain: item.explain || '', pinyin: item.pinyin || '', pic: item.pic || '' }));

filter 里的正则要求答案必须是四个中文字符，\u4e00-\u9fa5覆盖常用汉字。map 把字段固化，保证后续代码拿到的 answer、explain 不会是 undefined。这里清洗只做一次，而不是每次判断时重复做，否则上万条数据会拖慢游戏。

实际场景中如果题库来源是 txt 文本，我一般用 Node.js 脚本把它转成 JSON，分隔符用 Tab。脚本核心就是把每一行拆成答案和解释两个字段，生成 JSON 后放到assets/resources/data/chengyu.json。注意文件编码必须是 UTF-8，不要带 BOM，否则 Cocos Creator 的 JSON 解析器会报错。这一点在 Windows 记事本存盘时要特别留意。

rank 文件如果是要做排行榜的，我的做法是彻底脱离它的原始格式，自己在本地用 localStorage 和文件缓存双写实现。下一章会讲具体的计分和存储代码。

4. 游戏核心逻辑：状态机、答案判定与本地排行榜的完整实现

4.1 用状态机管理游戏流程：防止连点与重复出题

答题游戏最容易出的问题是点击按钮后疯狂生成节点，或者同一题被判定多次。我维护一个整型 state，每个值对应一个游戏阶段，进入阶段前先检查合法性。

const State = { IDLE: 0, // 暂无题目 ASKING: 1, // 题目已出，等待输入 JUDGING: 2, // 正在判定，禁用操作 SETTLED: 3 // 本回合结束，等待下一题 };

开始游戏按钮点击后，先检查 state 是否为 IDLE，不是就直接 return。然后把 state 置为 ASKING，调用 DataMgr.getOne 取出随机题，展示题目和提示。确认按钮事件里再判断 state 是否为 ASKING，进入 JUDGING 后执行比较，比较完进入 SETTLED，此时只有"下一题"按钮可用。

状态机的价值在于逻辑变得可预测。对比那种直接在按钮回调里写全部业务逻辑的实现，状态机可以避免玩家快速重复点击导致同一题判定两次、分数多加的情况。在 Cocos Creator 2.3.3 中事件回调默认是单线程的，但是按钮连点产生的多个事件会在同一帧依次触发，没有状态保护，状态就会乱。

4.2 输入清洗与答案判断：空格、标点、全角字符一锅端

用户输入法敲出的字符串带了很多隐藏字符：句号、逗号、全角空格、不间断空格。如果直接拿输入内容和题目 answer 比较，明明答对了却提示错误，玩家会直接卸载游戏。所以判断前必须做归一化处理。

normalize(str) { return (str || '') .replace(/[ \u3000\u00A0]/g, '') .replace(/[，。！？、,.!?;；:"'“”（）()]/g, '') .replace(/[Ａ-Ｚａ-ｚ０-９]/g, ch => String.fromCharCode(ch.charCodeAt(0) - 0xFEE0)); }, check(input, answer) { const a = this.normalize(input); const b = this.normalize(answer); return a.length === 4 && a === b; }

第一个 replace 去掉半角空格、全角空格和不断行空格；第二个 replace 去掉常见中文标点和英文标点；第三个 replace 把全角字母数字转换成半角。最后 check 函数先比较长度，再比较内容，避免输入"一清二楚好"这种五个字但前四个字匹配的假正确。

这里没有做繁体转简体，如果题库里有繁体词，判断会失败。我在资源准备阶段就把所有数据清洗成简体。判断用的函数是纯 JavaScript，不依赖 Cocos 引擎，意味着你可以单独在单元测试环境里验证——把这段代码复制到一个 Node 脚本里跑几个用例，比在游戏里测试快速得多。

4.3 计分规则与本地排行榜：用 cc.sys.localStorage 存最高分

猜成语的计分规则可以简单做成答对 +10，答错不扣分，连续答对翻倍只是数值改进，核心记录逻辑一样。我实现一个 addScore 方法，正确时加分并更新 UI，错误时不操作。

addScore(correct) { if (correct) { this._score += 10; this.scoreLabel.getComponent(cc.Label).string = this._score.toString(); } }, saveRank() { const KEY = 'chengyu_rank'; const best = Number(cc.sys.localStorage.getItem(KEY) || 0); if (this._score > best) { cc.sys.localStorage.setItem(KEY, String(this._score)); } }

KEY 加了项目前缀，避免和其他游戏公用同一域名时冲突。cc.sys.localStorage 是同步接口，读写都在主线程完成，数据量只在几十字节内可以接受。排行榜如果要存前 10 名，就把数组 JSON.stringify 后存进同一个 key，读取时 parse 出来。

单纯的 localStorage 在真机上并不保险，系统可能清理 WebView 缓存。为了稳，我在原生平台还会写入文件：把jsb.fileUtils.getWritablePath()得到的路径加上chengyu_rank.json，每次 saveRank 时都写一遍。读取时优先读文件，文件不存在再读 localStorage。这样做的好处是即使系统清了 Storage，分数文件还在。

4.4 提示功能与交互闭环：扣分提示、下一题按钮

给游戏加一个"提示一字"按钮能有效提升可玩性。提示逻辑是把当前成语的第一个字填到答案格子，同时从总分里扣 5 分。实现时要注意，单元格 Label 一旦填上初始字符，后面判断就不应该受影响，因为判断函数是比较完整答案，而不是读取格子内容。

giveHint() { if (this.state !== State.ASKING) return; const answer = this._current.data.answer; const cells = this.answerPanel.children; if (!cells || cells.length === 0) return; const cellLabel = cells[0].getComponent(cc.Label); if (cellLabel.string === '') { cellLabel.string = answer[0]; this._score -= 5; this.scoreLabel.string = this._score.toString(); } }

cells[0] 是答案面板第一个子节点，四字成语直接提示第一个字。这里要求 answerPanel 的子节点顺序和成语字顺序一致，而动态生成时已经保证。扣分直接修改 _score，不需要走 addScore，防止出现错误加分。

确认按钮的完整回调可以写成：

onConfirm() { if (this.state !== State.ASKING) return; this.state = State.JUDGING; const input = this.editBox.string; const isRight = this.check(input, this._current.data.answer); if (isRight) { this.tipLabel.string = '正确'; this.addScore(true); } else { this.tipLabel.string = '不对，再试试'; this.addScore(false); } this.state = State.SETTLED; this.nextBtn.active = true; }

这里把 UI 更新和状态切换放在一起，逻辑直观。实际项目里可以把状态切换抽成统一函数，但抽太细反而不好读。重点是每个状态入口要设置对应的 UI 状态，比如 JUDGING 时让按钮置灰，SETTLED 时显示下一题按钮。

5. 猜成语打包 APK：Cocos Creator 2.3.3 真机上的五个坑

5.1 真机加载失败：bin 文件路径与大小写问题

现象：模拟器运行正常，打包成 APK 安装在手机上，进入加载场景时卡住或直接退出，logcat 里能看到"load json failed"或者资源找不到的报错。

原因：Cocos Creator 构建时把 Resources 目录下的文件打包到 Andriod 资源路径，路径大小写敏感。如果你的目录叫 Data，代码里写 data，在 Windows 上没问题，在 Android 上就是找不到。另一种常见原因是资源名带了空格或中文，构建工具不报错，但运行时字符串匹配失败。

解决：把项目里所有资源目录和文件名统一成小写字母、下划线，路径里不写扩展名。代码里使用相对路径cc.resources.load('data/chengyu')，不要用绝对路径。构建时如果勾选了 MD5 Cache，资源文件名会带上哈希，但 Resources 目录的读取逻辑不受影响。最保险的做法是先取消 MD5 Cache 联调，最后发布再打开。另外从旧版本迁移项目时，删除项目根目录的 Library 和 temp 文件夹再重新构建，避免老缓存干扰新资源。

5.2 中文输入框弹不出键盘

现象：点击 EditBox 没有任何反应，或者键盘弹出了一下立刻收回。

原因：Cocos Creator 2.3.3 的 EditBox 在部分 Android 机型上与原生输入法兼容性差。常见诱因是 EditBox 的 inputMode 没有设置为 SINGLE_LINE，导致输入法回调被系统强制终止。此外，构建后的 AndroidManifest.xml 里 windowSoftInputMode 如果设置不当，键盘会顶起或遮挡应用，给人的感觉就是没弹。

解决：EditBox 组件属性面板里把 Input Mode 改为 SINGLE_LINE，Return Type 改为 DONE。然后在构建生成的 AndroidManifest.xml 中找到 Activity 标签，确认android:windowSoftInputMode="adjustResize"。如果你用的是 WebView 模式，还需要确认 WebView 的 focusable 设置。我踩过的坑是用了默认的 adjustUnspecified，部分手机上键盘弹不出来，改成 adjustResize 后立刻正常。

5.3 播放音效杂音或没声音

现象：本地预览播放点击音效正常，打包后背景音乐正常，音效却破音或者完全无声。

原因：Cocos Creator 2.3.3 对不同格式的音频在 Android 上的兼容性差异很大。mp3 在某些机型上采样率不匹配就会破音。另外多个 AudioSource 同时播放，音量叠加会导致爆音。

解决：音频资源优先转成 ogg 格式，点击音效文件控制在 100KB 以内。播放短音效时不要直接在场景节点上挂一个 AudioSource 反复用，而是创建一个音频池，动态生成节点播放，播放完回收。

playClick() { const node = new cc.Node('fx'); node.parent = this.node; const audio = node.addComponent(cc.AudioSource); audio.clip = this.clickClip; audio.volume = 0.6; audio.play(); node.on('finished', () => node.destroy(), this); }

音量 0.6 是经验值，留出余量避免多个特效叠加时削波。finished 事件里销毁节点，不会造成内存泄漏。注意事件名在 2.3.3 中确实是finished，不是浏览器 WebAudio 的ended。

5.4 排行榜分数丢失：本地存储与文件双写

现象：玩家通关后最高分显示正常，第二天再进游戏分数回到 0。

原因：cc.sys.localStorage在 Android 端本质是 WebView 的 LocalStorage，系统在内存不足或应用更新时可能清理该数据。如果游戏因为 bug 闪退，未落盘的数据也会丢。

解决：在原生平台额外写文件。代码写在saveRank()方法里，用 jsb.fileUtils 写 JSON 文件到应用沙盒目录。

saveToFile(score) { if (!window.jsb) return; const path = jsb.fileUtils.getWritablePath() + 'chengyu_rank.json'; const data = JSON.stringify({ best: score, updateAt: Date.now() }); jsb.fileUtils.writeStringToFile(data, path); }

读取时先判断文件是否存在，存在则读取文件里的 best，再与 localStorage 里的值比较，取较大者作为当前最高分。文件路径在不同平台不同，但getWritablePath()返回的都是应用私有目录，不需要额外权限。必备的 Android 写入权限已经在构建模板里默认开启。

5.5 中文变方块：字体缺失

现象：真机上所有使用默认字体的 Label 显示为方格□□□，模拟器正常。

原因：Cocos Creator 2.3.3 的默认字体 Arial 不包含中文字形，在 Android 上没有自动回退到系统中文字体。只有指定了行距或设置了其他字体属性的 Label 有可能被系统单独渲染。

解决：项目里放一个中文 ttf 字体文件，比如思源黑体子集或 Noto Sans SC。在场景中任意选中一个空的 Label 节点，把 Font 属性设为该字体，然后这里设置为"默认"，更正确的做法是全局统一管理：创建一个cc.Label的扩展组件，在 start 时强制设置 font 为共享字体。最简单粗暴的是进入项目后在编辑器里把所有 Label 的 Font 重新拖一遍，虽然费时但可靠。

字体文件体积大，尽量只保留需要的字重。我用的是一个 3.5MB 的简体中文子集，覆盖了常用成语出现的高频字。如果你用系统字体选项，在国产 ROM 上会随机命中不同字体，观感不统一，不建议。

6. 最后一关：用 20 分钟做一遍真机检查，确认游戏能交付

游戏功能写完，重点转移到验证。我吃过太多次"本地跑得通，一发包就翻车"的亏，后来把发布前的检查固定成表格，每次强制走一遍。

前两项在模拟器上就能验证，第三项到第五项一定要在真机。真机调试 Android 时，用 adb 过滤日志能快速定位崩溃原因：

adb logcat -s Cocos2dx danglingJs:V

这个命令只看 Cocos 的 JS 报错，比盯着黑屏猜原因高效。如果你手边没有 Android 设备，也可以用 Cocos 的浏览器预览模式在 Chrome 里模拟移动端，但输入法、字体这些还是真机才暴露问题。

除了真机检查，构建面板的选项也要留意。Cocos Creator 2.3.3 的"MD5 Cache"一旦勾选，Resources 内文件在发布包里会改名。代码里如果写死了某个文件的原始路径，构建后就会加载失败。我一般联调阶段不勾，发布前才勾上，并且所有动态加载都走cc.resources.load，路径带不带哈希都由引擎处理，不手拼路径。

从那以后，我每次发版前都会强制自己把这张表完整过一遍，哪怕只改了一行 UI 代码也不例外。输入框真机测试尤其不能跳过，因为这个环节几乎每个版本都有人踩坑。很多看起来玄学的崩溃，最后都落在某一行配置上。希望这套流程帮到你，少走我走过的弯路。

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