将一个 Web 项目从“能用”变成“人们喜欢使用”的产品之间存在巨大差距。

在开发 Test Merkezim 时，我最初的目标非常简单：构建一个快速平台，让用户无需注册即可在浏览器中评估自己的认知能力并玩智力游戏。

但随着项目规模扩大，我意识到工作远不止展示题目或开发几款游戏那么简单。用户流程、移动端适配、分数安全、游戏难度和页面性能与游戏本身同样重要。

本文将分享我在项目过程中遇到的核心问题及收获的经验。

让用户进入测试的流程应尽可能简短

最初的设计中，用户需在首页点击按钮 → 进入测试介绍页 → 再次点击“开始” → 然后在姓名输入页再次点击“开始测试”，总共需要重复三次相同操作。

虽然技术上可行，但对用户而言这是不必要的重复。

因此我移除了中间的介绍步骤。现在用户从首页进入测试后，可直接（或自愿填写姓名后）开始答题。

这一改动再次印证了一个简单道理：

每次额外的点击都给用户提供了放弃的机会。

如果一个页面并非必需，删掉它往往比把它做得更漂亮更有效。

为什么选择 PHP 和 Vanilla JavaScript？

项目运行在共享主机上，我希望保持轻量，因此没有使用大型框架或复杂的构建流程。

整体技术栈如下：

  • 服务端：PHP
  • 游戏逻辑：Vanilla JavaScript
  • 通用头部、页脚、音频和排行榜组件：PHP 片段
  • 分数与游戏数据：服务端 API
  • 页面专属 HTML、CSS 与 JavaScript

这种方式最大的优势是部署简单：更新文件可直接上传，无需安装依赖。

缺点是如果不合理拆分公共组件，重复代码会出现在不同游戏中。因此我只把真正共享的部分提取到公共文件，游戏专属逻辑仍保留在各自页面。

一款智力游戏本质上是一个小型状态机

开发游戏时容易把精力放在视觉设计上，但真正困难的是正确管理所有游戏状态：

  • 游戏开始前哪些按钮可用？
  • 如何处理非法操作？
  • 撤销操作是否影响分数或步数？
  • 刷新页面后能否从中断处继续？
  • 游戏结束后是否禁止新输入？
  • 触屏与鼠标是否表现一致？

以“连线谜题”为例，玩家需用一条连续线条填满所有格子，并按正确顺序连接带编号的点。

在桌面端长时间按住鼠标会很疲劳，因此我增加了“点击同一行/列的远端格子时自动填充中间有效格子”的功能。规则未变，但操作更舒适。

这个小改动在不降低难度的前提下减少了操作摩擦。

难度不只由棋盘大小决定

最初我以为减少编号点的数量就能自动提升难度。但过多点位也会把路径限制在更多强制检查点上，反而可能增加某些谜题的解题负担。

因此我采用了一种混合机制：

  • 棋盘尺寸从 5×5 逐步增加到 8×8。
  • 同一尺寸下点位密度会周期性升降。
  • 在较高关卡中混合使用 3 至 9 的不同密度。
  • 每七关完整遍历一次所有密度。
  • 禁止相同点位数量连续出现。

这样玩家无法提前预测下一关的结构。程序化生成不仅需要随机性，更需要受控的多样性，才能得到更均衡的体验。

不能信任客户端提交的分数

浏览器游戏的全部逻辑对用户可见且可修改，因此仅接受 JavaScript 上报的分数是不安全的。

服务端必须实施以下验证：

  • 白名单校验游戏 ID
  • 检查该游戏允许的难度范围
  • 为每款游戏设定合理的分数区间
  • 拒绝不切实际的完成时间
  • 按玩家或 IP 限制提交频率
  • 写入排行榜前清洗数据

在休闲游戏平台上把所有游戏在服务端重新模拟成本过高，但几项低成本校验就能阻止大部分自动作弊。

核心原则非常明确：

客户端负责用户体验，服务端决定数据是否可接受。

移动端体验不应是后期添加的功能

由于大部分游戏在手机上进行，仅把桌面设计缩小是不够的。

移动端需要单独考虑：

  • 游戏区域随屏幕宽度自适应
  • 控制按钮、步数和计时器不被遮挡
  • 触控目标足够大
  • 文字与图标对齐
  • 下拉菜单不超出屏幕
  • 滚动操作不与游戏操作冲突

响应式设计不只是使用 width: 100%，还需要决定内容展示顺序和用户手指可触达的位置。

性能优化不需要大型基础设施

我在性能方面采取的简单措施包括：

  • 字体从本地服务器加载而非外部服务
  • 大图转为 WebP 格式
  • 首屏以下图片懒加载
  • 保持公共 CSS 文件精简
  • 避免不必要的 JavaScript 库
  • 为图片指定宽高属性
  • 首屏不需要的资源延迟加载

这些优化单看很小，但在移动网络环境下累积效果非常明显。

SEO 与用户体验不可分割

为搜索引擎准备内容时，容易把同一信息重复展示在不同区块中。

我采用的更健康做法是：

  • 每页使用一个清晰的主标题
  • 页面内容直接回答搜索意图
  • 可见内容与结构化数据保持一致
  • 相似页面间标题保持一致
  • 不让用户在不必要的介绍页停留
  • 在游戏下方真正解释规则与机制

目前项目提供无需注册的 IQ 测试、即时结果页面，以及聚焦不同能力的浏览器端智力游戏。

同时明确说明在线测试不能替代专业或临床评估，这也是可信产品沟通的重要组成部分。

本项目的主要经验总结

开发过程中我学到的最重要几点如下：

  1. 能用的用户流程不等于好的用户流程。
  2. 随机生成若不受控，无法产生均衡的难度。
  3. 移动端控制需与桌面端分开设计。
  4. 客户端提交的任何分数都不可直接信任。
  5. 微小的性能优化累积起来能产生巨大差异。
  6. SEO 内容若不能真正回答用户问题，再长也无用。
  7. 留住玩家的不仅是难度，更是不断变化的体验。

随着项目继续发展，我将持续改进游戏机制、分数系统和无障碍选项。

您在浏览器游戏中如何管理游戏状态与程序化难度？欢迎在评论区分享您的经验。