Infernus 是什么
Infernus
的名字来源于游戏中 id
为 411
的载具(特指 sa
中)。
Infernus
是一个基于 samp-node
打造的库,用于在 JavaScript
层调用游戏的 sdk
。
WARNING
Infernus项目已进入维护阶段并将逐步归档,后续生态建设将由omp-node社区主导推进,诚邀感兴趣的开发者共同参与。
🚧 施工中
- omp-node 目前正在积极开发中,未来它会取代
Infernus
。 - 如果您想尝鲜
omp-node
,或更喜欢原生语法而没有过多封装,请关注 @open.mp/node。
差异
/ | Infernus + samp-node | omp-node |
---|---|---|
运行环境 | Windows/Linux: Node.js 22.17+ | Windows/Linux: Node.js 18+ |
模块规范 | CommonJS/ESModule(实验性) | ESModule |
架构支持 | 仅x86 | x86/x64 |
底层实现 | 通过sampgdk→fakeamx→原生调用 | 直接调用omp-gdk/omp-sdk |
执行效率 | 低 | 高 |
兼容性策略 | 通过兼容层polyfill支持三方插件 | 插件需适配sdk并使用特定版本 |
设计理念 | 1. 提倡完全使用Infernus重构,避免Pawn代码开发 2. 强制采用Steamer替代原生接口 | 详见官方文档 |
缺陷
DANGER
是的,一切的开始前您需要了解缺陷。
一些缺陷极大影响了开发体验,建议您以实验性的心态尝试使用 samp-node
生态开发。
总的来说目前生态并不稳定,这是多方面因素导致的。
生态系统
INFO
点击查看已实现的生态包,不保证和原型库执行结果相同,且一定存在BUG。
原有的以 pawn
开发的库,如果您的项目必须依赖这些,那么目前而言会出现两种情况:无人开发或是不兼容。
由于 samp-node
的插件开发是基于 samp
而不是基于 omp
,所以对于 omp
而言,一些插件生态基本无法兼容,比如无法访问到一些插件的 native
函数,比如 raknet
。
这极大程度上的限制了基于 node
的 samp
插件生态库开发,这一点需要社区共同努力推进。
Bindings支持
很遗憾,本项目是基于32位的嵌入式node.js
,对于bindings
的支持是不稳定的,你可能会遇到报错等情况。
在使用本项目前,请注意以下版本要求:
Node版本匹配
- 请确保你的Node主版本号与samp-node依赖的版本一致
- 例如samp-node依赖22.17.0,则只能使用22.x版本
- 不兼容的版本如18.x、20.x、24.x等将无法正常工作
如果项目已经创建:
- 先检查Node版本是否符合要求
- 删除node_modules文件夹
- 重新运行
pnpm install
环境支持说明:目前better-sqlite3模块已在Windows平台测试通过
也许在未来64位的omp-node
上迎刃而解。
终端阻塞
重要信息
已通过 monkeyPatch 作为目前的解决方案,修复了此问题。
由于底层的 samp-node
对于部分异步的 node
生态库的兼容性不佳,会导致概率性的终端阻塞。
比如 typeorm/sequlize
等 orm
库,如果使用了,它将一直阻塞导致服务器未响应,除非您手动在终端敲下回车。
所以更建议您采取分布式开发,虽然这听起来很蠢……
即另外再建立一个数据库操作的 node
项目,比如用 nestjs
搭建 api
,专门用来 crud
,游戏服务端采用 http
请求来访问,或者您可以尝试用一些更高级的 rpc
或者 socket
来实现通信。
不过这样的好处是服务端只处理游戏逻辑,数据库逻辑交给另外的项目,顺手您还可以再开发一个后台管理系统,这样后台和服务端采用的是同一套 api
。
组成
通常来说您只需要关注第一层,即应用开发层。
Infernus
主要做的就是第二层和第三层的工作,依赖于 samp-node
和 omp
游戏服务器。
如果您不知道怎样开始建立一个项目,请参考 快速上手。
/ | 层 | 介绍 |
---|---|---|
1 | 应用开发层 | 游戏模式,比如自由或角色扮演 |
2 | 类包装层 | 通过类来调用函数式包装 |
3 | 函数式包装层 | 例如 samp/omp/streamer 的包装 |
4 | Samp Node | SDK 通往底层的桥梁 |
5 | Omp 游戏服务器 | 底层 |
为何开发
对于编程初学者或前端开发者而言,使用类似C语言的面向过程式语言(如Pawn)开发游戏脚本存在显著的学习门槛。相较于现代面向对象语言(如JavaScript),Pawn在基础API设计上更为繁琐——例如字符串拼接、数组操作等底层功能需手动实现,增加了开发复杂度。
此外,Pawn语言生态存在以下局限性:
- 异步支持薄弱:原生缺乏类似JavaScript中
Promise/Async
的异步编程范式; - 国际化障碍:由于Pawn编译器(SA-MP)诞生较早,其字符编码方案依赖操作系统本地化设置:
- 西欧系统默认采用
ISO-8859-1
编码; - 中文系统依赖
GBK
编码; - 与通用
UTF-8
标准不兼容。
- 西欧系统默认采用
这种编码强依赖性可能导致不可预见的兼容性问题,例如将GBK
数据直接存入UTF-8
数据库时,若无转译处理则会出现乱码。
而基于JavaScript的开发方案则能充分利用Node.js生态优势:
- 工具链丰富:日期处理(Day.js)、数据库驱动(MySQL/Redis/MongoDB)等成熟库;
- 异步标准化:原生支持
Promise/Async
异步控制; - 编码统一性:全栈采用
UTF-8
编码,规避国际化兼容问题。
通过迁移至JavaScript技术栈,开发者可显著降低学习成本,同时获得更健壮的国际化支持与现代工具链赋能。