1. 一个念头怎么变成一份可执行的需求文档
先说一个很多新人容易忽略的事实：做游戏最难的不是写代码，而是把脑子里那个模糊的“好玩”变成一个具体到能动手的东西。
我当时的念头特别简单——想做一个不用下载、打开浏览器就能玩的小游戏，能自己一个人从零搞定，最好还能让朋友点开链接就直接玩。这个念头听起来很美好，但它真正落地之前，我花了整整两天时间在纸上折腾需求，而不是写代码。
第一步是做减法。一个人开发最忌讳的就是贪多，我原本给自己列了一堆功能：排行榜、账号系统、皮肤商城、每日任务、成就系统……后来全部砍掉，只保留了一个最核心的玩法循环。我当时给自己定了一条硬性原则：如果去掉某个功能，游戏的核心乐趣不受影响，那就去掉它。
最终我锁定的方向是“打砖块”。为什么选它？因为它的核心机制足够简单——挡板接球、球撞砖块、砖块消失、清空过关。这个循环足够自洽，不用复杂的剧情、不需要数值策划、不会有大量的资源需求，一个人完全能驾驭。
需求文档里我写下了这样几个关键定义：
- 核心操作：鼠标或键盘控制挡板左右移动
- 胜利条件：消灭所有砖块
- 失败条件：球落到底部，生命值扣完
- 单局时长：控制在3到5分钟，碎片时间能来一局
- 关卡变化：砖块排布方式改变，球速逐关递增
这些定义看着不起眼，但它们是后面所有开发工作的锚点。没有这些锚点，开发过程中你会不断冒出“再加个功能吧”的念头，然后项目就永远不会上线。
需求确定之后，我估算了一下工作量。按我下班后和周末能投入的时间来算，从零到上线大概需要四到六周，这也成了我的整体节奏规划。写代码反而是其中占比最小的一块，更多的精力花在资源准备、测试和上线配置上面。
2. 技术选型为什么用了最“无聊”的方案
这个章节我想先聊聊技术路线的问题，因为它直接决定你后面会不会被各种莫名其妙的问题折磨到崩溃。
我的技术选型非常朴素：HTML5 Canvas做游戏渲染，原生JavaScript写游戏逻辑，Node.js加Express搭一个静态服务器，Nginx做反向代理，部署在一台便宜的云服务器上。数据库？不需要。框架？React和Vue我都没碰。构建工具？Webpack和Vite也省了。
可能有人会觉得这太“原始”了，但我必须说，对于一个人开发的轻量级网页游戏，这恰恰是最稳的方案。
我解释一下每个选择的逻辑：
第一次选择是渲染方案。游戏行业里现在流行用Unity、Godot导出WebGL版本，但那样做出来的包体动辄几十MB，加载体验并不好。而且Unity的WebGL打包产物对服务器配置有要求，部署也会更复杂。用Canvas意味着我需要自己处理游戏循环、碰撞检测、渲染帧率这些基础问题，工作量会多一些，但换来的是极致的轻量——整个游戏所有文件加起来不到200KB，首次加载基本上瞬间完成，这种体验是重型引擎很难给你的。
第二次选择是不用任何JavaScript框架。框架擅长的是管理复杂的UI状态，而我的游戏核心是一个每帧更新的Canvas画布，需要的是对渲染流程的精确控制。如果硬套框架，反而需要在框架的生命周期和游戏循环之间做额外适配。原生JavaScript在这个场景下反而更直接、更可控。
第三次选择是服务器方案。为什么不用更流行的云开发平台或者Serverless？因为我想要一个足够简单、足够可控的部署环境。一个Node服务加Nginx静态托管，逻辑非常透明，出问题了我能很快定位。Serverless虽然免运维，但冷启动、计费规则这些对一个小游戏来说有点过度设计。
关于代码组织，我也没有用什么复杂的架构模式，就用了一个最直观的分层方式：
// 游戏入口和主循环 // src/ // ├── index.html // 页面骨架 // ├── style.css // 全局样式，包括Canvas的布局 // ├── game.js // 游戏主循环，requestAnimationFrame驱动 // ├── entities.js // 挡板、球、砖块的实体定义 // ├── physics.js // 碰撞检测与物理逻辑 // ├── levels.js // 关卡数据，每关砖块的排布 // └── audio.js // 音效管理，Web Audio API生成这套初始代码是线下用file://协议直接双击HTML文件来调试的，根本没有起本地开发服务器，因为游戏里不需要发网络请求，不存在跨域问题。直到最后要上线了，我才去折腾服务器。
这个方案确实不够“酷”，但它帮我避开了几乎所有与工具链和框架相关的坑。整个开发过程中，我没有花一天时间在处理依赖冲突、编译报错或者框架版本升级这些破事上，全部精力都集中在游戏本身。
3. 核心玩法与程序骨架：先让小球动起来
我的开发顺序是先从最核心的玩法循环开始的。第一步不是写砖块，也不是写挡板，而是让一个小球在Canvas上动起来。别小看这一步，整个游戏的灵魂都在这个移动逻辑上。
3.1 游戏循环：每一帧发生了什么
Canvas游戏的基本逻辑非常简单，就是不断重复“清屏、更新、绘制”这三个动作。我用requestAnimationFrame来驱动这个循环，它比setInterval好在能跟显示器刷新率同步，实现60FPS的平滑动画。
let lastTime = 0; function gameLoop(timestamp) { const deltaTime = (timestamp - lastTime) / 1000; lastTime = timestamp; update(deltaTime); // 更新所有实体的位置和状态 render(); // 绘制当前帧的画面 requestAnimationFrame(gameLoop); } requestAnimationFrame(gameLoop);这里有个很重要的细节：deltaTime。如果你不做帧率适配，游戏在60Hz和144Hz的显示器上运行速度会差出一大截。用deltaTime把位移换算成“每秒移动多少像素”，就能保证不同刷新率的设备上游戏速度一致。
球的移动逻辑就是最简单的匀速直线运动，加上碰到边界后的反弹。反弹的本质就是把速度向量的某个分量取反：撞到左右墙，x方向速度取反；撞到上墙，y方向速度取反。这段代码很短，但它涉及到一个新手很容易做错的地方——每帧位移必须和deltaTime相乘，否则游戏速度会漂移。
3.2 碰撞检测：从“大概碰到”到“精确碰到”
接下来的重头戏是碰撞检测。有不少教程会让你用坐标间的“约等于”来判断碰撞，但那种方式在球速较快的时候会出问题——球可能从砖块中间穿过去而不被检测到。
我用的方式是AABB碰撞检测，也就是轴对齐包围盒检测。简单说，就是把每个物体看作一个矩形，判断两个矩形是否有交集。判断逻辑是：
function checkCollision(rect1, rect2) { return ( rect1.x < rect2.x + rect2.width && rect1.x + rect1.width > rect2.x && rect1.y < rect2.y + rect2.height && rect1.y + rect1.height > rect2.y ); }这个函数的核心逻辑是判断两个矩形在x轴上投影是否重叠，在y轴上投影是否重叠，两者都重叠才算碰撞。就好比两列队伍横向看过去没有交集，纵向看过去也没有交集，那它们肯定不在同一个位置。
真正让我纠结的是碰撞后怎么反弹。如果只简单地把y速度取反，会导致一个体验问题：球碰到砖块下边缘时，仍然会继续往上走，看起来就像球“穿模”了一下。我处理的方式是判断碰撞点相对于砖块中心的位置，根据碰撞的方向来决定反转x还是y速度。这个细节直接决定了手感，值得花时间去调。
挡板的碰撞我做了额外处理，没有用统一的反弹角度。当球撞到挡板时，反弹角度由球击中挡板的位置决定——击中最左侧，球就向左上方飞；击中最右侧，就向右上方飞。这个设计让玩家可以通过移动挡板来控制球的走向，游戏的策略性一下子就出来了。这是整个开发过程中最早加入的一个让游戏“好玩”的机制，成本极低，效果立竿见影。
3.3 帧率与性能：30FPS就不流畅吗
关于性能我想说一句公道话：对于这种2D小游戏，性能问题几乎不应该存在，但如果出现了，多数是开发过程中自己制造出来的。
最常见的问题是每帧都去操作DOM或者创建新对象。Canvas绘制本身很高效，但如果你在render函数里频繁document.createElement或者触发重排，那性能会急剧下降。我的做法是：所有砖块在游戏初始化时生成一次，存进数组，之后每帧只更新它们的位置和状态，不重新创建结构。
另一个很容易被忽略的问题是Canvas的像素比适配。在Retina屏幕上，如果不做适配，画面会发虚。处理方式是把Canvas的实际尺寸设置为CSS尺寸乘以window.devicePixelRatio：
const dpr = window.devicePixelRatio || 1; canvas.width = canvas.clientWidth * dpr; canvas.height = canvas.clientHeight * dpr; ctx.scale(dpr, dpr);这段代码让我免于在高分屏上游戏画面模糊的尴尬。
4. 游戏逻辑的层层递进：挡板、砖块、关卡与音效
核心循环跑通之后，接下来就是往这个骨架里填充实体和逻辑。我按“挡板 → 砖块 → 关卡 → 音效”的顺序来推进，每一步都建立在已有的代码之上。
4.1 挡板控制：一个像素级别的反馈体验
挡板是这个游戏里玩家唯一的控制对象，它的跟手程度直接决定了游戏的好坏。我用了两种输入方式：鼠标控制和键盘控制。
鼠标控制的逻辑简单直接：监听mousemove事件，将鼠标的x坐标减去挡板宽度的一半，作为挡板的中心x坐标。
canvas.addEventListener('mousemove', (e) => { const rect = canvas.getBoundingClientRect(); const mouseX = e.clientX - rect.left; paddle.x = mouseX - paddle.width / 2; });这段代码里有个细节：e.clientX是相对于浏览器窗口的坐标，而Canvas在页面上可能不在左上角，所以需要用getBoundingClientRect().left计算出Canvas相对视口的偏移，再做减法。这个偏移如果忘了处理，在多窗口环境下挡板位置就会错位。
键盘控制则是监听keydown和keyup事件，维护一个按键状态对象。这里比较合理的做法是每帧根据当前按键状态计算移动方向和速度，而不是在按键事件里直接修改挡板位置，否则会出现按键延迟和重复触发的问题。
const keys = {}; document.addEventListener('keydown', (e) => { keys[e.code] = true; }); document.addEventListener('keyup', (e) => { keys[e.code] = false; }); // 在update函数里 if (keys['ArrowLeft']) { paddle.x -= paddle.speed * deltaTime; } if (keys['ArrowRight']) { paddle.x += paddle.speed * deltaTime; }挡板移动范围需要限制在Canvas边界内，否则挡板会跑出屏幕。这里用Math.max和Math.min做钳制，是很基础但很实用的技巧。
4.2 砖块数据结构与血量系统
砖块的实现比想象中复杂一点。我一开始以为砖块只是一个矩形数组，写到后面才发现需要为它赋予更多属性：坐标、宽高、颜色、血量、是否已经消失。
我定义了一个砖块生成函数，根据关卡配置生成不同排列的砖块：
function createBricks(levelConfig) { const bricks = []; const rows = levelConfig.rows; const cols = levelConfig.cols; const brickWidth = 60; const brickHeight = 20; const gap = 5; const offsetTop = 60; const offsetLeft = (canvasWidth - (cols * (brickWidth + gap) - gap)) / 2; for (let row = 0; row < rows; row++) { for (let col = 0; col < cols; col++) { bricks.push({ x: offsetLeft + col * (brickWidth + gap), y: offsetTop + row * (brickHeight + gap), width: brickWidth, height: brickHeight, hp: levelConfig.hpPattern ? levelConfig.hpPattern[row] : 1, color: levelConfig.colors ? levelConfig.colors[row % levelConfig.colors.length] : '#ff6b6b', alive: true }); } } return bricks; }血量系统的加入是我一个人开发时觉得产品感增强很关键的一步。原本所有砖块都是一击即碎，玩起来单调。我后来给某些行砖块设置了2点甚至3点血量，球撞上去颜色会变淡一档，玩家能直观地感觉到“这块砖更硬”。同时，这种小设计不需要额外的美术资源，仅靠颜色变化就能传达信息，非常适合单人开发。
砖块消除的判定是在碰撞检测之后进行的：砖块受到碰撞后血量减1，血量归零则alive设为false。渲染时直接跳过alive为false的砖块。这里有个性能细节：与其每帧遍历所有砖块做渲染判断，不如在砖块消失时把它从数组中移除。但为了保留继续判断碰撞的可能性，我采用了alive标记的方式，这是为了后面做连击特效时方便拿数据。
4.3 关卡设计的巧劲：只用数据就做出新鲜感
关卡方面我花了相当多的时间。很多人以为做关卡就是写一堆排布数据，但真正麻烦的是如何让玩家觉得“有趣”。我给自己定下的原则是：每一关至少引入一个新鲜的变量，但绝不超过两个。
第一关最简单的十字形排列，砖块密集，球速慢，让玩家建立基本的操作感觉。第二关开始出现血量更高的砖块，打起来需要多几次反弹。第三关球速加快，砖块排成了菱形，这要求玩家对反弹角度有预判。第四关开始出现“死区”，即最高层砖块之间有缝隙，球容易从缝隙飞出去，玩家需要控制挡板来防止球飞出太多。
这些关卡逻辑其实都很轻，我不需要做很复杂的关卡编辑器，只需要在levels.js里写一个配置数组：
const levels = [ { rows: 4, cols: 8, hpPattern: [1, 1, 1, 1], colors: ['#ff6b6b', '#ffd93d', '#6bcb77'], ballSpeed: 300 }, { rows: 5, cols: 8, hpPattern: [1, 2, 1, 2, 1], colors: ['#ff6b6b', '#ff9f43', '#ffd93d', '#6bcb77'], ballSpeed: 350 }, // ... ];配置化的好处是，想调关卡只需要改数据，完全不用动游戏逻辑。我后面加一个新关卡，从构思到测试通过，一般也就半个小时。
4.4 音效：没有音乐文件的音乐系统
音效这部分是很多人会忽略的，但我觉得它恰恰是游戏“觉得专业”和“觉得业余”的分水岭。一个人开发游戏不可能去找音频素材，也没钱去买授权，我的方案是用Web Audio API直接合成音效。
function playTone(frequency, duration, type = 'square', volume = 0.3) { const audioCtx = new AudioContext(); const oscillator = audioCtx.createOscillator(); const gainNode = audioCtx.createGain(); oscillator.type = type; oscillator.frequency.value = frequency; gainNode.gain.setValueAtTime(volume, audioCtx.currentTime); gainNode.gain.exponentialRampToValueAtTime(0.001, audioCtx.currentTime + duration); oscillator.connect(gainNode); gainNode.connect(audioCtx.destination); oscillator.start(); oscillator.stop(audioCtx.currentTime + duration); }打球时播放一个短促的440Hz方波，消除砖块时播放880Hz的上升音，砖块血量下降时播放更短促的660Hz音。这一套听起来简陋，但因为音量小、时长短，在游戏里反而有不错的反馈效果。唯一需要注意的是AudioContext的创建要放在用户点击之后，否则浏览器会阻止自动播放的声音。我在打开游戏时先显示了一个“点击开始”的按钮，这既是游戏开始动画，也是音频上下文的初始化时机，一石二鸟。
5. 美术资源的取舍：代码即美术的极简路线
美术是整个项目里对我来说最痛苦的部分。我不是美术出身，画画功底约等于零。在这个问题上，我的策略是：不是让游戏看起来好看，而是让游戏看起来“统一”。
统一比好看更重要。如果一个游戏的风格本身是简约几何风，那它看起来就自然、协调，不会有人觉得简陋；但如果你一会儿用几何图形，一会儿又塞进一个手绘风格的素材，那才会显得粗糙。
我的色彩方案完全从一个工具来：Coolors。这是一个在线配色工具，我选了几个看上去舒服的色板，然后用到游戏里。整套游戏的色调是深蓝背景、白色挡板、彩色砖块，颜色饱和度控制在中高水平，内容辨识度很强。
代码层面的“美术”我给每个元素加了点简单的视觉反馈，让小动作看起来不那么干瘪：
- 挡板是圆角矩形，颜色偏白，和背景形成对比
- 球带一点渐变和拖影效果，拖影是用一个半透明的大球画在球后面，看起来就有速度感
- 砖块被击中时有一个0.1秒的闪白效果，给玩家“打中”的反馈
- 砖块消失时会分裂成几个小碎片四散飞出，这是用小粒子的效果做出来的
这些视觉效果每个都不复杂，加起来之后对体验的提升非常明显。尤其是砖块的碎片效果，我不需要额外的美术资源，只需要在砖块消失时创建几个速度方向不同的小矩形，每帧更新它们的位置并逐渐缩小，最后移除。这个效果让游戏的打击感好了不少。
我还花了一点时间调整了当时的背景。一开始背景是纯色的，后来我加了一些缓慢移动的渐变光斑，用ctx.createRadialGradient实现。这个背景看起来好像是花了心思做的，其实也就二十几行代码，性能开销也极低。但它给整个游戏的观感提升了一个档次，同样属于“低成本高回报”的投入。
字体方面我用的是Google Fonts里的一款像素风字体，叫Press Start 2P。这个字体用在标题和分数上非常出效果，但它不适合正文，所以页面上的提示文字我还是用系统默认字体。字体文件通过CDN加载，页面上的资源加载时间会增加一点点，但换来的是和游戏氛围很搭的界面风格。
如果你的审美判断力比我还薄弱，我推荐一个笨办法：找一款你喜欢的极简风格游戏，截几张图，分析它的布局、配色和字体，然后照着这个方向去调。不一定要抄，但要搞清楚那个游戏为什么看起来舒服。绝大多数情况下，答案就是“元素克制+配色统一”，而不是堆砌素材。
6. 测试与调试：一个人如何逼疯自己然后自愈
测试是一个人在开发时最容易敷衍的环节。你可能觉得“反正就我一个人写，逻辑我自己清楚，试两把没问题就上线吧”。我劝你千万不要这样，上线的游戏一旦出现低级Bug，带来的负面口碑会远超你节省下的那点测试时间。
我的测试分成了三层，每一层都有不同的侧重点。
6.1 功能测试：把常见问题列成清单
首先是功能测试，我把游戏里的每个交互都列成了清单：
- 点击开始按钮能进入游戏
- 鼠标移动控制挡板正常
- 键盘左右键控制挡板正常
- 球撞到挡板后反弹角度符合预期
- 球撞到砖块后分数增加
- 砖块血量减少到0后消失
- 所有砖块消失后出现胜利界面
- 球落底后生命值减1
- 生命值归0后出现失败界面
- 重玩按钮能重新开始游戏
- 音效是否在对应操作时播放
- 屏幕窗口缩放时Canvas是否自适应
这份清单看起来简单，但真的帮我发现了一个问题：窗口缩放时，Canvas的尺寸变了，但我的游戏逻辑里球的坐标用的是旧尺寸，导致球在缩放后飞出屏幕。解决方式是在window.resize事件里重新计算Canvas的尺寸和球的位置。
6.2 DevTools调试技巧：断点、日志、性能面板
调试过程中我用了不少DevTools的技巧，这些技巧是平时写业务代码时锻炼出来的，在游戏调试里同样好使。
最重要的一条：把游戏逻辑中的关键变量以可视化的方式输出到页面上。我在调试阶段做了一套调试面板，在Canvas上方悬浮显示球的速度、挡板坐标、当前帧率。这样在做手感调优时，我能直观地看到每个参数对游戏的影响，不用来回读代码。
另外我特别推荐Chrome DevTools的Performance面板。游戏卡顿时，录制一段性能日志，看看到底是哪段函数消耗了大部分时间。我遇到过一次莫名的卡顿，用Performance面板定位后发现是资源加载时导致的，不是游戏逻辑的问题，这帮助我放下了对游戏代码性能的怀疑。
断点调试也是值得说一说的。很多时候游戏逻辑里的Bug不会报错，只是行为不对。比如球打到一个角落的砖块时直接飞出了屏幕外，这种问题靠看日志很难定位。我的做法是在碰撞检测函数里加断点，逐步执行看球的位置和砖块的位置是否符合预期。一旦你看过几次碰撞检测的逐步执行，你对球和砖块位置变化的理解就会非常深刻，之后写相关代码就不容易出错了。
6.3 游戏平衡性测试：一个人模拟一百种玩家操作
功能测试做完后，还有一个看起来很虚但很重要的测试：游戏平衡性测试。说白了就是让游戏既不能太简单让人无聊，又不能太难让人挫败。
我自己的测试手段非常原始，就是不断玩，记录每一关的用时和失败次数。如果一个关卡我连续三局都过不去，那它大概率对普通玩家来说太难了。这个阶段我做了几次调整：
- 初始球速从350调低到300，让新手有足够反应时间
- 每过一关球速递增幅度从10%调整到5%，避免难度曲线过陡
- 增加了一次“接住球时球会短暂加速”的效果，给老玩家创造挑战感
调整平衡性的核心逻辑是：**难度曲线应该是渐进的，而不是阶梯式的跳变。**玩家在第一关建立信心，第二关开始需要动脑，第三关开始需要技巧，第四关之后才是真正的挑战。这种变化应该是平滑的，让玩家在不知不觉中变强。
我还有一个小小的测试技巧：找一两个朋友来试玩，观察他们玩的时候的表情和行为，通常会比他们嘴上说的诚实得多。如果朋友玩到一半开始频繁低头看手机或者不停叹气，那说明游戏体验出了问题。朋友试玩发现的典型问题是：“球速太快的时候根本不知道球在哪”，这促使我加大球的视觉尺寸，并且给球加了拖影，让它在高速移动时也能被清晰追踪。
7. 上线部署：域名、服务器、HTTPS与首次公测
所有开发工作结束之后，真正让网页游戏“成为产品”的是上线部署。这一步的技术难度不高，但细节非常多，每一步都暗藏着可能把你绊倒的小坑。
7.1 买域名和服务器：一趟踩坑之旅
域名我是在阿里云买的，选了一个和游戏名称相关的.com域名。这里要提醒一个坑：**域名备案。**如果你用的是国内服务器，域名必须完成ICP备案才能正常访问，备案周期通常一到三周。我当时差点因为这个卡住，还好提前规划了，备案期间我一直在做最后的打磨和测试。
服务器我选的是一台最低配的云服务器，1核2G内存，带宽5Mbps。这个配置对静态网页游戏来说绰绰有余，因为整个游戏打包后所有文件不到200KB，几乎没有访问压力，更重要的其实是开启HTTPS所需的证书配置。
服务器操作系统我选了Ubuntu 22.04 LTS。原因很实际：这个系统的软件源里自带Nginx和最新版Node.js，安装配置的资料也最多，出问题好搜解决办法。
7.2 从本地到服务器：文件怎么放最合理
静态文件的部署比很多人想象得更简单。我的做法是：本地开发好的文件夹，直接把整个目录传到服务器/var/www/game下面。用Nginx指向这个目录，给它配一个server_name，然后重启Nginx，游戏就上线了。
Nginx配置大概是这样的：
server { listen 80; server_name yourdomain.com; root /var/www/game; index index.html; location / { try_files $uri $uri/ =404; } }这已经是最简配置。但注意，如果只有HTTP没有HTTPS，现代浏览器会显示“不安全”的警告，这会吓跑很多玩家。所以紧接着需要配置HTTPS。
7.3 HTTPS证书：用免费的先用起来
HTTPS证书我用的是Let‘s Encrypt提供的免费证书。安装过程倒是流水线操作，现在用的是certbot工具，执行一下命令就能自动完成签发和配置：
sudo apt install certbot python3-certbot-nginx sudo certbot --nginx -d yourdomain.comcertbot会自动修改Nginx配置，给server块加上证书路径和443监听。我的建议是用自己的账号注册一下邮箱，这样证书快到期时能收到邮件提醒，避免证书过期导致网站突然打不开。
配置完成后，我用了一个叫“SSL Labs”的在线工具检查证书链和HTTPS配置的安全性，评分拿到A，证明配置没有问题。同时我在Nginx里加了一条HTTP跳转HTTPS的规则：
server { listen 80; server_name yourdomain.com; return 301 https://$host$request_uri; }7.4 首次公测：真实世界的第一个反馈
部署完毕后的第一件事，是把链接发到朋友圈和一些游戏交流群里，请朋友试玩。这里我想说的是：第一次公测的目标不是获得大量玩家，而是验证你的游戏在“别人的设备”上运行是否正常。
很快我就收到一个非常有价值的Bug反馈：有朋友用手机打开游戏，界面错位了，挡板很难控制。我意识到一个大问题——我在开发时从来没考虑过移动端的适配。
网页游戏的本质优势是跨平台，如果不支持手机浏览器，这个优势就会大打折扣。于是我用CSS媒体查询为小屏幕设备做了布局适配，同时判断设备类型自动切换控制方式：触屏设备用滑动控制挡板，而鼠标设备的控制保持原样。
const isTouchDevice = ('ontouchstart' in window) || (navigator.maxTouchPoints > 0); if (isTouchDevice) { canvas.addEventListener('touchmove', handleTouchMove, { passive: true }); }这里有个小坑是touchmove事件的坐标获取跟mousemove不一样，需要通过e.touches[0].clientX来获取第一个触摸点的坐标。如果不注意这个，你会遇到挡板完全不跟着手指走的诡异现象。
首测还暴露了一个问题：在部分老旧设备上，我的拖影效果会拖慢帧率。我加了一个设置项，玩家可以在开画面前关闭特效，保证低端设备也能流畅运行。
8. 上线后的运维：日志、崩溃和用户反馈渠道
游戏一旦公开访问，你的工作就从“开发”切换到了“运维”。这个阶段的核心不是你做了什么，而是你能多快发现问题、多快响应问题。
8.1 日志：你唯一能依赖的客观记录
Nginx的访问日志和错误日志是运维阶段最重要的信息源。默认情况下Nginx会记录所有访问请求，但默认格式对游戏项目来说信息量太多。我调整了日志格式，只保留关键信息：
log_format game_log '$remote_addr - [$time_local] "$request" ' '$status $body_bytes_sent "$http_user_agent"';这样一来，我能看到玩家的设备类型、操作系统和访问时间，这些信息对判断用户群体很有帮助。比如我发现不少玩家用的是iPhone和Android手机访问，这印证了移动端适配的必要性。
8.2 错误监控：不要等用户来告诉你有Bug
前端JavaScript的错误不会出现在Nginx日志里，因为那是浏览器端运行时发生的。为了捕获这些错误，我在window.onerror里加了一段代码，把错误信息异步发送到一个简单的后端接口，然后记录到文件里：
window.addEventListener('error', (e) => { const errorData = { message: e.message, filename: e.filename, lineno: e.lineno, colno: e.colno, userAgent: navigator.userAgent, timestamp: Date.now() }; fetch('/api/log-error', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(errorData) }).catch(() => {}); });服务端那边我加了一个简单的Express路由来接收这条日志：
const express = require('express'); const fs = require('fs'); const app = express(); app.use(express.json()); app.post('/api/log-error', (req, res) => { const logEntry = JSON.stringify(req.body) + '\n'; fs.appendFileSync('/var/log/game-errors.log', logEntry); res.json({ status: 'ok' }); });这套轻量级错误追踪机制，让玩家碰到的异常会直接进入我的服务器日志。我上线第一周就靠这个发现了一个问题：有个玩家在某个特定屏幕尺寸下，游戏开始时球的位置刚好处于砖块的正下方，导致球瞬间被弹飞，游戏体验很差。我修复时判断了屏幕尺寸，在游戏开始时重置球的位置，问题解决。
8.3 用户反馈渠道：让玩家有地方找到你
没有反馈渠道的游戏就像消失的店，玩家遇到问题只能去别处吐槽。我留了两个反馈入口：
一是游戏页面底部加了一个“反馈”按钮，弹出一个简单的表单，收集玩家的浏览器信息和问题描述。表单提交后数据发到我配置的一个后端接口，然后转发到即时通讯工具里，这样我手机就能实时收到消息。
二是在朋友圈发布游戏时，背景说明里写了“欢迎反馈问题和建议”，同时留了邮箱。这个邮箱我设置了邮件提醒，不会漏看消息。
反馈渠道有点像售后服务，玩家愿意花时间告诉你问题，说明他对你的游戏有兴趣。每一份反馈都是优化游戏的线索，而不是负担。
9. 复盘：一个人做游戏到底值不值
从零到上线，整个过程我用了一个多月的时间。如果让我用一个词来总结这次经历，我会说“值得”，但也必须诚实地说“有不少遗憾”。
值得的部分在于，我把自己从“我有一个想法”一步步推到了“我做出了一个完整的产品”。这个过程中没有任何人催我、没有人帮我决定方向、也没有人可以依赖，所有的问题都必须自己找到答案。这种解决问题的经验，比写一万行代码都值钱。一个人做项目最珍贵的能力不是你掌握了多少技术，而是你能否独立把一个模糊的想法拆解成可执行的任务，然后逐一完成它。
遗憾的部分在于，游戏上线后的实际数据并没有达到我的预期。大概是因为游戏本身没有做任何推广，只是靠朋友圈和一些小社群的分享，首周访问量大概在几百人左右，后续自然增长很快衰减，现在的每日访问量基本是个位数。这让我明白一个残酷的事实：游戏的开发只是第一步，让玩家知道你的游戏存在，是另一个同样残酷的战场。
还有一个值得复盘的是时间分配。我前期花了大量时间在代码逻辑和关卡平衡上，后期动手做上线准备时才发现，备案周期、域名解析生效、朋友试玩反馈这些外部因素，所需的时间远超写代码本身。下次如果再做项目，我会把上线运营的工作提前考虑进去，甚至在需求定义阶段就想清楚发布渠道和推广方式。
但即便数据和反馈这么平淡，我还是会建议想做个人项目的朋友勇敢去试一次。因为当你打开浏览器输入自己的域名，看到一个完整的游戏在那里等你玩的时候，那种“这个产品是我做出来的”的满足感，是任何教程和文档都给不了你的。
最后分享一个小技巧：如果你想一个人做点东西，**先把“完成”的优先级放到“完美”之上。**不要等所有功能都齐全了再上线，先把一个最小可玩的版本放出去，哪怕只有五关、只有三种砖块、没有音效，只要核心玩法成立，你就可以上线。剩下的功能，完全可以上线后再补。我的游戏后面加音效和特效的版本，就是先上线了基础版之后才迭代出来的，这个过程里收到了不少真实反馈，帮助我调整方向比闭门造车有效得多。
