在众多开发者还在纠结做App还是做小程序的时候我选择了一个人把所有事都干了——做网页游戏。不需要应用商店审核不需要用户下载安装一条链接发过去就能玩这大概是独立开发者最舒服的交付形态。这篇博文就完整记录我从零开始做一款网页游戏到正式上线的全过程包括技术选型、核心玩法实现、部署上线的完整链路以及我踩过的那些坑。1. 想要一个人做完先把需求砍到能用手玩一个人开发最容易犯的错误就是开局就想做一个庞大的MMORPG。我见过太多独立开发者把项目从“像样的小游戏”一路膨胀到“做不完的3A大作”最后全部烂尾。所以第一件事不是写代码而是把项目范围死死按住。1.1 我最终选定的游戏形态和玩法考虑到“一个人”这个核心约束条件我选择了浏览器实时对战休闲游戏这个品类具体来说是一款回合制多人在线小游戏。回合制意味着不需要处理每帧同步对服务器压力极小浏览器直接跑意味着不用处理跨平台打包、应用商店审核这些问题多人在线则是为了让游戏具备一定的社交裂变属性玩家可以拉朋友一起玩。核心玩法设计得足够简单两名玩家进入同一房间后各自在3x3的格子上放置角色然后轮流选择攻击或者防御通过属性克制关系决出胜负。整个一局游戏控制在3分钟以内适配碎片化时间。这个玩法肯定谈不上创新但它足够小小到一个人能够在两周内从零写完前后端并上线。顺带说一句我见过很多独立开发者在玩法设计上花了大量时间反复横跳一会儿觉得这个玩法不够炫一会儿觉得那个玩法不够新。对一个单人项目来说完成并上线本身就是最大的竞争力玩法新颖程度反而是次要的。1.2 发布目标锁定网页版而不是小程序现阶段如果你问我要不要同步做微信小游戏我的建议是先做纯网页版。网页版不需要注册开发者账号、不需要企业资质、不需要过审核域名解析好就能上线。小程序版本会涉及开放数据域、排行榜、资质审核等一系列额外问题这些对独立开发者来说都是时间黑洞。而且网页版有一个独特优势低门槛传播。你可以直接把链接丢到微信群、朋友圈、论坛帖子里对方点了就能玩不需要任何安装步骤。这个体验在很多场景下是微信小游戏给不了的——小程序跳转有拦截App下载更麻烦。等网页版数据跑通了再考虑用小游戏容器套一层壳做微信版本也不迟。Unity或Cocos都有现成的微信小游戏导出方案后面专门有章节讲这件事。2. 全栈技术选型怎么搭才最省心技术选型是一个老生常谈的话题但单人项目和团队项目的选型逻辑完全不同。团队项目要照顾团队既有技术栈和协作规范而单人项目最重要的标准只有一个你用得越熟越好。没有团队协作负担你完全可以选择自己最熟悉、能最快出活的技术组合。2.1 前端渲染引擎的对比选择网页游戏前端有几种常见方案纯Canvas手写、Phaser框架、PixiJS渲染引擎以及相对小众的Cocos引擎Web版。我做了一个简单对比方案上手难度适合场景单人项目评价纯Canvas中等极简游戏、图形学基础好不推荐重复造轮子Phaser低2D游戏快速开发很推荐内置场景管理和物理PixiJS较低2D渲染为主的Web应用可以选但需自己拼游戏逻辑Cocos Creator Web中等需要编辑器辅助的游戏稍重启动即编辑器我最终选择了Phaser 3理由非常实际它把场景切换、精灵动画、输入事件、粒子效果都封装好了我不用自己写游戏循环和资源管理。Phaser在国内的教程资料虽然不如Unity丰富但官方文档和示例代码已经足够支撑一个休闲游戏的全部开发。如果你完全没接触过游戏框架直接读一遍Phaser官方教程里的“Making your first game”三天内就能写出一个能玩的小游戏原型。它和写业务前端代码的心智模型差别不大——场景就是一个页面精灵就是一个div输入事件就是click监听。2.2 服务端和数据库按最省事的方案走服务端我选了Node.js Express数据库用了SQLite再加一层Redis做房间状态的临时存储其实不加也能跑。这套组合对单人项目极其友好Node.js和前端同样的语言切换上下文几乎没有成本SQLite是零配置文件数据库一个文件就搞定数据持久化服务器重启也不怕丢数据。有人会问为什么不用MySQL或者PostgreSQL。对一个纯网页休闲游戏来说数据量小、并发有限SQLite完全够用。真到了需要换MySQL的时候——其实以这个体量的游戏来说大概率不会到——数据和表结构迁移的成本也不高。我在这件事上的原则是能少一个服务就少一个服务服务越多要部署、监控、排障的东西就越多。Redis那层其实我也犹豫过但后来发现用进程内Map存房间状态完全够用而且游戏本身做了断线重连补偿Redis那点性能优势根本体现不出来。上线后的实际数据也印证了这一点。3. 核心玩法的实现细节3.1 游戏核心逻辑回合制战斗的状态机回合制游戏的核心是状态机管理。一局游戏对应一个Room对象房间状态在WAITING等待对手、FIGHTING对战中、FINISHED对局结束之间流转。每个玩家在房间内有一个PlayerState记录血量、攻击力、防御状态和角色属性。这里我强烈建议一个实践服务器是唯一权威。所有战斗计算都必须在服务端完成前端只负责展示结果。因为这是多人在线游戏如果说前端也能决定伤害结果玩家用浏览器控制台改几个变量就能改血量和伤害游戏的公平性就完全崩了。核心战斗流程大致是这样的两名玩家加入房间房间状态从WAITING变成FIGHTING。服务器向两名玩家广播对局开始事件附带各自的初始状态。玩家提交行动指令攻击某个格子/防御。服务器收到双方指令后先校验指令合法性玩家是否存活、是否重复提交然后计算本回合结果。服务器广播本回合结果两名玩家更新UI并进入下一回合。回合制的计算逻辑本身不复杂真正需要仔细处理的是各种边界情况玩家A提交了指令但玩家B掉线了怎么办两个人都选择了防御这一回合算不算结束玩家连续5个回合不发指令怎么处理这些问题在设计状态机的时候都要考虑清楚否则上线后全是问题。3.2 前端UI和交互怎样实现得又快又好前端界面上我用Phaser的场景管理做了三个场景BootScene负责加载资源MenuScene负责显示主菜单和创建/加入房间GameScene负责渲染对局画面。资源加载方面用了一张自己拼的图集Sprite Sheet把角色头像、格子底图、技能图标都合并到一张PNG里减少网络请求。对局画面的交互做得很克制玩家只需要点选格子然后点击“攻击”或“防御”按钮确认指令后等待对手操作。为了防止误操作我在玩家提交指令后给了一个“等待对手行动”的遮罩层把画面变暗并显示加载动画。这里有一个细节值得单独说说音效和动画不要做得太重。单人项目的时间和精力有限应该优先保证核心交互流畅。我给关键操作攻击、防御、胜负判定加了简单的音效其他无关紧要的按钮点击没有加任何特效。动画也只用了一组简单的帧动画没有加额外的粒子特效。4. 从本地联调到服务器部署上线的完整链路4.1 服务器选型与基础环境配置网页版游戏的部署比想象中简单——本质就是部署一个静态前端加上一个Node.js服务端。我选了云服务器2核4G的配置这个配置对这类体量的游戏绰绰有余。操作系统装的Ubuntu 22.04 LTS用Nginx做反向代理。服务器基础环境配置主要有这么几步安装Node.js 20 LTS和npm。安装Nginx配置静态文件服务和反向代理。用pm2守护Node服务进程保证服务崩溃后能自动重启。用certbot申请并配置SSL证书开启HTTPS。配置防火墙只对外开放80和443端口。4.2 数据库表结构设计和初始化SQLite数据库只建了两张表users存玩家账号信息battles存对局记录。因为游戏没有做复杂的注册登录流程只是让玩家输入昵称就直接进入游戏所以users表也很简单id、nickname、created_at。battles表记录了每一局的对局双方、胜负结果和对局开始/结束时间后续如果要看留存和活跃数据这些基础数据就已经够分析了。建表语句我直接放在了服务端启动时执行用CREATE TABLE IF NOT EXISTS避免手动去服务器上创建表的麻烦。4.3 域名备案与HTTPS配置在国内云服务器上部署网站域名备案是绕不开的一个环节。我从买域名到备案通过前后花了一周左右。这里提醒一句备案期间域名不能绑定服务器IP访问80端口所以进度规划上要留足提前量别等游戏开发完了才开始备案。HTTPS配置用的是Let‘s Encrypt的免费证书certbot一键搞定还自动续期。配置Nginx反向代理的时候我踩过一个不小的坑WebSocket连接的反代配置。Phaser和服务器之间用的是WebSocket实时通信如果Nginx没有正确配置Upgrade和Connection头前端会一直卡在连接状态但看起来Nginx服务又是正常的。下面这段配置是验证过可以直接用的location /ws { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection “upgrade”; proxy_set_header Host $host; proxy_read_timeout 3600s; }4.4 上线前的完整测试清单上线前我给自己列了一个测试清单覆盖了功能、性能和兼容性三个维度。功能层面把核心流程——创建房间、加入房间、完整对局、胜负结算——完整跑了一遍并且专门测试了断线重连。性能层面看服务端在处理并发连接时的CPU和内存占用情况验证在100个并发连接下响应时间都在200ms以内。兼容性层面在Chrome、Edge、Safari和手机版微信内置浏览器里分别试玩了几局。手机端兼容性这里有一个很值得注意的坑iPhone Safari对Web Audio的自动播放策略极其严格用户不点击页面就播放声音的话控制台会报错。解决方案是进入游戏后的第一次点击先调用一下audioContext.resume()再播放音效这样才能正常出声。5. 后端服务的核心逻辑和部署避坑指南5.1 房间匹配与对局控制的实现思路房间匹配逻辑我用了最简单的策略玩家点击“开始匹配”后服务器把他加入匹配队列。如果队列里已经有等待的玩家就直接匹配成对否则就一直等着。这个逻辑放在内存队列里就行不需要持久化到数据库。对局控制方面我设计了一个GameSession类每个实例对应一场进行中的对局。GameSession持有当前回合数、双方玩家状态、战斗记录等数据。每当一个回合结束GameSession会检查胜利条件如果满足则结束对局并写入battles表。5.2 服务端稳定性保障的几条经验一个人开发没有专门的测试工程师来帮你找问题所以服务端的容错能力就显得特别重要。我总结了三个实战经验第一个是所有接口都要做入参校验。前端传进来的roomId、playerId、action这些字段你不能假设它们一定符合预期格式。我都写了校验逻辑不合法的直接拒绝不让脏数据流进核心战斗逻辑。第二个是空闲资源一定要及时清理。匹配队列里的玩家可能等太久就走了对局中的玩家可能直接关掉浏览器就再也不回来了。我专门写了一个定时任务每30秒扫描一次所有房间和匹配队列把超时的玩家清理掉并提供重连入口。不然跑几天之后进程里会积累大量僵尸房间内存迟早被吃光。第三个是善用日志和监控。服务端在关键节点都打了日志比如玩家进入匹配、匹配成功、对局开始、对局结束。上线初期我每天看一次日志从日志里发现了几个基本问题有人匹配到对手后因为前端资源加载太慢导致迟迟进不了对局有人断线重连时因为房间已被清理而失败。这些问题都是通过日志第一时间发现的如果没有日志光靠用户反馈找人排查效率会低很多。5.3 数据备份与恢复策略SQLite数据备份特别简单——直接拷贝数据库文件到备份目录就行。我用了一个cron定时任务每6小时把数据库文件打包拷贝到另一个目录里保留最近7天的备份。对游戏系统来说这够用了真出了大问题最多丢6小时的对局记录玩家账号信息不会丢。6. 部署上线后的运营和维护思考6.1 上线初期的版本迭代节奏游戏上线后我保持着一周一个小版本、两周一个中版本的迭代节奏。小版本修bug和体验优化中版本加新玩法或新角色。这个节奏很重要因为玩家是需要新鲜感的。你的游戏再怎么好玩连续玩两周同一套内容也会腻。第一个迭代周期里我根据玩家反馈做了几个重要调整新增了“再来一局”按钮方便玩家连续对战加了一个简单的排行榜功能优化了移动端的操作热区把按钮调大防止误触。这些小改动看起来不起眼但每个改动都实打实地提升了玩家的体验。6.2 用户获取与社交裂变的设计网页游戏的获客渠道主要是分享和裂变所以我从一开始就在游戏里植入了分享机制。每局游戏结束后无论胜负都有会一个“邀请好友对战”的按钮点击可以生成一条带链接的分享文案。上线两周后来自微信聊天的分享链接是最大的流量来源。另外我还做了一个小功能分享链接里带上邀请者的昵称新用户通过这个链接进来后双方各获得一次额外的“加油”加成效果。这个设计的逻辑很直接——给分享者和被邀请者双方都提供奖励才真正愿意去分享。这个裂变功能上线后新增用户数明显上了一个台阶。6.3 关于多人对战游戏的外挂问题只要是竞技游戏外挂问题迟早会遇到。我这款游戏是回合制而且所有计算都在服务端完成外挂能影响的维度非常有限——最多就是看看对方是什么角色这也看不全因为对手在行动前有隐藏机制真正想改数值是改不了的。但我也做了一层防护在服务端限制每个IP的并发连接数防止有人用脚本批量注册小号刷排行榜。对于做更大体量实时对战游戏的开发者我建议一开始就在架构层面就做好校验截包修数据这种最基础的攻击要防御住否则后面业务做大了再改架构代价是很大的。7. 兼容微信小游戏和移动端的拓展方向7.1 Unity/Cocos导出微信小游戏的方案对比如果你未来想把网页游戏转成微信小游戏版本有两条常见路线一是用Phaser写的代码直接用weapp-adapter适配层转换二是直接用Cocos或Unity重新写一遍。前者对老项目比较友好但不一定稳定后者等于重写整个游戏但后续维护比较省心。我的建议是规模小、玩法简单的游戏直接走适配层方案玩法复杂、后续要做长篇内容更新的游戏干脆用Cocos重写来得实在。微信小游戏还有Open Data Context开放数据域的概念排行榜、好友对战这些功能都需要在开放数据域里单独实现比网页版要多一些工作量。7.2 从网页游戏到App的移植思考如果后续要做成App有两套方案一套是套壳WebView方案用Capacitor或Tauri把你的网页包一层另一套是重写成原生或跨平台框架方案。套壳方案省事但性能和体验有上限重写方案上限高但是工作量巨大。我个人的倾向是如果这款游戏数据表现不错用户粘性也够才考虑用Cocos或Unity重写一遍。如果没有足够的数据支撑重写App版本很可能就是浪费时间。8. 实际运营中常见的坑与排查技巧8.1 兼容性陷阱Web Audio自动播放限制前面已经提到了这个坑这里再展开说说。Chrome和Safari都有自动播放策略不允许页面加载后就自动播放带声音的媒体。如果你在Phaser的init或preload阶段就加载了音效但没触发过用户手势游戏可以正常运行但声音不会出来。解决方法是找一个用户进入游戏后的第一次点击事件在里面调用this.sound.unlock()或者audioCtx.resume()之后声音就正常了。8.2 WebSocket连接不稳定和心跳机制WebSocket连接在移动网络下特别容易断特别是在用户锁屏、切后台、横跨Wi-Fi和移动网络等场景下。如果不做心跳机制前端可能以为连接还活着实际服务器早就把连接清掉了。我用的方案是前端每30秒发送一个ping消息服务器收到后立即返回pong。如果前端连续3次没收到pong就判断连接已断开自动触发重新连接逻辑。配合前面说的断线重连机制用户基本感知不到中间断过线。8.3 常见问题速查表问题现象可能原因排查思路页面能打开但一直“连接中”Nginx忘记配置WebSocket升级头检查proxy_set_header Upgrade和Connection配置声音只响一次后就没了Web Audio自动播放策略限制在首次用户交互事件中调用resume()有人反馈匹配不到对手在线人数太少或匹配队列未清理查看日志确认匹配队列状态考虑加机器人AI服务器跑几天后内存飙升僵尸房间/会话未清理检查定时清理任务是否正常执行某个角色属性改了没生效前端用的是旧的CDN缓存在静态资源文件名上加上版本hash数据库出现“database is locked”SQLite并发读写冲突给写操作加队列或改用WAL模式8.4 日志分析带来的几个真实优化前面说了日志很重要这里举两个真实优化过的例子。第一次是从日志中发现大量玩家在对局开始后的前10秒内退出对局。这说明匹配成功后加载对局场景的时间太长了很多玩家等不了。我分析发现原因是场景资源加载是串行的一个资源卡住会让后面所有资源等待。后来改成并行加载并加了一个资源加载超时跳过机制这个退出率下降了不少。第二个例子是从日志中发现断线重连失败的用户比例较高。排查后有两个原因一是重连时房间已经因超时被清理了二是在移动网络切换IP变化时重连请求被拒绝。这两个问题分别通过延长房间保留时间和用带签名的Token来识别玩家身份解决。9. 一个人做游戏上线的最后的实在话一个人从零到上线做完一个网页游戏最大的投入不是技术而是持续不断把这件事做完的耐心。技术栈选熟悉的那一套功能砍到最简单最核心部署流程自动化减少重复劳动剩下的就是上线后根据真实反馈不断迭代。如果你正在计划做自己的第一款独立游戏我的建议是不要一上来就追求大而全先找一个足够小的玩法把它做到能上线、能玩、能给朋友发链接的程度然后在此基础上快速迭代。做完上线那一刻的成就感远比你想象中更让人上瘾。