微信小程序/小游戏转小红书 MiniTool 离线 H5 迁移引擎

设计理念：为什么不用传统类层级

README 用较大篇幅对比了两种设计路线，这是理解 EntityJS 的关键：

• 传统做法是构建类的继承层级。README 认为这恰恰是耦合最紧的设计：功能被严格绑定到某一个类上，难以移植到其他项目，想复制某个需要的函数也很麻烦；随着开发推进，类会越来越大、越来越复杂，最终出现控制大部分游戏逻辑的「上帝类」（god-classes）。
• 实体-组件做法把全部逻辑实现在组件（component）中，组件可大可小；然后创建实体（entity），向其中添加或移除组件。实体是其所有组件的实时表示。组件与实体之间低耦合，可以自由混搭组合出强大功能，同时保持可移植与健壮。

安装与命令行用法

README 记录的版本要求为 Ruby 1.8.1 及以上，并通过 gem 安装：

gem install entityjs

所有命令需在游戏根目录下执行：

• entityjs new mygame：使用默认模板创建新游戏；
• entityjs new mygame platform：使用平台模板创建游戏；
• entityjs templates：查看所有可用模板；
• entityjs comp rock：在 scripts/rock.js 创建名为 rock 的组件，并生成测试文件；
• entityjs comp display/hero：在 scripts/display 目录下创建 hero 组件；
• entityjs test name test1 test1：在 /tests/name_test.js 创建包含两个测试方法的测试；
• entityjs build：将引擎源码与游戏源码压缩合并到 /builds 下的单个文件；
• entityjs server：启动服务器，访问 localhost:2345 游玩，localhost:2345/test 运行测试，资源位于 localhost:2345/assets/*name。

短 getter / setter 与工厂

引擎提供了一种简写访问方式，同一个方法名既可赋值也可取值：

var tile = re.e('tile');
tile.tileX(1); // 设置
tile.tileX();  // 获取

setter 也可以用在 attr() 中，例如 tile.attr('tileX', 2)；带多个参数的 setter 如 tile.tile(1, 2) 可同时设置 tilex 与 tiley，等价于 tile.attr('tile', [1,2])。

README 中标注为 0.4.2 的特性是：所有组件都拥有工厂方法，用于创建复杂实体。示例中通过 re.c("button").factory(...) 定义工厂，之后可直接以 re.button("Hello", callback) 创建；也可以用 method 覆盖默认行为，例如实现单例式的 re.player()。

测试与地图编辑器

所有游戏使用轻量的 QUnit 进行测试，平台模板中包含示例测试。测试目录下可新建 factories.js 注册工厂，例如 factory('enemy', ...) 定义带初始生命值与状态的敌人，之后在测试任意位置用 factory('enemy') 或 re.e('enemy') 创建；需要多种变体时可用简写 f('enemy attacking', ...)。此外还提供了 expectTrigger、expectFlicker、expectListener 等实体断言，以及 keypress()、click() 等模拟输入方法，具体可查看 localhost:2345/qunit/ 下的相关文件。

地图方面，README 说明已兼容 Tiled 地图编辑器：在 /assets 下新建如 levels 的目录保存地图，代码中可用 re('level1.tmx')[0] 读取单个地图，或用 re('level') 查找该目录下所有关卡。

学习建议

• 该项目适合作为理解实体-组件架构与「组合优于继承」思路的阅读材料，README 对两种设计取舍的论述较为完整。
• 由于仓库处于重写阶段（Ruby → Node.js，转向实体系统），动手前应先确认 dev 分支的实际状态，避免按旧版命令操作。
• 若关注工程化流程，可留意其命令行工具链（新建、生成组件、生成测试、构建、本地服务器）与 QUnit 测试辅助方法的组织方式。