game-bird 最开始只是我 GitHub 仓库里的一个随手建的项目名后来慢慢长成了一个能跑、能玩、能拿出去展示的鸟类知识问答小游戏。简单来说它就是一个纯前端实现的答题闯关游戏每道题给你几条关于鸟类的线索四个候选答案里挑出正确的鸟名15 秒内作答10 题为一轮最后看你能拿多少分。做这个项目的原因很直接一是我那段时间在公园遛弯时总被孩子追着问“这是什么鸟”索性做个工具让孩子自己玩着学二是我一直想验证一个想法——不碰 React、不碰 Vue、不上构建工具就靠一份 HTML 文件能不能做出一个体验完整的游戏。做完之后的结论是能而且还挺顺手。这篇文章把整个开发过程、核心代码和踩过的坑都记录下来适合刚学完前端三件套想找练手项目的人也适合想快速做一个教育类小游戏的人参考。1. 整体设计与思路拆解1.1 核心玩法与项目定位这个游戏要解决的根本问题是把“记鸟名”这件有点枯燥的事变得像刷短视频一样轻松。所以核心玩法设计成“线索问答”显示一条文字线索玩家在四个选项中点击一个。线索我设计了三类信息组合外形描述比如“头顶有黑色冠羽”、栖息环境比如“常见于城市公园和农田”、典型行为比如“喜欢在地面蹦跳觅食”。线索通常是 2 到 3 条组合出现避免线索太直白导致题目没有思考空间也避免太隐晦导致玩家全靠蒙。定位上我刻意做成了“轻量休闲”而不是“硬核竞速”。每轮 10 道题每题 15 秒正常玩一局就是两三分钟的事坐地铁、排队、睡前都能来一局。计分上采用“正确得 10 分、连续答对额外奖励 2 分”的规则既简单好懂又能给老手一点挑战同时不会劝退新手。为什么做问答而不是做成类似“小鸟归巢”那种操作型游戏因为操作型游戏的门槛在操作手感知识型游戏的门槛在知识密度前者的美术和物理引擎成本很高一个人很难在短时间里做出手感后者只要题目质量够玩法本身的实现成本很低。对一个时间有限的个人项目来说问答这个方向是性价比最高的选择。1.2 技术选型为什么坚持纯前端三件套在技术选型上我几乎是刻意地没有用框架。原因有三点第一这个游戏的核心逻辑只有“出题、答题、计分、倒计时”四件事用原生 JavaScript 几百行就能搞定引入框架反而增加读代码的人的理解成本。第二我希望最终的产物可以双击 HTML 文件直接运行这样一个没有任何命令行基础的人也能玩上如果是用脚手架搭出来的项目还得配 Node 环境、装依赖、起服务传播成本高了一大截。第三我始终认为在学框架之前把原生 DOM 操作、事件绑定、定时器这类基础吃透后面学框架会轻松很多。实际开发中我用了三个文件来组织代码index.html 负责结构style.css 负责样式script.js 负责逻辑。没有用任何第三方库连图标库都没引。视觉上的反馈全部靠 CSS 类切换和简单的动画实现这样也方便后续想把它用 Electron 或 Cordova 包成桌面端、移动端应用的人代码拿过去几乎不用改。1.3 核心状态设计与信息架构小游戏最容易出问题的地方就是状态管理。很多人写着写着页面上的元素越来越多互相改来改去最后自己都理不清当前处于什么阶段。我在动手前用最简单的方式画了一个状态流转待开始 - 答题中 - 题目反馈 - 下一题 - 结算。整个游戏只维护一个 gameState 对象集中记录当前题号、当前得分、连续答对数、剩余秒数、题目列表。界面只有三个视图首页标题、规则说明、开始按钮、答题区线索卡片、选项按钮、倒计时条、得分面板、结算页得分、答对数、评级和重玩按钮。视图之间用 display 的 none 和 block 切换不做路由避免多余的复杂度。现在看这个决定非常值因为整个开发过程中我几乎没有遇到“改一个地方崩另一个地方”的连锁问题。2. 核心细节解析与实操要点2.1 鸟类题库的数据结构设计游戏好不好玩七成靠题库。我的题库最初只有 20 种常见鸟类后来扩展到 48 种。每条数据长这样{ id: 17, name: 白头鹎, clue1: 头顶有一小块白色羽毛像戴了顶白头巾, clue2: 常见于城市绿化带和果园叫声很勤快, clue3: 喜欢站在枝头连续鸣叫常成群活动, difficulty: 1 }这里有几个设计细节值得注意。一是每条线索都是“一句话能说完”的独立描述三条线索按从难到易排列玩家先看到最难的那条答不出来再点一下按钮多看一条这样难度是渐进的。二是名字选取的都是城市里真正能见到的鸟比如麻雀、乌鸫、珠颈斑鸠、白鹭、翠鸟这类确保玩家学到的知识在第二天下楼遛弯时就能验证。三是加了一个 difficulty 字段虽然第一版没用到但它为后续做难度分档留了口子。题目数据要避免两个坑一是名字别太长或太生僻像“黄腹山雀”这种五个字的还算行但“棕头鸦雀”对新手就有很强的挫败感二是线索不能出现选项里的名字比如正确选项是“喜鹊”线索里就不能写“拖着喜鹊般的长尾巴”否则等于把答案直接告诉了玩家。我后来专门写了一个校验函数跑一遍数据扫出所有“线索文本里包含任意选项名”的情况一把揪出了好几条不合格题目。2.2 出题算法与选项生成出题是核心环节直接决定游戏体验。如果每次都是同样的鸟玩两轮就腻了。我实现了一个“不重复优先”的抽题策略用一个数组记录本轮已经出过的鸟名每次抽题先从未出过的里面抽取等所有鸟都出过一遍才允许重复。这样保证 10 道题内不会出现重复题。选项生成也有讲究。四个选项中除了正确选项另外三个干扰项不能随便抽。如果正确选项是“翠鸟”干扰项里混进一个“麻雀”那这道题就太简单了但也不能都选外表相近的鸟那样新手容易直接崩溃。我的做法是“就近混搭”生成干扰项时优先从同栖息环境或相似体型的鸟类里挑比如正确答案是“白鹭”干扰项就用“苍鹭、夜鹭、池鹭”。如果不够四个再从全题库随机补。这样做出来的题目玩过的人普遍反馈“有思考的乐趣但不会想摔手机”。洗牌算法这里强烈建议用 Fisher-Yates 而不是数组自带的sort(() Math.random() - 0.5)后者在数据量小的时候分布不均虽然肉眼很难察觉但对想理清逻辑的人来说不够稳妥。实现也很简单function shuffle(arr) { for (let i arr.length - 1; i 0; i--) { const j Math.floor(Math.random() * (i 1)); [arr[i], arr[j]] [arr[j], arr[i]]; } return arr; }2.3 倒计时、计分与连击机制倒计时我踩过一个经典的坑第一版直接用 setInterval 每秒把数字减 1但浏览器切到后台时会暂停执行玩家切回来发现时间反而变多了甚至能钻空子无限思考。后来改成记录“截止时间”而不是“剩余秒数”正确答案后记一个deadline Date.now() 15000然后用一个每 100ms 跑一次的定时器去计算剩余时间这样即使浏览器卡顿或切后台回来补算也是准的。这个方案几乎成了倒计时的标准写法强烈推荐。计分规则上我设定了三档答对得 10 分连续答对 3 题以上时每道多加 2 分在 5 秒内快速作答额外加 3 分。这样设计是想奖励“又快又稳”的玩家让高手之间也能拉开差距。分数计算时把剩余时间和连击数都考虑进去逻辑集中在一个 updateScore 函数里避免多处分散改分数导致数据对不上。3. 实操过程与核心环节实现3.1 页面骨架搭建先把 HTML 的骨架写出来。我用语义化标签组织首页、答题区、结算页各用一个 section通过 CSS 类控制显示section idhome h1GameBird 鸟类问答/h1 p根据线索猜鸟名每题 15 秒10 题为一轮/p button idstartBtn开始游戏/button /section section idquiz classhidden div classprogress-bar span idtimerBar/span /div p idquestionNum第 1 / 10 题/p div idclueBox p idclueText/p button idmoreClueBtn再看一条线索/button /div div idoptions/div p idscore得分0/p /section section idresult classhidden h2 idfinalScore/h2 p idfinalDetail/p button idreplayBtn再来一局/button /section这里有几个细节值得说明。第一个是“再看一条线索”按钮这是我中途加的当玩家第一次没答出来可以点一下按钮多看一条线索但会扣 2 分。这个机制让游戏变得有策略性而不是单纯卡死。第二个是进度条我用了一个 div 的宽度百分比来表示剩余时间比单纯的数字直观很多玩家扫一眼就知道还剩多少不用专门读秒。3.2 样式与视觉反馈CSS 的重点不是“好看”而是“给玩家明确反馈”。我给自己定了三条规定答对时按钮变绿色并轻微上浮答错时按钮变红色并抖动倒计时最后 5 秒进度条变红并闪烁点击反馈与计分结果要在 1 秒内呈现不能让人等。很多小游戏做得糙不是因为功能不对而是因为反馈太弱玩家点完按钮屏幕几乎没变化第一反应是“我点到了吗”体验一下就凉了。卡片悬浮的阴影、按钮的圆角这些不是核心就不展开了。但有一点值得提我用了 CSS 变量统一管理颜色后续如果想换主题只改几个变量就行不用满文件替换色值。比如:root { --primary: #2d6a4f; --danger: #d62828; --correct: #2a9d8f; --bg: #f7f1e5; }这个习惯对任何前端项目都适用尤其是后期想上深色模式时省下的时间不是一点半点。答对答错的抖动动画也很简单直接在 CSS 里写 keyframes然后切换类名触发不需要引入动画库。3.3 核心逻辑编码我按“初始化和出题 - 玩家点击选项 - 判题和反馈 - 下一题或结算”的顺序写逻辑。核心部分代码如下const gameState { currentIndex: 0, score: 0, streak: 0, remaining: 15, questions: [], ans: null }; function startGame() { gameState.questions buildQuestions(10); gameState.currentIndex 0; gameState.score 0; gameState.streak 0; showQuestion(gameState.questions[0]); startTimer(); } function showQuestion(q) { gameState.ans q.name; document.getElementById(clueText).textContent q.clue1; const optionsHtml shuffle(q.options.map(opt button classopt>function startTimer() { gameState.deadline Date.now() 15000; if (timerId) clearInterval(timerId); timerId setInterval(() { const remain Math.max(0, Math.ceil((gameState.deadline - Date.now()) / 1000)); gameState.remaining remain; document.getElementById(timerBar).style.width (remain / 15 * 100) %; if (remain 0) { clearInterval(timerId); timeUp(); } }, 100); }这里用Math.ceil而不是Math.round有个细节如果剩余 14.2 秒ceil 会显示 15 秒round 会显示 14 秒相比而言 ceil 让玩家觉得“多赚了”零点几秒心理上更舒服。结算逻辑输出了得分、答对题数以及一个基于得分的评级S/A/B/C阈值我设成 120 分以上 S100 分以上 A80 分以上 B其余 C。评级没有复杂的计算但结算页一出来玩家能有个明确的目标去“刷 S”这就成了重玩一局的理由。4. 常见问题与排查技巧实录4.1 题目重复与选项答案泄露我第一版上线后自己玩了五局发现有两局的题目出现了重复的鸟而且正确答案的按钮在某种情况下会提前高亮。排查了半天才发现问题出在两个地方一是buildQuestions里用了 splice 修改原数组没留意历史状态导致抽到重复项二是 CSS 里写了一个button:last-child的样式恰好在四个选项中最后一个选项是正确答案时视觉上会有微妙差异精明的玩家几次就能摸出规律。这个教训很典型小游戏里任何无意的视觉差异都会被玩家利用不管是有意还是无意。解决方式就是统一按钮样式去掉:last-child这种特殊样式同时保证抽题逻辑是无状态的。4.2 定时器跑飞与内存泄漏还有一个问题发生在玩家连续点“开始游戏”时旧的定时器没有清理新的又开了一个结果两个定时器同时跑倒计时变成两倍速一局游戏 7 秒就结束了。这个问题的根源是startTimer没有在开头clearInterval。所以后来我养成一个习惯每次创建定时器之前先清理上一次的定时器写在函数的第一行不管是不是真的需要这个动作都不会错。另外答题反馈的setTimeout也要存起来防止玩家在 1 秒反馈期间疯狂点击按钮触发多个定时器导致题目跳着走。4.3 移动端适配与字体问题我做这个游戏的时候优先照顾手机屏幕但在真机上发现了两个问题第一iPhone 的 Safari 会对小于 16px 的字体自动放大导致布局错乱解决方法是把 html 的 font-size 设置得明确一些并适当调大所有交互元素的字号第二按钮的点击触发有 300ms 延迟我引入了 CSS 的touch-action: manipulation来解决。当然如果只是在现代桌面浏览器上玩这些都不是大问题但是要面向用户分发的话这些细节就得处理不然很容易被一句“手机上打不开”打回来。4.4 状态管理混乱加功能前的教训我在开发中途加了一个“提示”功能想着很简单就是多一个按钮的事。结果改的时候发现因为初始代码里把扣分逻辑散落到了四个不同的地方加上提示功能后分数变得对不上一局下来能算出负分。后来花了一个晚上把分数、连击、当前题号全部收敛到gameState里每个操作只做一件事视图层只从gameState读取数据这才把问题根治。从那以后我给自己定了一个规矩凡是和状态有关的逻辑必须集中在一个对象里别让状态满天飞。这个教训也直接影响了后面的项目我现在写任何小工具都会先想清楚状态在哪里流动再做界面。做完这个项目我最大的感受是小游戏开发最容易忽略的不是图形和音效而是“状态流”和“时间处理”这两件看不见的事。game-bird 的代码到现在已经迭代了三个版本最近我正在给它加一个基于 localStorage 的本地排行榜还想把题库扩充到 100 种鸟。如果你也想拿它练手建议你先别急着加花哨功能把主体问答流程跑顺再考虑扩展。真到了那一步你会发现之前打的底子越干净后面加功能越省心。