上次摸了个开放世界原型几个朋友连进来一起跑图画面虽然简朴但人物同步、动作广播、状态回放都走通了。代码基本是 AI 生成的我只做架构拆分和结果审查。项目代号就叫aethercraft目前完成度 10%基础架构已经搭稳网络连机效果比预期好最重要的是不用装客户端打开浏览器就能访问。这篇文章把 aethercraft 目前能做什么、怎么启动、怎么验证多人连机、怎么评估“完成度 10%”这件事讲清楚。如果你也在用 AI 写游戏、想搞一个可多人访问的 Web 端世界原型这篇可以直接收藏。1. 核心能力速览从标题字面信息看aethercraft 是一个 Web 端开放世界游戏原型开发方式以 AI 辅助编码为主现阶段目标不是做完整玩法而是先把“大地图 多人同时在线 浏览器直接访问”这条主干跑通。能力项当前情况项目形态开放世界游戏原型目前在早期阶段完成度约 10%侧重基础架构与网络同步访问方式直接通过浏览器打开无需安装客户端网络能力多人连机基础链路已搭建同步效果良好开发方式AI 辅助生成代码人力主要负责架构设计与结果验证主要模块世界场景、角色控制、网络通信、同步逻辑当前重点架构稳定、连机可用、浏览器端可运行未完成部分地形生成、玩法系统、内容丰富度、渲染优化、权限与安全加固适合读者独立开发者、游戏编程学习者、AI 编码工具使用者这里要特别说明很多项目容易在 30% 完成度时架构崩坏aethercraft 选择在 10% 阶段就把多人连机和浏览器运行链路打通属于“先修路再通车”的思路。后面加玩法内容时只要地面架构不塌新增功能会快很多。2. 适用场景与使用边界aethercraft 现在不是商业游戏更接近一个技术验证型项目。它最有价值的点在于让你用少量的代码量验证“开放世界 多人连机 浏览器访问”是否可行。2.1 适合谁尝试独立开发者想做一个轻量级多人世界但又不想一上来就碰客户端分发、服务器运维等重问题浏览器端可以省掉大量平台适配工作。AI 辅助编程实践者网上很多 AI 写代码示例停留在“生成一个静态网页”层面aethercraft 属于“AI 生成多人实时同步逻辑”难度和数据量都更接近真实项目。游戏原型验证团队在投入美术资源之前先验证核心玩法、多人交互、场景承载能力aethercraft 这类项目可以当作技术底稿。2.2 不适合什么场景需要高画质、高物理精度的大型游戏目前阶段的重心是架构和网络不是画面表现。超大规模在线用户场景虽然连机链路已通但承载能力还需要压力测试现阶段不适合直接做公测。对数据安全有严格要求的场景浏览器端天然存在客户端代码可见问题逻辑加密和反作弊都需要额外设计。2.3 合规与边界提醒aethercraft 如果后续加入玩家生成内容、用户昵称、聊天信息、 UGC 地图等模块需要提前考虑内容审核、数据隐私、未成年人保护等合规措施。使用 AI 生成代码时也一样——不要直接运行不理解的依赖包不要随意引入来源不明的二进制文件发布前要做代码审查和安全扫描。3. AI 辅助写代码的前置准备既然标题重点之一是“用 AI 来写点代码”这里先把 AI 协作开发的准备工作列清楚。不要指望把需求一句话丢给 AI 就能得到一个可连机的开放世界更现实的流程是人类定架构、AI 填实现、人类做验证。3.1 开发工具链工具类型建议AI 编码助手根据个人习惯选择 Copilot、Cursor、通义灵码等重点看是否支持多文件上下文代码管理Git 仓库必须建立AI 生成的代码经常需要回滚对比本地运行环境Node.js 比较适合 Web 端游戏Python 更适合做服务端原型浏览器调试Chrome/Edge 开发者工具重点用 Network 面板观察 WebSocket帧率与性能工具浏览器 Performance 面板、Stats.js 这类轻量监控脚本3.2 任务拆解是 AI 写代码的核心AI 写代码不是不能出结果而是不能理解“模糊的全局目标”。我自己在 aethercraft 项目里把任务拆到如下粒度搭一个最基本的 Web 服务器能够返回一个页面。页面里加载一个三维场景支持鼠标旋转视角。给角色添加 WASD 移动能力。加入一个广播系统客户端把位置发给服务器服务器转发给其他客户端。加入玩家实体管理新玩家进入时创建实体离开时删除实体。在浏览器控制台输出同步日志方便排查。每一条都是一次独立的 AI 对话或一个提交记录。任务越具体AI 生成代码的可用率越高。如果一句话让 AI“写一个开放世界”得到的基本只能是一堆文件壳子。3.3 提示词模板示例下面是我整理过的一种通用提示词结构可以直接复制后按项目替换描述你现在是一个网页游戏开发工程师。请为以下需求提供代码实现。 项目背景一个可以在浏览器中访问的多人开放世界原型。 技术方向使用 WebSocket 做实时通信三维场景渲染。 本次任务实现一个最简角色移动同步协议。 具体要求 1. 客户端每隔 100ms 发送一次角色位置。 2. 服务器收到后广播给其他客户端。 3. 其他客户端根据位置信息更新虚拟角色。 4. 代码要带注释并给出运行说明。 局限性说明 - 如果当前需求依赖后端服务请指出需要先启动什么服务。 - 不要生成和本次任务无关的代码。这样写的好处是AI 不会自由发挥生成一大堆无关类输出结构也会更贴近“可用代码”。在 aethercraft 的开发过程中大部分可用代码都是通过这种约束式提示词生成的。4. 环境准备与本地运行aethercraft 要跑起来硬件门槛并不高。以浏览器为目标平台的优势就是开发机不需要高端显卡只要有一台能跑现代浏览器的电脑即可。但服务器端和客户端之间的网络链路需要提前确认。4.1 本地环境检查清单# 检查 Node.js 是否可用建议使用 LTS 版本 node -v npm -v # 检查 Git 是否可用 git --version如果你计划把服务部署到云服务器还需要考虑 WebSocket 端口是否被安全组放行。很多情况下页面能打开但连不上服务器就是云控制台的安全组规则没放行对应端口。4.2 下载项目与安装依赖假设项目从 Git 仓库拉取启动流程大致如下# 克隆项目仓库仓库地址按实际项目替换 git clone https://example.com/aethercraft.git cd aethercraft # 安装依赖 npm install这里不写死具体的依赖包版本因为 aethercraft 仍处于早期阶段依赖变化会比较频繁。安装完成后检查根目录下是否有package.jsonserver.jsclient等关键文件再继续启动。4.3 启动服务器从标题信息看aethercraft 强调“直接浏览器就可以访问打开”说明应该是“服务器 前端静态资源一体化”的形态。# 启动开发服务器 npm start启动后终端会输出一个本地地址通常是Server running at http://localhost:3000 WebSocket server listening on ws://localhost:3000请以实际终端输出为准。如果本地端口被占用换一个端口再启动# 指定端口启动示例端口 8080实际以项目支持的参数为准 npm start -- --port 8080浏览器打开http://localhost:3000能看到一个三维场景画面就说明基础服务已经跑通。这一环节的验证标准是页面无报错、角色可以移动、控制台没有红色异常。5. 功能测试与效果验证现在进入正题如何验证“完成度 10% 但架构跑通”这件事。单机跑一个场景只是开始真正要验证的是多人连机。5.1 单机场景测试测试目的确认画面渲染、角色控制、基本交互正常。操作步骤启动服务器。浏览器打开页面。使用 WASD 或方向键移动角色。观察画面是否流畅、控制是否跟手。打开浏览器控制台确认没有报错。预期结果角色能正常移动。画面帧率在可接受范围。控制台无 JavaScript 异常。如果发现画面卡顿优先检查是否开启硬体加速以及在浏览器任务管理器中观察 GPU 进程占用。5.2 多人连机测试这是 aethercraft 最需要重点验证的部分。核心目标是两个不同的浏览器窗口里玩家 A 能看到玩家 B 的移动。测试方法打开一个浏览器窗口记为玩家 A。再打开一个无痕窗口记为玩家 B。两个窗口都访问同一个地址。玩家 A 移动角色。玩家 B 观察场景中是否出现玩家 A 的同步实体且位置实时更新。反向再验证一次。判断成功标准两个玩家都在线时画面中能同时看到两个角色。任一角色移动另一个窗口中的位置同步延迟在可接受范围。玩家 A 关闭窗口后玩家 B 画面中对应的实体被移除。如果多人连机测试通过说明基础网络架构已经建立了。这个阶段比画面好看重要得多因为很多开放世界项目后面就死在了“单机流畅、联机崩坏”上。5.3 压力与稳定性观察完成度 10% 阶段不需要做千人在线压测但建议做小规模稳定性观察测试场景操作方式关注点多标签连机开 3 到 5 个标签页同时进入新玩家进入时是否卡顿长时挂机窗口挂机 30 分钟WebSocket 是否断开、内存是否持续上涨频繁进出反复刷新页面玩家实体是否残留断线重连断开网络再恢复客户端能否自动恢复同步从 aethercraft 的标题描述看连机效果已经比较理想但这并不代表所有场景都稳。多标签页反复进出是对实体管理逻辑最直接的考验——刷新后玩家实体如果没被清理服务器内存和客户端画面都会出问题。这一步值得优先验证。5.4 问题定位方法连不上服务器时用浏览器开发者工具看网络流量F12 打开开发者工具。切到 Network网络面板。筛选 WS 类型查看 WebSocket 连接状态。如果显示 pending 或 failed说明服务器地址或端口有问题。检查控制台是否有WebSocket is closed before the connection is established之类的报错。常见原因不是代码逻辑复杂而是地址写死、端口错误、安全组拦截。建议把服务器的监听地址和客户端连接地址都做成配置项避免后续换部署环境时到处改代码。6. 服务端接口与批量能力规划aethercraft 目前完成度 10%还没有到开放 Mod 接口的阶段。但从架构角度看要支撑后续内容扩展建议现在就预留接口层。6.1 当前最简接口设计现在不需要 REST APIWebSocket 消息协议已经足够。一个最简的示例协议如下{ type: playerMove, data: { x: 12.3, y: 0, z: -4.2, rotation: 1.57, speed: 2.5 } }服务器把这条消息广播给其他客户端时加上玩家 ID{ type: playerMove, playerId: u_001, data: { x: 12.3, y: 0, z: -4.2, rotation: 1.57, speed: 2.5 } }这样每个客户端在收到消息时就知道“谁在什么位置”。后续加入聊天、状态同步、物品交互时按这个模式增加type类型即可。6.2 批量测试思路AI 生成的网络同步代码最容易出现的问题是消息顺序和重复广播。可以设计一个简单的批量测试脚本用代码模拟多个客户端连接服务器import asyncio import websockets URI ws://localhost:3000 async def fake_player(player_id): async with websockets.connect(URI) as websocket: for i in range(10): await websocket.send(f{{type:playerMove,playerId:{player_id},data:{{x:{i},y:0,z:0}}}}) await asyncio.sleep(0.1) async def main(): tasks [fake_player(fbot_{i}) for i in range(5)] await asyncio.gather(*tasks) asyncio.run(main())注意这个脚本是一个通用示例实际消息格式需要按 aethercraft 的协议调整不能直接照搬。它的价值在于验证服务器能否同时处理多个连接、广播逻辑是否正确、消息顺序是否错乱。AI 生成代码时也可以把“写一个多客户端模拟脚本”作为一条独立任务这对后续性能观察非常有帮助。6.3 后续接口扩展路径等完成度到 30% 以后可以考虑加入以下接口能力# 接口规划示例 api: auth: - POST /api/login - POST /api/register world: - GET /api/world/info - POST /api/world/save mods: - POST /api/mods/upload - GET /api/mods/list这只是规划示例不代表 aethercraft 当前已实现。早期阶段把 WebSocket 协议做稳比分心做一堆 HTTP 接口更务实。7. 资源占用与性能观察方法开放世界游戏哪怕只是个原型也要关注资源占用。浏览器端项目的优势是部署方便代价是性能上限更容易触顶。这里不给出固定显存或内存数值因为不同机器差异很大但观察方法是通用的。7.1 浏览器端观察指标打开 Chrome 的开发者工具切到 Performance性能面板录制一段移动和视角切换操作重点看FPS如果频繁掉到低帧可能与绘制调用数量有关。GPU 进程占用打开浏览器任务管理器观察 GPU 进程的内存和 CPU 占用。网络流量网络同步频率过高会导致流量飞涨需要权衡同步间隔。如果项目使用三维场景渲染建议在代码里加入一个可开关的渲染统计而不是靠人工感受卡顿。AI 生成如下代码也非常方便// 简单帧率统计实际项目可替换为更完善的实现 let frames 0; setInterval(() { console.log(FPS: ${frames}); frames 0; }, 1000);这个示例展示的是“统计帧率”的思路实际要接在渲染循环里计数。更成熟的方案可以在项目后期接入内置性能监控面板。7.2 降低资源占用的方法如果场景出现卡顿优先级如下降低同步频率。位置同步从 100ms 一次改成 150ms 一次肉眼很难察觉差异但网络压力会显著降低。使用插值算法。在两次位置消息之间做平滑插值避免实体跳变同时可以降低消息密度。限制视野内实体数量。开放世界不能无限渲染所有物体需要按距离裁剪。控制粒子、光照、阴影数量。原型阶段这些效果要克制。7.3 服务器端观察指标多人连机项目的瓶颈经常出现在服务器端消息广播。几个观察重点服务器进程 CPU 占用如果持续接近满负荷广播逻辑可能需要优化。消息队列积压如果大量消息没有及时广播说明写入了慢消费者。玩家列表内存每新增一个连接都对应一组状态数据需要确认离开时是否完整释放。AI 生成服务器代码时提示词里应明确要求“包含日志输出和异常处理”否则线上出问题会很被动。比如每个 WebSocket 连接建立时打印玩家 ID断开时打印清理结果这些小日志在排查时非常关键。8. 常见问题与排查方法从 AI 生成代码到多人连机跑通中间会踩不少坑。下面是 aethercraft 这类项目常见的排查清单。问题现象可能原因排查方式解决方案浏览器打开后显示空白页静态资源路径不对打开控制台看资源加载请求检查资源文件是否在预期目录页面打得开但连不上服务器WebSocket 地址或端口错误Network 面板筛选 WS 查看连接状态修正客户端连接地址为实际服务器地址两个窗口看不到对方玩家房间/频道逻辑不一致检查服务端日志中玩家是否在同一房间统一房间分配逻辑角色移动不同步消息没广播或位置坐标格式不一致在服务器打印收到的 playerMove 消息确认协议字段与客户端发送字段完全一致刷新后出现幽灵玩家玩家断开时未清理实体检查 close 事件处理逻辑在连接关闭时广播移除实体消息画面卡顿渲染负载过高或同步频率太高Performance 面板看 FPS 与 GPU 占用降低同步频率、裁剪场景物体云服务器上无法连机安全组未放行端口在本地 telnet 测试端口连通性放行对应 TCP 端口AI 生成的代码运行后报错依赖缺失或新版 API 不一致查看错误堆栈并回传 AI 修复提供完整错误信息重新生成WebSocket 频繁断开心跳机制缺失或网络代理问题查看服务器日志和网络稳定性加入心跳保活机制这里最值得强调的是AI 生成的代码不是不能报错而是你要有能力把“报错信息 涉及代码片段 上下文”完整复述给 AI修复效率才会高。不要只丢一句“这个代码不行”AI 和人都无法基于这句话定位问题。9. 最佳实践与工程化建议aethercraft 目前完成度 10%刚好是从“跑通”走向“扩展”的转折点。这个阶段最怕两件事一是代码腐化二是不知道下一步做什么。下面是更稳妥的推进方式。9.1 代码与目录规划建议从一开始就维护清晰的目录结构。即使 AI 生成很多代码也要把它归入固定位置aethercraft/ ├── server/ # 服务器逻辑 │ ├── index.js # 入口 │ ├── network/ # WebSocket 消息处理 │ └── world/ # 世界状态管理 ├── client/ # 浏览器端 │ ├── index.html │ ├── src/ # 客户端逻辑 │ └── assets/ # 素材与模型 ├── tests/ # 自动化测试与模拟脚本 └── prompts/ # AI 提示词留存方便复用很多使用 AI 写代码的项目死在完全依赖 AI 生成文件。文件路径一乱后期改任何功能都要全局搜索。prompts/目录是容易忽略但很有价值的——把每一次有效的 AI 提示词保存下来下次遇到相似需求可以直接复用不用重新组织语言。9.2 小步提交快速回滚AI 生成代码的不确定性决定了必须频繁提交。规则很简单一次任务一个 commit。提交前先跑一次现有测试。AI 生成的大块代码先放分支验证不要直接合并主分支。回滚时优先用 Git不要手工删除文件。例如# 每次完成一个小功能后提交一次 git add . git commit -m feat: add playerMove protocol synchronization这种提交习惯让“AI 把代码改坏”的风险变得可管理。因为你可以随时回退到上一个稳定版本。9.3 提示词沉淀AI 开发中最大的成本不是提问次数而是每次都要重新解释项目背景。推荐写一个project_context.md把 aethercraft 的核心信息浓缩进去- 项目类型Web 端多人开放世界原型 - 技术方向浏览器实时渲染 WebSocket 同步 - 当前任务玩家位置同步 - 已完成模块基础场景、角色控制、连接管理 - 常用约定消息格式为 JSON统一包含 type 字段每次让 AI 生成代码前先把这份上下文贴给 AI再附具体任务。这样 AI 生成的内容会更贴合项目现状不会凭空冒出风格完全不一致的代码。9.4 在早期引入基础测试开放世界项目最核心的测试对象不是渲染好不好看而是状态同步。建议用 AI 直接生成下面这种测试脚本{ name: multi-client-simulation, players: 5, duration: 30, check: [ all_players_connected, position_messages_broadcast, no_ghost_players_after_disconnect ] }现阶段不需要做完整自动化测试但能让脚本自动模拟 5 个玩家进出、移动、断开对稳定性判断非常有价值。9.5 安全与合规注意浏览器端开放世界意味着所有客户端代码都是公开的所以服务端必须做校验而不是信任客户端上报的任何位置数值。AI 生成的代码中如果出现“直接使用客户端传入的坐标更新世界状态”这种情况要在代码审查时拦住改成“服务端校验后更新”。涉及用户账号、聊天、上传内容时更要遵守相关法律并做内容管理设计。10. 总结与下一步aethercraft 在完成度 10% 时跑通了基础架构多人和浏览器访问两个核心目标都验证成功这个节点价值很高。现在最值得做的事情是守住这个稳定的多人链路再逐步加入新系统。AI 写代码确实省力但前提是任务拆解够细、代码立刻提交、测试要跟上。最容易踩的坑是三种一是拿到 AI 生成代码后不审查直接跑依赖注入风险不可控二是任务太大一次让 AI 生成上百个文件出问题根本无法排查三是服务端不做状态校验把浏览器端的数据完全当真。下一步可以考虑的方向不多挑一个先做给服务器加入心跳检测与掉线重连。实现玩家名字显示和简单的聊天消息广播。加入更丰富的地面材质和空间网格辅助线。做一次 10 人同时在线的迷你压测确认当前架构的承载上限。把位置同步频率做成服务器可配置参数方便后续调优。aethercraft 现在的问题不是“完成度低”而是地基能不能撑住后续内容。从目前网络连机效果来看这个地基至少是稳定的。文章可先收藏等后续 AI 代码和模块逐步补全再对照验证。
