《装甲核心》是什么游戏:从零件搭配开始打造专属机甲

提到可以“自己组装机器人”的电子游戏,很多人想到的可能是《装甲核心》。 《装甲核心》的日文名称是「アーマード・コア」,英文名称为 ARMORED CORE。中文通常译作《装甲核心》。这是一系列以机甲组装和高速战斗为核心的动作游戏,由 FromSoftware 开发。 不只是驾驶机甲,而是自己设计机体 与许多提供固定角色或固定载具的动作游戏不同,《装甲核心》允许玩家使用不同零件组装自己的机甲。 一台机体通常由多个部分构成,例如: 这些零件并不只是改变外观,还会直接影响机体的重量、速度、防御力、能源消耗、武器命中能力和移动方式。 因此,组装机体并不是简单地选择攻击力最高的零件,而是在不同性能之间取得平衡。 不同腿部决定不同战斗风格 《装甲核心》中最有代表性的设计之一,是不同腿部结构会明显改变机体的操作方式。 常见类型包括: 双足型 外形接近传统人形机甲,性能相对均衡,适合大多数战斗场景。 逆关节型 拥有较强的跳跃能力和空中机动性,适合高速移动和突然改变位置。 四足型 通常具有较高的稳定性,部分作品中还可以在空中保持悬浮,适合使用重型武器。 坦克型 使用履带或大型底盘,移动方式与普通双足机体不同,但能够承载更重的武器和装甲。 同一套武器安装在不同腿部结构上,可能会形成完全不同的战斗体验。 重量和能源是组装的重要限制 机体不能无限安装大型武器和厚重装甲。 每一种手臂和腿部零件都有承载上限。如果机体总重量过高,可能无法完成组装,或者会导致移动速度明显下降。 能源系统同样重要。推进器、能量武器和部分特殊设备都需要消耗能源。发电机性能不足时,机体可能频繁出现能量短缺,无法连续闪避或飞行。 因此,一套合理的机体配置通常需要同时考虑: 这使得组装过程本身成为游戏的重要内容。 战斗强调高速移动和立体空间 《装甲核心》的战斗并不是传统意义上的缓慢机器人对射。 机体可以进行快速推进、空中移动、侧向闪避、近距离突击和高速转向。战斗往往同时发生在地面和空中,玩家需要不断判断敌人的位置、攻击范围和自身能源。 部分机体适合远距离使用导弹和步枪,部分机体则依靠高速推进接近敌人,使用光剑或其他近战武器。 因此,机体配置和实际操作必须相互配合。即使零件性能优秀,如果与操作习惯不匹配,也未必能够发挥效果。 《装甲核心 VI:境界天火》 系列中较新的作品是《ARMORED CORE VI FIRES OF RUBICON》,中文名称通常译作《装甲核心 VI:境界天火》。 该作保留了系列经典的机体组装系统,同时加入了更现代的画面表现、任务设计和大型头目战。 玩家可以根据任务需要不断修改机体。例如,面对高速敌人时,可以使用轻型机体和高追踪能力武器;面对重装目标时,则可以换成高冲击力武器或近战装备。 游戏中的失败并不一定意味着操作能力不足,也可能说明当前机体配置不适合对应任务。重新组装机体、改变武器和战术,往往就是解决问题的重要方式。 它是不是机器人拼装游戏 严格来说,《装甲核心》并不是现实中的模型拼装游戏,而是一款机甲动作游戏。 不过,机体装配系统足够深入,玩家确实可以像设计模型一样选择零件、调整颜色、制作标志,并打造具有个人风格的机体。 对于喜欢机械设计、零件搭配、高速战斗和反复优化配置的玩家来说,《装甲核心》的魅力不仅在于战斗,也在于不断思考“下一台机体应该怎样组装”。

Minecraft Forge 服务端优化记录:从 1GB Heap OOM 到稳定启动与正常停服

背景 一套 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 Forge 客户端性能优化记录:从高画质高负载调整到稳定低热

背景 一套 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 超平坦世界里建造一座小镇

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

使用 AI Agent 连接 Minecraft 服务端:一种本地自动化建造实践

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,避免因为默认版本变化导致启动异常。 模组方面,服务端模组必须能被客户端识别。客户端可以额外保留一些只影响本地操作或显示的模组,但不应把客户端的 …

雨把世界放慢:川瀬巴水《五月雨(荒川)》中的静默与距离

图注:川瀬巴水《五月雨(荒川)》,1932年,木版画。https://seikougarou.co.jp/item/1633.html 川瀬巴水的《五月雨(荒川)》是一幅很容易让人停下来的作品。它并没有表现宏大的风景,也没有戏剧性的事件。画面里只是雨、河、水边、船屋、几只小船、远处的帆船,以及一个撑伞站在岸边的人。但正是这种没有强烈情节的画面,使它呈现出一种非常安静、湿润、缓慢的力量。 这幅画最先抓住视线的,是前景中撑伞的人。人物很小,身体几乎被雨和岸边的色调包围,但蓝白色的伞面非常醒目,像是整幅画里唯一明确发亮的圆点。观者的目光会先落在伞上,然后顺着岸边的小路、木船、码头和船屋,慢慢移动到水面中央的帆船,再到更远处的树丛和阴云。画面的空间不是突然打开的,而是被雨一点一点推远。 这里的雨不是暴雨,也不是为了制造悲剧气氛的雨。细密而接近垂直的雨线贯穿天空、水面、船屋和人物,把所有东西都放进同一个天气之中。它让画面变得统一,也让时间变慢。河面没有激烈波动,船只停靠着,船屋里似乎仍有人生活,远处的帆船也在缓慢前行。雨并没有让世界停止,只是让世界变得更低声、更迟缓。 色彩也是这幅画的重要部分。整体被控制在蓝、青、灰绿和木色之间,几乎没有强烈的暖色。天空上方较深,下方渐浅;水面也有蓝色和青色的层次变化。这样的处理让画面虽然大面积使用冷色,却并不单调。它更像是雨天空气中的湿度、河面的反光和远处景物的模糊感共同形成的一种视觉温度。 画面下方的船屋、木船和码头线条比较密集,充满生活痕迹;而上方的天空、水面和远岸则相对空旷。这个对比很耐看:近处是具体的日常,远处是被雨水淡化的空间。人站在这两者之间,既属于岸边的生活,也望向更远的河面。这个人物并不孤立,也不特别悲伤,但确实带着一种安静的距离感。 这也是川瀬巴水风景版画中很有代表性的气质:他画的不是单纯的地点,而是某个地点在特定天气、特定光线、特定时间里的空气。新版画继承了浮世绘的线条、平面色块和木版画特有的清晰轮廓,同时又加入了近代风景画对光线、空间和气氛的关注。《五月雨(荒川)》正好体现了这种结合:它有传统版画的简洁构图,也有近代风景画式的空气感。 这幅画真正动人的地方,不在于“画了雨”,而在于它画出了雨中生活仍在继续的状态。岸边有人,船屋里有人,远处还有船。世界没有因为雨而变得空无,只是安静下来。它不是凄凉的雨景,而是一种湿润、低声、带着日常温度的风景。 因此,《五月雨(荒川)》适合慢慢看。它不急着给出强烈情绪,也不要求观者立刻理解什么。它只是把一个雨中的水边瞬间保存下来:一个人停在岸边,几只船靠在水上,远处的帆慢慢经过,雨线落下,河面安静。看久了会发现,这种安静并不是空洞,而是一种被雨水洗过之后的秩序感。

魚拓:魚の姿をそのまま紙に残す日本の伝統技法

日本には、魚拓という興味深い伝統的な記録方法があります。読み方は「ぎょたく」です。魚の表面に墨や絵の具を塗り、その上から紙をかぶせて軽く押さえることで、魚の輪郭やうろこ、ひれの模様を紙に写し取ります。 魚拓は、もともと芸術作品としてだけではなく、釣った魚を記録するための方法でもありました。写真がまだ一般的ではなかった時代、大きな魚を釣ったときに、その大きさや形を実物大で残す手段として使われていました。 この技法の面白さは、想像で魚を描くのではなく、魚そのものを使って姿を写し取るところにあります。紙に残る模様は実際の魚の体から生まれるため、記録としての正確さと、自然が作る独特の美しさの両方を持っています。現在では、魚拓は釣りの記念としてだけでなく、日本の伝統文化を体験できるアートとしても親しまれています。

Minecraft 老存档升级、已生成区块与 MCA Selector 查看方法整理

一、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 生存模式变成“自动驾驶”

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

用自然语言控制 Minecraft:从自动化模组到 AI 玩家代理

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