一个人做了42个HTML5小游戏，零后端零依赖，源码全开源

## 起因

前阵子我在做在线工具站，Astro + React 那套，纯前端 SSG 部署到 GitHub Pages。某天晚上改完 bug 刷推放松，看到有人聊"HTML5 小游戏站还能不能做"——不是那种满屏弹窗广告、套壳 Unity 老游戏的站，是正经的、开箱即玩、手机也能跑的轻量游戏集合。

我当时的第一反应是：这不就是工具站的变种吗？

工具站解决的是"我有一个具体任务要完成"，游戏站解决的是"我想摸五分钟鱼"。两者都是即来即用、不需要注册、不需要下载。区别只是工具站留住人靠的是功能刚需，游戏站靠的是玩法本身。

越想越觉得可以试。手里正好有 GitHub Pages 的部署基建，域名也是现成的。于是挑了个周末开始动手。

## 技术选型：为什么是纯 HTML5 而不是 React + 引擎

这一步纠结了大概十分钟。

最初的想法是上 Phaser 或者自己搭 React 组件化开发。但冷静下来算了一笔账：

- 42个游戏，如果每个都走框架，bundle 体积爆炸，首屏加载慢，移动端体验差
- 小游戏的逻辑都很简单，俄罗斯方块的核心逻辑不到 300 行 JS
- 用框架的最大收益是组件复用和状态管理，但每个游戏的 UI 和状态都不一样，复用率其实很低
- GitHub Pages 是静态托管，没有构建步骤的话连 CI 都省了

最终决定：**每个游戏一个独立 HTML 文件，HTML + CSS + 原生 JS，零依赖零构建零后端**。

听起来很土，但实测下来这是对的选择：

- 单个游戏文件 5-15KB，首屏秒开
- 没有打包过程，改完刷新就能看效果，开发反馈极快
- 每个游戏完全独立，改一个不会影响其他，调试完全没有心智负担
- SEO 友好，每个游戏就是一个独立 URL，title/description/schema 完全独立可控

唯一的代价是公共部分（头部导航、样式、i18n 脚本）有些重复，但用共享 CSS 和一个 i18n.js 就解决了，不算大问题。

## 42个游戏是怎么选出来的

不是拍脑袋选的。先定义了三条筛选标准：

1. **能在浏览器里 3 秒内理解规则**——复杂规则的游戏直接 pass，没人会在摸鱼的时候看教程
2. **单文件可实现**——如果一个游戏需要资源管理器、关卡编辑器、多场景切换，那它不适合这个形态
3. **有 replay value**——能反复玩而不腻，而不是通关一次就想关掉

基于这三条，从经典街机（贪吃蛇、俄罗斯方块、打砖块）、棋牌策略（四子棋、黑白棋、五子棋、尼姆）、解谜（数独、扫雷、推箱子、点灯）到反应类（Flappy、打地鼠、反应测试）挑了42个。

选型的时候有个意外发现：经典游戏之所以经典，正是因为它们满足上面三条。50年前的游戏设计原则，放到今天的浏览器里依然成立。这不是怀旧，是这些游戏经过了几十年的人类筛选，留下的都是精华。

## AI对手：从"能玩"到"有挑战"

带AI对手的游戏一共8个：四子棋、五子棋、黑白棋、贪吃蛇、乒乓、尼姆、井字棋、猜拳。

早期版本的AI都很弱，属于"能对弈但随便赢"的水平。后来逐个加强：

- **四子棋**用 Minimax + Alpha-Beta剪枝，深度4，配合启发式估值函数。胜负判定要检查横竖正斜反斜四个方向，写的时候最容易漏的是反斜对角线。
- **五子棋**同理但搜索空间更大，加了威胁检测（活三、冲四必防）
- **黑白棋**最绕的不是AI而是规则——一方无棋可走时要pass，两边都没棋才结束。第一版写错了，导致某一局卡死
- **尼姆**有数学最优解（Nim-sum异或和），但Misère变体（拿最后一根的输）的残局策略和标准版不同，需要特殊处理

有意思的是，写完AI之后发现一个反直觉的事：**AI不需要太强**。四子棋深度4的AI已经能让大多数人输赢参半，再强反而劝退玩家。游戏AI的目标不是赢，是让玩家觉得"再来一把我能赢"。

## 商标这件事

做到一半才意识到一个坑：好几个游戏的名字是注册商标。

Tetris是俄罗斯方块公司的、Wordle是NYT的、Space Invaders是Taito的、Pong是Atari的。哪怕你是免费小游戏，商标持主理论上可以发C&D（Cease and Desist）。对于网页站可能无所谓，但如果将来想上小程序/App Store，商标扫描会直接卡审。

于是花了半天把12个有风险的游戏全部改名：

- Tetris → Block Drop
- Wordle → Word Guess
- Space Invaders → Alien Invasion
- Pong → Paddle Ball
- Flappy Bird → Flap Dash
- Hangman → Word Rescue
- ……（共12个）

改名不是简单换个标题，要同步改 HTML title、meta description、canonical、JSON-LD schema、首页卡片、i18n 词典，漏一个就会出现"标题对了但schema里还是旧名"的情况，被搜索引擎抓到反而扣分。

## 中英双语：一个不优雅但有效的方案

做工具站时积累的双语经验直接用上了。方案很朴素：

- 一个 `i18n.js` 脚本，支持两种翻译方式：全局词典（`data-i18n="key"`）和属性级双语（`data-i18n-en="..." data-i18n-zh="..."`）
- 右上角语言切换按钮，localStorage记忆偏好
- 英文为默认（SEO主力），中文可切换

不优雅的地方在于：游戏内JS动态生成的文本（比如"Game Over"、"You Win"）需要手动调 `I18N.get()` 取当前语言。42个游戏改下来，有十几个遗漏点，都是逐个测试才发现的。

为什么这么麻烦还要做双语？因为流量来源是双线的：Google搜英文来的是海外流量（AdSense RPM高），百度搜中文来的是国内流量（用户体验好）。单站双语比建两个站省一半维护成本。

## 对抗"看不懂怎么玩"

上线前做了一轮全站审查，重点排查一个事：**用户能不能在3秒内看懂怎么操作**。

发现的问题比预期多：

- 推箱子只有键盘控制，手机完全没法玩 → 加了触摸滑动
- 四子棋点哪列棋子落到最底下，但因为没有视觉反馈用户以为点错了 → 加了列高亮和落点预览
- 乒乓球AI太弱，球还可能水平移动导致无限回合 → 调了AI追踪和球速下限
- 寻词游戏有概率出现单词放不进去但还显示在列表里，导致永远无法通关 → 只统计成功放置的词
- 青蛙过河有个逻辑漏洞：青蛙可以站在水面上不死亡 → 修复了判定
- 猜词游戏词库只有30个技术词（javascript、kubernetes……），非技术用户根本玩不了 → 扩到120+个多主题词

这些问题自己测的时候不会发现——因为你写了代码，你当然知道怎么玩。只有"假装不知道规则"去审视，才会发现那些"对开发者来说显而易见但对外人来说不直观"的地方。

这也是纯前端小游戏站的一个隐性优势：**改起来快**。上面这些问题，每个的修复时间都在10分钟以内。如果是框架项目，改一个交互逻辑可能涉及组件通信、状态更新、重渲染，半小时起步。

## 部署和成本

零成本。

- 代码托管：GitHub
- 部署：GitHub Actions 自动构建 → GitHub Pages
- 域名：`games.hypergrad.cn`，CNAME 指向 GitHub Pages，HTTPS 自动签发
- DNS：一条 CNAME 记录
- 服务器：无

整个站的运营成本就是域名的几十块钱一年。没有数据库、没有后端、没有 API 调用——纯前端意味着流量再大也不花一分钱服务器费。

唯一需要花钱的地方是域名续费。对，就这么省。

## 上线之后

目前还在等搜索引擎收录。SEO 基建都做好了：每个游戏页有独立的 title/description/canonical/JSON-LD，sitemap 43个URL已提交，robots.txt 配置完毕。

百度对新站有沙盒期，通常要等几天到两周才放出来。Google 收录快一些但排名需要养。AdSense 申请需要站点有一定内容量和流量，42个游戏的内容量应该够了。

下一步的计划是观察搜索词数据，看哪些游戏有搜索流量，再针对性地补充同类游戏。工具站的经验告诉我：**不要凭感觉猜用户会搜什么，要看数据**。

## 如果你也想做

整套技术栈的门槛非常低：

- 会写 HTML/CSS/JS 就能开始
- 不需要框架知识
- 不需要后端
- 不需要数据库
- 不需要服务器

需要的只是耐心——42个游戏，每个从开发到调好AI到写好双语说明，平均一个半小时。不是难，是量大。但正因为量大，做完之后你会有一个相当扎实的产品。而且每个游戏都是独立的，可以随时往里加新的。

网址在下面，手机电脑都能直接玩，不注册不下载不弹窗：

**games.hypergrad.cn**

---

*作者：HyperGrad，独立开发者，专注纯前端工具与游戏站。其他项目：hypergrad.cn（在线工具站集群）。本文首发于CSDN，掘金/知乎同步更新。*