LuantiMinetest开发方向与路线图解读SSCSM、输入处理与 UI 演进全指南【免费下载链接】minetestLuanti (formerly Minetest) is an open source voxel game-creation platform with easy modding and game creation项目地址: https://gitcode.com/gh_mirrors/mi/minetest导读本文以 Luanti前身 Minetest官方路线图文档 doc/direction.md 为主体系统梳理该开源体素游戏创建平台的长期愿景与中期开发目标Roadmap并深入剖析其中三大核心技术方向服务端下发客户端脚本SSCSM、输入处理重构与 UI 体系升级。文章结合仓库内的 SSCSM 实现源码、安全模型文档与贡献规范帮助读者理解路线图的制定机制、各目标的现实动因与工程落地现状为引擎开发贡献者、Mod 作者与对 Luanti 架构感兴趣的读者提供一份可检索、可验证的路线图导读。一、路线图文档在项目中的定位在 Luanti 的官方文档体系中doc/README.md 明确指出direction.md与 Luanti 未来发展方向相关的信息通常被称为路线图文档roadmap document。也就是说本文所依据的 direction.md 并非 API 参考或使用手册而是面向引擎开发的核心决策文件。它回答了Luanti 要往哪里走、为什么这么走、以及贡献者如何参与这三个关键问题是衡量每一个新功能 PRPull Request是否符合项目整体图景的准绳。仓库根目录的 .github/CONTRIBUTING.md 在合并条件一节中把以某种方式遵循路线图并契合项目整体图景列为第一优先级足见该文档的实际约束力。文档整体分为两大部分长期路线图Long-term Roadmap项目愿景与指导哲学由历史文档与核心开发者讨论沉淀而来中期路线图Medium-term Roadmap当前正在推进的、按优先级排序的开发目标约每两年评审一次。二、长期路线图项目的指导哲学direction.md 的长期路线图部分本身并不重复罗列愿景内容而是通过一组权威来源文档来承载项目的长期目标、追求与指导哲学历史存档文章《What is Minetest?》阐述了项目诞生之初的定位思考核心开发者 celeron55 发布的个人路线图以及他在 A clear mission statement for Minetest is missing需要一个清晰的使命宣言议题中的长篇评论后者是理解项目自我认知的关键材料核心开发者待办/愿望清单Core developer to-do/wish lists。这些材料的共同主题是Luanti 是一个开放的体素游戏创建平台其价值在于易修改easy modding与易创建游戏game creation而路线图机制正是为了在保持这一开放性的同时让引擎内核的演进有章可循。从仓库布局也能印证这一点games/、mods/、builtin/引擎内置的 Lua 基础库与 doc/lua_api.md 共同构成了面向创作者的分层体系任何内核改动都必须与这套生态兼容。三、中期路线图工作机制与参与规则3.1 目标来源与评审周期中期目标并非凭空产生而是来自一次路线图头脑风暴roadmap brainstorm该讨论收集了社区与核心团队排名靠前的发展建议并整理为当前的中期目标列表。该列表不区分优先级顺序in no particular order并且大约每两年评审一次以保证目标随时间推移仍然有效、与生态现状匹配。3.2 Roadmap PR 标签与概念批准机制为了让路线图真正落地到日常开发流程项目制定了明确的门禁规则针对路线图中某个目标提交的 Pull Request会被标记为Roadmap标签不在路线图上的 PR除非在一个月内获得概念批准concept approval否则将被关闭开发者可以先用Issue 进行预批准preapproval即先在 Issue 中讨论并获得认可再动手实现以避免返工Bug 修复不受此限制始终被接受并优先处理。这套机制在 .github/CONTRIBUTING.md 的概念批准与路线图Concept approvals and roadmaps一节中得到进一步细化非 bug 修复类 PR 若匹配路线图目标应标记为 Roadmap 并在描述中标注目标编号若不匹配则需在一周内获得概念批准才能保持开启。这也解释了为什么 direction.md 被贡献文档反复引用为评审依据——它是社区贡献者与核心维护者共同遵守的契约。3.3 三大中期目标概览当前中期路线图聚焦于三个方向它们分别触及引擎的脚本架构、输入抽象与用户界面三大基础设施层目标核心问题期望结果SSCSM服务端无法在客户端沙箱中执行 Mod 代码客户端脚本执行环境降低网络延迟改善架构Input Handling键位映射受限、手柄兼容性差让游戏开发者能映射设备上的绝大多数按键UI Improvements表单formspec与 HUD 割裂、主菜单体验欠佳统一 GUI API重做主菜单以下各节逐一深入剖析。四、SSCSM服务端下发客户端脚本4.1 概念与动机SSCSMServer-sent client-side modding服务端下发的客户端侧 Modding是Mod 作者与核心开发者都长期呼吁的功能。其核心思想是由服务端把 Modding 脚本发送给客户端客户端在沙箱中执行这些脚本。这与网页在浏览器中运行 JavaScript的模型高度类似——网页由服务器提供内容脚本则在用户机器上本地执行。为什么需要 SSCSMdirection.md 给出了三层理由规避网络延迟支持同步 API许多客户端行为需要同步完成例如瞬时响应输入若每次调用都走服务端往返延迟会破坏体验。SSCSM 环境下引擎可以提供新的脚本 API让 Mod 覆盖当前客户端中大量硬编码hard-coded的行为架构合理性某些 API 天生就应该存在于客户端而非把每次调用都通过服务端隧道传输tunnel every call through the server——后者只会在 SSCSM 到来后演变成技术债性能分流Mod 的部分计算可以迁移到客户端执行从而改善服务端性能。方向文档特别强调与其追求短期方案、积累必然爆发的技术债SSCSM 为可长期存续的更干净架构铺平了道路。这体现了路线图以终为始的设计哲学。4.2 仓库中的实现现状从源码结构看SSCSM 在仓库中已经形成了完整的代码骨架客户端控制器src/script/sscsm/sscsm_controller.h 中的SSCSMController类职责是作为 SSCSM 进程的 RAII 所有者、向 SSCSM 发送事件并处理请求runEvent同时对外隐藏独立进程 IPC的实现细节运行环境SSCSMEnvironment见 src/script/sscsm/sscsm_environment.h与控制器通过StupidChannel通信配合sscsm_irequest.h、sscsm_ievent.h、sscsm_events.h、sscsm_stupid_channel.h等文件形成完整的事件/请求处理链Lua API 绑定src/script/lua_api/l_sscsm.cpp 与 src/script/lua_api/l_sscsm.h 提供 SSCSM 环境的脚本接口src/script/cpp_api/s_sscsm.cpp 负责服务端一侧的脚本桥接客户端内置脚本builtin/sscsm_client/init.lua 是客户端 builtin 的入口它加载common/item_s.lua、common/register.lua等共享库并注册core.get_content_id()、core.get_name_from_content_id()等占位实现注释标明FIXME: send actual content defs to sscsm env——真实内容定义尚未下发沙箱安全初始化initializeSecuritySSCSM()见 src/script/cpp_api/s_security.cpp负责在安全模式下收紧 Lua 环境例如builtin/sscsm_client/init.lua在加载完成后主动置空debug.getinfo以兑现安全初始化承诺。4.3 如何启用enable_sscsm 配置项SSCSM 的启用由设置项enable_sscsm控制。仓库中的定义与使用位置默认值定义在 src/defaultsettings.cppsettings-setDefault(enable_sscsm, nowhere)即默认完全关闭启用判断在 src/client/client.cppg_settings-get(enable_sscsm) singleplayer时视为启用源码注释//FIXME: enum表明该逻辑未来应重构为枚举判断。配套的安全文档 doc/sscsm_security.md 进一步说明该设置并非简单的布尔开关而是四级作用域限制取值含义nowhere任何情况下都不启用默认值singleplayer仅在单人游戏本机启用localhost本地回环地址含单人游戏或更严格的范围lan局域网或更严格范围其他对所有服务器启用higher values安全考量是作用域分级的关键在localhost及更严格的取值下可以确认服务端运行在同一台机器上或代表服务端的角色就在本机其恶意风险几乎为零。而在足够的安全措施就位之前用户被禁止将该项设置为高于localhost的值。配置示例写入minetest.conf# 仅在单人游戏时启用 SSCSM 预览脚本 enable_sscsm singleplayer注意根据 doc/sscsm_api.md当前阶段尚不能由 Mod 自行添加 SSCSM 脚本只有在enable_sscsm singleplayer时引擎才会加载一个硬编码在 C 中的小型预览脚本preview script。因此本文档描述的更多是架构方向与 API 形态而非可直接投入生产的 Mod 功能。4.4 SSCSM API 形态速览doc/sscsm_api.md 勾勒了未来 SSCSM 编程环境的 API 面貌文档明确警告SSCSM 高度实验性API 必然变动Mod 必须做版本检查至少校验core.get_version().proto_max虚拟文件系统SSCSM 使用虚拟路径字典承载脚本文件路径形如modname:foo/bla.lua但文档建议依赖core.get_modpath()而非硬编码路径引擎按服务端 Mod 依赖顺序加载各 Mod 的modname:init.lua注册与全局回调core.register_globalstep(function(dtime))等SSCSM 特有 APIcore.get_node_or_nil(pos)、core.get_content_id(name)、core.get_name_from_content_id(id)注册表core.registered_items、core.registered_nodes、core.registered_tools、core.registered_craftitems、core.registered_aliases后者标注 TODO 仍为空工具 APIcore.log、core.get_us_time()精度受限、JSON 序列化、压缩/Base64、哈希sha1/sha256、颜色转换、core.time_to_day_night_ratio()、core.urlencode等标准库子集Lua 标准库assert、pcall、coroutine.*、table.*、math.*等其中string.dump被移除、load/loadfile/loadstring被改写为禁止加载字节码LuaJIT 的jit.*库与bit.*位运算库仅客户端 builtin 可用core.get_builtin_path()、debug.getinfo(...)、INIT sscsm。4.5 SSCSM 安全模型由于 SSCSM 脚本来自可能是恶意的服务端方向文档配套的 doc/sscsm_security.md 专门定义了威胁模型与多层防御威胁模型默认信任服务端是恶意行为者且因 Luanti 网络本身不加密任何能向客户端 IP 发送 UDP 包的人都可以冒充服务端服务端不得访问 API 明确暴露之外的任何信息文件、文件路径、设置等DDoS 不是关注点因为通过已有网络 API 本就容易压垮客户端且目标价值低上限原则SSCSM 的安全性上限是每个 API 函数都可退化为一个网络包端点安全投入不会超过这一基准Lua 沙箱 纵深防御脚本不能控制 GC垃圾回收这是防止沙箱逃逸利用堆布局原语的常见加固点进程隔离尚未实现计划中的独立 SSCSM 进程 Linux 下基于 SECCOMP 的沙箱文档以 FIXME 注明实现时再补充细节受控调用点只在极少数位置数据包处理器、客户端step()把控制流交给 SSCSM这些位置本身不假设客户端状态如库存必然存在从而规避 use-after-free 一类问题时钟精度限制os.clock()与core.get_us_time()的精度被限制为SSCSM_CLOCK_RESOLUTION_US20 微秒以缓解基于时间的侧信道攻击。这套设计把实验性功能的安全底线写成了可审计的工程决策是阅读路线图时最值得关注的部分之一。五、输入处理Input Handling打破键位与手柄瓶颈5.1 现状与痛点direction.md 指出输入系统存在两个相互关联的问题键位子集过小Luanti 当前只支持一小部分按键子集无法让游戏开发者映射设备提供的大部分按键。这极大限制了游戏创作者的可能性——他们要么实现笨拙的变通方案workaround要么干脆放弃该功能手柄支持是已知痛点某些手柄设备完全无法工作或带来令人不适的使用体验。从仓库中的 Android 输入实现android/icons 中的大量按钮 SVG如jump_btn.svg、inventory_btn.svg、chat_btn.svg以及 builtin/client/chatcommands.lua 的键位绑定命令可以看出当前输入仍以引擎预定义按键 有限键位枚举为主Mod 层缺少将任意设备按键绑定到游戏逻辑的统一机制。这正是中期路线图要解决的问题让按键映射能力对齐设备通常提供的绝大多数按键并修复手柄兼容性从而把输入控制的主动权交还给游戏作者。5.2 期望方向虽然方向文档没有给出具体 API 设计但从SSCSM 允许 Mod 覆盖客户端硬编码行为的目标可以推断输入处理重构很可能与 SSCSM 协同由服务端/游戏侧定义输入语义客户端负责设备层面的采集与映射。这意味着未来游戏可以声明按键 X 触发动作 Y而不必受限于引擎预置的键位常量。六、UI 改进统一 GUI API 与主菜单重做6.1 Formspec 替换从表单到统一 GUI方向文档明确提出需要一个formspec 替换方案formspec replacement目标是让 GUI 更好、更容易创建。更关键的是这个替换方案有可能同时成为 HUD 的替换方案从而提供统一 API。当前仓库中 formspec 与 HUD 是两套体系表单系统服务端 Mod 通过core.show_formspec()等 API 弹出表单详见 doc/lua_api.md 的 Formspec 章节由 src/gui 下的 GUI 控件树渲染HUD由 src/hud_element.cpp 与 builtin 的 builtin/game/hud.lua 维护是叠加在 3D 场景上的 2D 元素。两套机制在坐标体系、事件模型与 API 风格上都存在差异Mod 作者需要分别掌握。统一 API 的价值在于一次学习、一套事件、同时覆盖对话框与屏幕内嵌界面降低创作门槛并减少引擎维护负担。6.2 新主菜单第一印象工程方向文档直言第一印象很重要而当前主菜单在推销 Luanti 或解释它是什么方面做得并不好。 为此需要一个新主菜单new mainmenu来改善用户体验。主菜单当前由 builtin 的 builtin/mainmenu 下的 Lua 脚本驱动如tab_local.lua、tab_online.lua、tab_content.lua、tab_about.lua等页面模块配合 builtin/fstkFormspec ToolkitAPI 见 doc/fst_api.txt构建界面。新主菜单的目标是更好地向新用户传达Luanti 是什么、能玩什么、如何开始并提升整体观感。6.3 给贡献者的提醒方向文档特别提醒UI 代码正处于快速变化之中因此在投入大量时间实现大型改动之前务必先为任何大型变更提交 Issue。这与本文第三节介绍的Roadmap 标签 概念批准机制一脉相承——UI 层改动牵一发动全身先讨论、后实现是避免浪费的核心纪律。七、路线图的实际约束力贡献者如何参与综合 direction.md 与 .github/CONTRIBUTING.md可以整理出一条清晰的参与路径先读路线图确认你的想法是否契合三个中期目标SSCSM、Input Handling、UI Improvements或长期愿景先开 Issue 讨论非 bug 修复的大改动建议先用 Issue 获取预批准尤其是 UI 相关改动再提交 PR匹配路线图目标的 PR 应被标注为 Roadmap 并在描述中注明目标不匹配的 PR 必须在一个月内维护者视角为一周内获得概念批准否则会被关闭Bug 修复永远优先不受路线图门禁限制始终被接受并优先处理。这套机制保证了方向文档不只是愿景宣言而是可执行的工程治理规则——它决定了哪些代码能进入引擎、以什么顺序进入、以及什么情况下会被拒绝。八、总结与展望Luanti 的中期路线图围绕三个相互关联的基础设施目标展开SSCSM重新划分服务端与客户端的职责边界把脚本执行下沉到客户端沙箱为 Mod 提供低延迟的同步 API并缓解服务端负载——仓库中已具备完整的控制器/环境/事件通道骨架src/script/sscsm、内置脚本builtin/sscsm_client、API 参考doc/sscsm_api.md与安全模型doc/sscsm_security.md目前仅以enable_sscsm singleplayer加载预览脚本安全上限定为localhost及以下Input Handling计划打破键位子集限制、修复手柄兼容性把输入控制权交还给游戏创作者UI Improvements以 formspec 替换并可能统一 HUD与主菜单重做为抓手配合先 Issue 后 PR的纪律重塑引擎的创作与上手体验。对读者而言这份路线图的价值在于它是理解 Luanti 引擎未来演进的唯一权威入口也是判断我的贡献是否符合项目方向的决策清单。随着 SSCSM 安全机制逐步完善、输入抽象落地与 UI 体系统一引擎将朝着更易创作、更少硬编码、更干净的长期架构持续演进——而这正是 direction.md 作为路线图文档的核心使命。延伸阅读完整 API 参考见 doc/lua_api.md服务端 Modding与 doc/client_lua_api.md客户端 CPCSMSSCSM 详细接口见 doc/sscsm_api.md安全设计见 doc/sscsm_security.md贡献规范见 .github/CONTRIBUTING.md。【免费下载链接】minetestLuanti (formerly Minetest) is an open source voxel game-creation platform with easy modding and game creation项目地址: https://gitcode.com/gh_mirrors/mi/minetest创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Luanti（Minetest）开发方向与路线图解读：SSCSM、输入处理与 UI 演进全指南
LuantiMinetest开发方向与路线图解读SSCSM、输入处理与 UI 演进全指南【免费下载链接】minetestLuanti (formerly Minetest) is an open source voxel game-creation platform with easy modding and game creation项目地址: https://gitcode.com/gh_mirrors/mi/minetest导读本文以 Luanti前身 Minetest官方路线图文档 doc/direction.md 为主体系统梳理该开源体素游戏创建平台的长期愿景与中期开发目标Roadmap并深入剖析其中三大核心技术方向服务端下发客户端脚本SSCSM、输入处理重构与 UI 体系升级。文章结合仓库内的 SSCSM 实现源码、安全模型文档与贡献规范帮助读者理解路线图的制定机制、各目标的现实动因与工程落地现状为引擎开发贡献者、Mod 作者与对 Luanti 架构感兴趣的读者提供一份可检索、可验证的路线图导读。一、路线图文档在项目中的定位在 Luanti 的官方文档体系中doc/README.md 明确指出direction.md与 Luanti 未来发展方向相关的信息通常被称为路线图文档roadmap document。也就是说本文所依据的 direction.md 并非 API 参考或使用手册而是面向引擎开发的核心决策文件。它回答了Luanti 要往哪里走、为什么这么走、以及贡献者如何参与这三个关键问题是衡量每一个新功能 PRPull Request是否符合项目整体图景的准绳。仓库根目录的 .github/CONTRIBUTING.md 在合并条件一节中把以某种方式遵循路线图并契合项目整体图景列为第一优先级足见该文档的实际约束力。文档整体分为两大部分长期路线图Long-term Roadmap项目愿景与指导哲学由历史文档与核心开发者讨论沉淀而来中期路线图Medium-term Roadmap当前正在推进的、按优先级排序的开发目标约每两年评审一次。二、长期路线图项目的指导哲学direction.md 的长期路线图部分本身并不重复罗列愿景内容而是通过一组权威来源文档来承载项目的长期目标、追求与指导哲学历史存档文章《What is Minetest?》阐述了项目诞生之初的定位思考核心开发者 celeron55 发布的个人路线图以及他在 A clear mission statement for Minetest is missing需要一个清晰的使命宣言议题中的长篇评论后者是理解项目自我认知的关键材料核心开发者待办/愿望清单Core developer to-do/wish lists。这些材料的共同主题是Luanti 是一个开放的体素游戏创建平台其价值在于易修改easy modding与易创建游戏game creation而路线图机制正是为了在保持这一开放性的同时让引擎内核的演进有章可循。从仓库布局也能印证这一点games/、mods/、builtin/引擎内置的 Lua 基础库与 doc/lua_api.md 共同构成了面向创作者的分层体系任何内核改动都必须与这套生态兼容。三、中期路线图工作机制与参与规则3.1 目标来源与评审周期中期目标并非凭空产生而是来自一次路线图头脑风暴roadmap brainstorm该讨论收集了社区与核心团队排名靠前的发展建议并整理为当前的中期目标列表。该列表不区分优先级顺序in no particular order并且大约每两年评审一次以保证目标随时间推移仍然有效、与生态现状匹配。3.2 Roadmap PR 标签与概念批准机制为了让路线图真正落地到日常开发流程项目制定了明确的门禁规则针对路线图中某个目标提交的 Pull Request会被标记为Roadmap标签不在路线图上的 PR除非在一个月内获得概念批准concept approval否则将被关闭开发者可以先用Issue 进行预批准preapproval即先在 Issue 中讨论并获得认可再动手实现以避免返工Bug 修复不受此限制始终被接受并优先处理。这套机制在 .github/CONTRIBUTING.md 的概念批准与路线图Concept approvals and roadmaps一节中得到进一步细化非 bug 修复类 PR 若匹配路线图目标应标记为 Roadmap 并在描述中标注目标编号若不匹配则需在一周内获得概念批准才能保持开启。这也解释了为什么 direction.md 被贡献文档反复引用为评审依据——它是社区贡献者与核心维护者共同遵守的契约。3.3 三大中期目标概览当前中期路线图聚焦于三个方向它们分别触及引擎的脚本架构、输入抽象与用户界面三大基础设施层目标核心问题期望结果SSCSM服务端无法在客户端沙箱中执行 Mod 代码客户端脚本执行环境降低网络延迟改善架构Input Handling键位映射受限、手柄兼容性差让游戏开发者能映射设备上的绝大多数按键UI Improvements表单formspec与 HUD 割裂、主菜单体验欠佳统一 GUI API重做主菜单以下各节逐一深入剖析。四、SSCSM服务端下发客户端脚本4.1 概念与动机SSCSMServer-sent client-side modding服务端下发的客户端侧 Modding是Mod 作者与核心开发者都长期呼吁的功能。其核心思想是由服务端把 Modding 脚本发送给客户端客户端在沙箱中执行这些脚本。这与网页在浏览器中运行 JavaScript的模型高度类似——网页由服务器提供内容脚本则在用户机器上本地执行。为什么需要 SSCSMdirection.md 给出了三层理由规避网络延迟支持同步 API许多客户端行为需要同步完成例如瞬时响应输入若每次调用都走服务端往返延迟会破坏体验。SSCSM 环境下引擎可以提供新的脚本 API让 Mod 覆盖当前客户端中大量硬编码hard-coded的行为架构合理性某些 API 天生就应该存在于客户端而非把每次调用都通过服务端隧道传输tunnel every call through the server——后者只会在 SSCSM 到来后演变成技术债性能分流Mod 的部分计算可以迁移到客户端执行从而改善服务端性能。方向文档特别强调与其追求短期方案、积累必然爆发的技术债SSCSM 为可长期存续的更干净架构铺平了道路。这体现了路线图以终为始的设计哲学。4.2 仓库中的实现现状从源码结构看SSCSM 在仓库中已经形成了完整的代码骨架客户端控制器src/script/sscsm/sscsm_controller.h 中的SSCSMController类职责是作为 SSCSM 进程的 RAII 所有者、向 SSCSM 发送事件并处理请求runEvent同时对外隐藏独立进程 IPC的实现细节运行环境SSCSMEnvironment见 src/script/sscsm/sscsm_environment.h与控制器通过StupidChannel通信配合sscsm_irequest.h、sscsm_ievent.h、sscsm_events.h、sscsm_stupid_channel.h等文件形成完整的事件/请求处理链Lua API 绑定src/script/lua_api/l_sscsm.cpp 与 src/script/lua_api/l_sscsm.h 提供 SSCSM 环境的脚本接口src/script/cpp_api/s_sscsm.cpp 负责服务端一侧的脚本桥接客户端内置脚本builtin/sscsm_client/init.lua 是客户端 builtin 的入口它加载common/item_s.lua、common/register.lua等共享库并注册core.get_content_id()、core.get_name_from_content_id()等占位实现注释标明FIXME: send actual content defs to sscsm env——真实内容定义尚未下发沙箱安全初始化initializeSecuritySSCSM()见 src/script/cpp_api/s_security.cpp负责在安全模式下收紧 Lua 环境例如builtin/sscsm_client/init.lua在加载完成后主动置空debug.getinfo以兑现安全初始化承诺。4.3 如何启用enable_sscsm 配置项SSCSM 的启用由设置项enable_sscsm控制。仓库中的定义与使用位置默认值定义在 src/defaultsettings.cppsettings-setDefault(enable_sscsm, nowhere)即默认完全关闭启用判断在 src/client/client.cppg_settings-get(enable_sscsm) singleplayer时视为启用源码注释//FIXME: enum表明该逻辑未来应重构为枚举判断。配套的安全文档 doc/sscsm_security.md 进一步说明该设置并非简单的布尔开关而是四级作用域限制取值含义nowhere任何情况下都不启用默认值singleplayer仅在单人游戏本机启用localhost本地回环地址含单人游戏或更严格的范围lan局域网或更严格范围其他对所有服务器启用higher values安全考量是作用域分级的关键在localhost及更严格的取值下可以确认服务端运行在同一台机器上或代表服务端的角色就在本机其恶意风险几乎为零。而在足够的安全措施就位之前用户被禁止将该项设置为高于localhost的值。配置示例写入minetest.conf# 仅在单人游戏时启用 SSCSM 预览脚本 enable_sscsm singleplayer注意根据 doc/sscsm_api.md当前阶段尚不能由 Mod 自行添加 SSCSM 脚本只有在enable_sscsm singleplayer时引擎才会加载一个硬编码在 C 中的小型预览脚本preview script。因此本文档描述的更多是架构方向与 API 形态而非可直接投入生产的 Mod 功能。4.4 SSCSM API 形态速览doc/sscsm_api.md 勾勒了未来 SSCSM 编程环境的 API 面貌文档明确警告SSCSM 高度实验性API 必然变动Mod 必须做版本检查至少校验core.get_version().proto_max虚拟文件系统SSCSM 使用虚拟路径字典承载脚本文件路径形如modname:foo/bla.lua但文档建议依赖core.get_modpath()而非硬编码路径引擎按服务端 Mod 依赖顺序加载各 Mod 的modname:init.lua注册与全局回调core.register_globalstep(function(dtime))等SSCSM 特有 APIcore.get_node_or_nil(pos)、core.get_content_id(name)、core.get_name_from_content_id(id)注册表core.registered_items、core.registered_nodes、core.registered_tools、core.registered_craftitems、core.registered_aliases后者标注 TODO 仍为空工具 APIcore.log、core.get_us_time()精度受限、JSON 序列化、压缩/Base64、哈希sha1/sha256、颜色转换、core.time_to_day_night_ratio()、core.urlencode等标准库子集Lua 标准库assert、pcall、coroutine.*、table.*、math.*等其中string.dump被移除、load/loadfile/loadstring被改写为禁止加载字节码LuaJIT 的jit.*库与bit.*位运算库仅客户端 builtin 可用core.get_builtin_path()、debug.getinfo(...)、INIT sscsm。4.5 SSCSM 安全模型由于 SSCSM 脚本来自可能是恶意的服务端方向文档配套的 doc/sscsm_security.md 专门定义了威胁模型与多层防御威胁模型默认信任服务端是恶意行为者且因 Luanti 网络本身不加密任何能向客户端 IP 发送 UDP 包的人都可以冒充服务端服务端不得访问 API 明确暴露之外的任何信息文件、文件路径、设置等DDoS 不是关注点因为通过已有网络 API 本就容易压垮客户端且目标价值低上限原则SSCSM 的安全性上限是每个 API 函数都可退化为一个网络包端点安全投入不会超过这一基准Lua 沙箱 纵深防御脚本不能控制 GC垃圾回收这是防止沙箱逃逸利用堆布局原语的常见加固点进程隔离尚未实现计划中的独立 SSCSM 进程 Linux 下基于 SECCOMP 的沙箱文档以 FIXME 注明实现时再补充细节受控调用点只在极少数位置数据包处理器、客户端step()把控制流交给 SSCSM这些位置本身不假设客户端状态如库存必然存在从而规避 use-after-free 一类问题时钟精度限制os.clock()与core.get_us_time()的精度被限制为SSCSM_CLOCK_RESOLUTION_US20 微秒以缓解基于时间的侧信道攻击。这套设计把实验性功能的安全底线写成了可审计的工程决策是阅读路线图时最值得关注的部分之一。五、输入处理Input Handling打破键位与手柄瓶颈5.1 现状与痛点direction.md 指出输入系统存在两个相互关联的问题键位子集过小Luanti 当前只支持一小部分按键子集无法让游戏开发者映射设备提供的大部分按键。这极大限制了游戏创作者的可能性——他们要么实现笨拙的变通方案workaround要么干脆放弃该功能手柄支持是已知痛点某些手柄设备完全无法工作或带来令人不适的使用体验。从仓库中的 Android 输入实现android/icons 中的大量按钮 SVG如jump_btn.svg、inventory_btn.svg、chat_btn.svg以及 builtin/client/chatcommands.lua 的键位绑定命令可以看出当前输入仍以引擎预定义按键 有限键位枚举为主Mod 层缺少将任意设备按键绑定到游戏逻辑的统一机制。这正是中期路线图要解决的问题让按键映射能力对齐设备通常提供的绝大多数按键并修复手柄兼容性从而把输入控制的主动权交还给游戏作者。5.2 期望方向虽然方向文档没有给出具体 API 设计但从SSCSM 允许 Mod 覆盖客户端硬编码行为的目标可以推断输入处理重构很可能与 SSCSM 协同由服务端/游戏侧定义输入语义客户端负责设备层面的采集与映射。这意味着未来游戏可以声明按键 X 触发动作 Y而不必受限于引擎预置的键位常量。六、UI 改进统一 GUI API 与主菜单重做6.1 Formspec 替换从表单到统一 GUI方向文档明确提出需要一个formspec 替换方案formspec replacement目标是让 GUI 更好、更容易创建。更关键的是这个替换方案有可能同时成为 HUD 的替换方案从而提供统一 API。当前仓库中 formspec 与 HUD 是两套体系表单系统服务端 Mod 通过core.show_formspec()等 API 弹出表单详见 doc/lua_api.md 的 Formspec 章节由 src/gui 下的 GUI 控件树渲染HUD由 src/hud_element.cpp 与 builtin 的 builtin/game/hud.lua 维护是叠加在 3D 场景上的 2D 元素。两套机制在坐标体系、事件模型与 API 风格上都存在差异Mod 作者需要分别掌握。统一 API 的价值在于一次学习、一套事件、同时覆盖对话框与屏幕内嵌界面降低创作门槛并减少引擎维护负担。6.2 新主菜单第一印象工程方向文档直言第一印象很重要而当前主菜单在推销 Luanti 或解释它是什么方面做得并不好。 为此需要一个新主菜单new mainmenu来改善用户体验。主菜单当前由 builtin 的 builtin/mainmenu 下的 Lua 脚本驱动如tab_local.lua、tab_online.lua、tab_content.lua、tab_about.lua等页面模块配合 builtin/fstkFormspec ToolkitAPI 见 doc/fst_api.txt构建界面。新主菜单的目标是更好地向新用户传达Luanti 是什么、能玩什么、如何开始并提升整体观感。6.3 给贡献者的提醒方向文档特别提醒UI 代码正处于快速变化之中因此在投入大量时间实现大型改动之前务必先为任何大型变更提交 Issue。这与本文第三节介绍的Roadmap 标签 概念批准机制一脉相承——UI 层改动牵一发动全身先讨论、后实现是避免浪费的核心纪律。七、路线图的实际约束力贡献者如何参与综合 direction.md 与 .github/CONTRIBUTING.md可以整理出一条清晰的参与路径先读路线图确认你的想法是否契合三个中期目标SSCSM、Input Handling、UI Improvements或长期愿景先开 Issue 讨论非 bug 修复的大改动建议先用 Issue 获取预批准尤其是 UI 相关改动再提交 PR匹配路线图目标的 PR 应被标注为 Roadmap 并在描述中注明目标不匹配的 PR 必须在一个月内维护者视角为一周内获得概念批准否则会被关闭Bug 修复永远优先不受路线图门禁限制始终被接受并优先处理。这套机制保证了方向文档不只是愿景宣言而是可执行的工程治理规则——它决定了哪些代码能进入引擎、以什么顺序进入、以及什么情况下会被拒绝。八、总结与展望Luanti 的中期路线图围绕三个相互关联的基础设施目标展开SSCSM重新划分服务端与客户端的职责边界把脚本执行下沉到客户端沙箱为 Mod 提供低延迟的同步 API并缓解服务端负载——仓库中已具备完整的控制器/环境/事件通道骨架src/script/sscsm、内置脚本builtin/sscsm_client、API 参考doc/sscsm_api.md与安全模型doc/sscsm_security.md目前仅以enable_sscsm singleplayer加载预览脚本安全上限定为localhost及以下Input Handling计划打破键位子集限制、修复手柄兼容性把输入控制权交还给游戏创作者UI Improvements以 formspec 替换并可能统一 HUD与主菜单重做为抓手配合先 Issue 后 PR的纪律重塑引擎的创作与上手体验。对读者而言这份路线图的价值在于它是理解 Luanti 引擎未来演进的唯一权威入口也是判断我的贡献是否符合项目方向的决策清单。随着 SSCSM 安全机制逐步完善、输入抽象落地与 UI 体系统一引擎将朝着更易创作、更少硬编码、更干净的长期架构持续演进——而这正是 direction.md 作为路线图文档的核心使命。延伸阅读完整 API 参考见 doc/lua_api.md服务端 Modding与 doc/client_lua_api.md客户端 CPCSMSSCSM 详细接口见 doc/sscsm_api.md安全设计见 doc/sscsm_security.md贡献规范见 .github/CONTRIBUTING.md。【免费下载链接】minetestLuanti (formerly Minetest) is an open source voxel game-creation platform with easy modding and game creation项目地址: https://gitcode.com/gh_mirrors/mi/minetest创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考