Category: Games

背景 一套 Minecraft 1.19.4 Forge 服务端运行在 Linux 主机上，并通过 systemd 管理。服务端使用多模组环境，世界存档体量约数 GB，包含主世界、下界、末地以及额外维度。此前服务端在运行过程中出现异常，停止服务时 systemd 报告 timeout，并最终对 Java 进程发送强制终止信号。 最初看起来像是服务器性能不足、保存世界过慢或 systemd 停止超时太短。但经过只读检查后，真正的主线问题被定位为：服务端实际 JVM heap 只有 1GB，Forge 多模组环境运行一段时间后发生 Java heap OOM，随后在保存世界时又撞上了 systemd 默认 90 秒停止超时。 初始现象 服务端停止时出现过如下现象： 这类日志容易让人第一时间怀疑是 systemd 停止流程本身有问题，或者服务器保存世界太慢。但如果只盯着停止阶段，会忽略更早发生的根因。 进一步检查崩溃报告和 latest.log 后，可以看到关键异常是： 同时崩溃报告中的 JVM Flags 显示： 这说明服务端最大堆内存只有 1GB。对于 Minecraft 1.19.4 Forge、多模组、多个维度和数 GB 世界存档来说，1GB …

背景 一套 Minecraft 1.19.4 Forge 客户端运行在 Linux 桌面环境中，桌面为 KDE，显示设备为 27 英寸高分辨率屏幕。由于客户端配置曾经经过较随意的手动调整，实际运行时存在发热、卡顿、负载偏高的可能。与此同时，服务端也出现过停止超时和内存不足问题，因此有必要先把客户端侧的明显性能压力项梳理清楚。 优化目标并不是把画质压到最低，也不是追求极限帧率，而是在保留正常视觉体验的前提下，让客户端运行更加稳定、少卡顿、低发热，并尽量减少客户端对服务端区块加载压力的间接影响。 初始检查发现的问题 客户端配置中最明显的性能压力来自几个方向：原版图形档位、渲染距离、模拟距离、帧率上限、OptiFine 视觉增强项，以及 JourneyMap 的常驻地图显示层。 首先，原版图形档位处于较高状态。配置中 graphicsMode:2 对应的通常是 Fabulous 档位。Fabulous 会使用更重的渲染路径，对高分辨率屏幕和老款 GPU 更不友好。对于普通生存和模组游玩来说，Fabulous 带来的视觉提升并不总是值得持续负载增加。 其次，客户端的 renderDistance 和 simulationDistance 均为 10。这个数值不算极端，但在 Forge、多模组、高分辨率显示环境下，会明显增加客户端渲染、CPU、内存和区块处理压力。模拟距离还会影响周边区块和实体的活跃范围，在联机环境中也可能间接增加服务端压力。 第三，帧率限制几乎处于放开状态。配置中 enableVsync:false，同时 maxFps:260。对于 60Hz 或普通显示目标来说，这种设置会让 GPU 和 CPU 尽可能多地渲染帧，即使肉眼和显示器无法完整利用，也会带来额外发热、风扇噪音和帧时间波动。 第四，OptiFine 中存在多项视觉增强功能，例如 Connected Textures、Dynamic Lights、Custom Sky、Custom Entity Models、Custom …

这是一组关于 AI Agent 控制 Minecraft 服务端的实验记录。 实验目标不是手动一块一块放置方块，而是把 Minecraft 服务端交给本地 AI Agent 控制：通过自然语言描述建筑目标、风格、范围和限制，再由 AI Agent 通过 RCON 向服务端发送命令，自动完成规划、建造、保存和报告。 最终结果是在一块超平坦区域中完成了一座木石混合风格的小镇。小镇包含中心广场、南北主路、东西支路、住宅、工坊、谷仓、旅店、守卫小屋、礼拜堂、面包铺、马厩、农具棚、果园、市场、农田、入口门拱、道路灯光、庭院、树篱、货物堆和生活装饰。 最后会附上一张建成后的截图。 一、整体结构 这套流程的核心结构如下： AI Agent 并不是作为一个普通玩家进入游戏，也不是在客户端里手动操作，而是通过 RCON 作为服务端控制端执行 Minecraft 命令。 客户端的主要作用是进入服务器观察结果、确认效果，并为下一轮自然语言指令提供反馈。 二、服务器控制方式概念 本次使用的是本地 Minecraft Forge 服务端。公开记录中不保留实际 IP、端口、用户名、密码和本机路径，统一使用占位符表示。 服务端目录示例： RCON 调用方式示例： 例如： 服务端配置中比较关键的项目可以概括为： 这里最重要的原则是： 三、前置检查用自然语言指令 正式建造前，先让 AI Agent 检查服务端和客户端环境，确认 Forge 版本、启动方式、Java 版本、服务端配置、客户端连接方式和 RCON …

AI Agent 不一定只能停留在浏览器、终端或文件系统里。只要目标软件提供可编程接口，Agent 就可以通过自然语言指令进一步控制外部程序。Minecraft 是一个很适合实验的对象：它既有可视化世界，又有服务端命令、RCON、模组和世界文件结构，可以把“自然语言 → 自动执行 → 可视化反馈”这条链路完整跑通。 本文整理一种本地实验方案：在 Linux 桌面环境中运行 Minecraft Forge 服务端和客户端，由 AI Agent 通过 RCON 控制服务端，玩家客户端负责观察和反馈。整个过程以本机测试为主，不暴露公网，不依赖多人联机环境。 一、基本思路 整体结构可以概括为： 在这种结构下，AI Agent 并不是一个“进入游戏的玩家”。它更像是服务端管理员控制台，可以执行命令、改变方块、保存世界、调整时间天气、传送玩家，甚至通过批量命令完成建筑和地形改造。 玩家客户端则承担观察者角色。玩家可以站在高处、使用创造模式或旁观模式，实时查看 AI Agent 对世界做出的修改。 二、为什么使用服务端，而不是直接改客户端单人世界 如果只是普通游玩，客户端单人世界已经足够。但如果目标是让 AI Agent 参与自动化建设，专用服务端更适合。 服务端具备几个优势： 在本地测试中，服务端和客户端可以运行在同一台电脑上。客户端连接地址通常使用本机回环地址，例如： 这样不需要开放公网，也不需要让局域网其他设备访问。 三、服务端与客户端的匹配检查 在连接之前，需要确认服务端和客户端基础环境一致。重点包括： 对于 Forge 1.19.4 一类环境，Java 17 通常是更合适的选择。如果系统默认 Java 版本更高，服务端启动脚本中最好显式指定 Java 17，避免因为默认版本变化导致启动异常。 模组方面，服务端模组必须能被客户端识别。客户端可以额外保留一些只影响本地操作或显示的模组，但不应把客户端的 …

一、Minecraft 世界有没有原点 Minecraft 的世界坐标系统存在一个水平原点： 完整坐标一般写成： 其中： 所以通常说“坐标 0”时，主要指的是： 这个位置有坐标系统上的意义，但没有特殊游戏加成。它不是资源更多、怪物更少、结构更多的特殊地点。出生点通常会在原点附近，但不一定正好在 0,0。 对于长期生存世界来说，0,0 更适合作为地图规划、交通中心或坐标参考点，而不是必须发展的地点。 二、版本更新后，旧地形会不会改变 Minecraft 世界不是每次升级版本后都会整体重新生成。核心规则是： 因此，旧基地、旧矿道、旧村庄、旧探索区域，一般不会因为升级版本而突然变成新版地形。 真正会变化的是： 比如一个世界经历过： 那么这个世界实际上会变成一个“多版本拼接”的长期世界： 这类老存档本身会带有很强的“年代层次感”。 三、1.18 是长期存档的重要分水岭 在多个版本中，1.18 是非常关键的地形更新节点。 1.18 改动了： 旧版本中，主世界高度大致是： 1.18 以后变成： 因此，旧世界升级到 1.18 以后，通常会出现这种情况： 所以旧世界不会整体重刷，但会在未生成区域和深层区域体现新版本特征。 四、真正需要关注的是“已生成区块” 如果关心未来版本升级后哪些地方还能生成新版内容，重点不是“玩家具体走过哪里”，而是： 因为只要一个区块已经生成，它就会被写入存档。以后升级版本时，这个区块通常不会自然重生成新版地形。 可以这样理解： 这对长期存档非常重要。如果当前版本大量探索周围空白区域，那么这些地方就会被当前版本固定下来。未来版本加入新生态、新结构、新矿物、新遗迹时，就必须跑到更远的未生成区域才能看到。 因此，长期世界最好有意识地保留一部分远处空白区块。 五、“去过哪里”和“已生成哪里”不是同一个问题 Minecraft 原版不会保存完整的玩家行动轨迹。但存档里会保存区块数据。 可以分成两类判断： 如果目标是回忆玩家真正活动过哪里，可以参考 InhabitedTime。但如果目标是判断未来版本更新时哪些区域不会重新生成，那么只需要看： 也就是 MCA Selector 中已经显示出来的区块区域。 六、MCA …

Baritone 是 Minecraft Java 版里非常有代表性的自动化工具。它不是一个独立机器人账号，也不是服务器插件，而是装在客户端里的“自动驾驶系统”。它可以控制玩家角色走路、寻路、挖矿、种田、建造、挖隧道、回家、跟随目标等。 它最适合的场景不是创造模式，也不是完全替代玩家，而是在生存模式里把重复、机械、耗时间的操作交给程序完成。比如自动收割农田、自动补种、自动找矿、自动回到起点、自动去指定坐标。这种体验很特别：游戏规则仍然存在，资源不是凭空来的，但重复劳动被机器接管了。 一、Baritone 是什么 Baritone 可以理解成： 它会控制： 但它不会生成一个新的玩家。安装 Baritone 之后，服务器里不会多出一个叫 Baritone 的角色。它控制的是当前登录的玩家本人。 所以使用 Baritone 时，看到的仍然是自己的角色。执行命令后，是自己的角色自动移动、自动挖矿、自动种田。 如果想要“站在旁边看一个机器人干活”，需要第二个 Minecraft 账号和第二个客户端。主账号旁观，副账号安装同样的模组和 Baritone，让副账号执行任务。 二、Baritone 和 Mineflayer 的区别 Mineflayer 是 Node.js 生态的 Minecraft bot 框架，可以用代码创建一个独立机器人账号登录服务器。它适合纯净服、插件服或不强制客户端模组的服务器。 Baritone 是客户端模组。它装在玩家自己的 Minecraft 客户端里，直接控制玩家角色。 两者区别大致是： 项目 Mineflayer Baritone 形态 独立 bot 客户端 玩家客户端自动驾驶 是否生成新玩家 是 否 …

近几年，大语言模型开始从“回答问题”进入“执行任务”的阶段。对于 Minecraft 这样的开放世界游戏来说，这种变化尤其有想象力：玩家不再只是输入指令、编写脚本或手动操作角色，而是可以用自然语言提出目标，让 AI 理解任务、拆解步骤，并控制游戏角色完成一系列复杂行动。 例如： 这些任务如果完全手动完成，需要玩家不断判断路径、资源、背包、工具、地形和危险。但如果由 AI 负责规划，再由模组负责执行，就可以形成一种新的游戏体验：玩家只提出目标，角色自己行动。 一、核心想法：不是聊天机器人，而是玩家代理 这类项目的重点并不是“在 Minecraft 里接入一个 ChatGPT 聊天窗口”，而是建立一个真正能执行任务的 AI 玩家代理。 它大致可以分成几层： 理想状态下，玩家只需要说： AI 就应该能拆解成： 但真正难的地方不是“让 AI 想出计划”，而是让游戏角色稳定地执行计划。 二、不能让 AI 每一帧控制按键 一个直觉上的方案是：让 AI 直接控制玩家按键，例如前进、转头、跳跃、挖掘、放置方块。 但这并不是好的设计。 原因很简单： 更合理的方式是： 也就是说，AI 不应该直接输出： 而应该输出类似这样的结构化任务： 或者： 然后由模组里的执行器去完成寻路、挖掘、放置、种植等具体动作。 三、Baritone 适合作为底层执行器 Minecraft 自动化领域里，Baritone 是一个非常重要的底层工具。它擅长寻路、到达坐标、挖矿、移动、避障等任务。 因此，一个比较现实的架构是： 例如： AI 可以拆解为： 真正的路径规划和挖掘过程，不需要 AI 逐步控制，而是交给 …