CoffeeScript 版 HTML5 贪吃蛇（coffee-snake）

TombEngine（社区常简称 TEN）是一个以 C++ 编写的开源自制关卡引擎，服务对象是《古墓丽影》经典作品（初代至五代）的自定义关卡作者群体。它的出发点并不在于复刻某一部作品，而是替换掉原版引擎，让作者在新框架下继续使用熟悉的素材与工作流。官方 README 明确写出该项目的两个目标：废除经典引擎的种种硬性限制，以及修复长期存在的缺陷；在此之上再引入新特性、改良旧特性，并尽量把关卡制作流程做得对作者友好。因此它更接近一个"运行时 + 创作工具链"的基础设施，而不是一款可以直接下载开玩的成品游戏——玩家实际体验到的内容，来自关卡作者用 Tomb Editor 制作并由 TEN 加载的项目。

从 README 列出的当前支持范围，可以看出这个引擎在保留经典味道的同时做了哪些现代化改造：脚本层采用 Lua 作为原生脚本语言；内置大量来自原系列 1 至 5 代的对象资源；渲染与运行层面支持高帧率、抗锯齿、mipmapping 以及 SSAO（屏幕空间环境光遮蔽）；所有对象都具备完整的蒙皮（skinning）支持；几何编辑不再受"只能正交"的束缚，提供完整的斜向几何支持；地图尺寸不再设上限；同时重新梳理了玩家控制方案，使其更加精简顺手。这一组特性基本覆盖了老引擎最常被作者抱怨的几个痛点：帧率与画面观感、模型动画表现力、关卡空间受限、以及操作手感僵硬。

创作流程上，TEN 与同组织的 Tomb Editor 配套使用，后者负责关卡搭建与测试，其仓库单独托管。README 给出的编译指引也体现了这种分工：编译出引擎二进制之后，需要另外建立一个目录作为主 TEN 目录（也可以用 TombIDE 直接创建一个测试工程），把 Build 目录中的全部产物复制进去，并准备好关卡数据与贴图文件，才能让 Tomb Editor 构建出的关卡在 TEN 中运行。这意味着想完整体验或参与开发，至少需要理解"引擎运行时"与"关卡工程"两套目录的关系，而不是简单双击一个可执行文件。

核心特性

技术实现方面，仓库是一个典型的 Windows 原生 C++ 工程，入口为 Visual Studio 解决方案 TombEngine.sln。README 列出的先决条件是安装 Microsoft Visual Studio 与 Tomb Editor；编译完成后若系统提示缺少 DLL（例如 bass.dll 等音频相关动态库），需要把 Libs 目录中的对应文件复制到主 TEN 目录。工程依赖 NuGet 包，若 Visual Studio 提示包缺失，可按官方建议删除 Packages 目录后在解决方案上执行"Restore NuGet Packages"，仍不奏效则通过 NuGet 包管理器手动安装 directxtk_desktop_2019 与 Microsoft.XAudio2.Redist。这些细节说明引擎在图形与音频侧分别依赖 DirectX Tool Kit 与 XAudio2 相关运行时，属于贴近 Windows 平台底层 API 的实现路线，而非跨平台抽象层封装。

许可与社区层面需要特别留意：TEN 采用的是一份经过修改的 MIT 许可，仅允许非商业用途，若要用于商业产品必须另行确认授权。README 同时声明该项目与 Crystal Dynamics 及 Embracer Group AB 无隶属关系，《古墓丽影》是该公司的商标，团队不对源码或二进制单独/配合第三方素材的非法使用负责，代码按现状发布，由无报酬的志愿者在业余时间维护。参与方式上，官方欢迎各种程度的贡献，包括功能建议、缺陷报告与代码提交，主要沟通渠道是 Discord 服务器。

对于想通过该项目学习的人，TEN 提供了一个规模可观、真实在用的游戏运行时样本：可以研究渲染特性（抗锯齿、mipmapping、SSAO）如何被接入一条老派管线，研究全对象蒙皮与动画系统的组织方式，研究以 Lua 作为脚本层与 C++ 核心交互的绑定设计，也可以观察地图尺寸解限、斜向几何这类"在老约束上做结构性突破"的工程取舍。与此同时也要有心理准备：这是一套 Windows 优先的大型 C++ 工程，构建链涉及 Visual Studio、NuGet 与若干预编译动态库，首次编译失败往往来自包还原或 DLL 缺失，而非代码本身；此外引擎的可玩内容依赖第三方关卡资源，仓库本身并不附带完整游戏。

技术要点

平台支持方面，README 的编译与运行说明全部围绕 Windows 上的 Visual Studio 展开，未提及 Linux 或 macOS 的官方构建方式，因此这两个平台的支持情况应以官方后续文档为准