Shipping an Isometric Game in the Browser With Three.js

使用 Three.js 在浏览器中发布等距视角游戏

A browser game has an unusual constraint: the first level begins before the player reaches the first level. The download, parsing, asset setup, input initialization, rendering pipeline, and first interactive frame are all part of the experience. When building an isometric action game with Three.js, architecture has to account for that startup path as carefully as the gameplay loop.

浏览器游戏有一个不同寻常的限制：第一关在玩家真正进入关卡之前就已经开始了。下载、解析、资源设置、输入初始化、渲染管线以及第一个交互帧，这些都是游戏体验的一部分。在使用 Three.js 构建等距视角动作游戏时，架构设计必须像对待游戏循环一样，仔细考量启动路径。

Keep rendering and game state separate

保持渲染与游戏状态分离

Three.js provides scene, camera, materials, geometry, animation, and WebGL abstractions. It does not prescribe a game architecture. Avoid making the scene graph the only source of truth. Gameplay systems should reason about entities, movement, combat, health, and interactions in a form that can be tested without requiring every object to be a rendered mesh. A clean boundary lets the renderer reflect state while simulation code remains understandable.

Three.js 提供了场景、相机、材质、几何体、动画和 WebGL 的抽象，但它并没有规定游戏架构。要避免将场景图（Scene Graph）作为唯一的真值来源。游戏系统应该以一种无需将每个对象都渲染为网格（Mesh）即可测试的方式，来处理实体、移动、战斗、生命值和交互。清晰的边界可以让渲染器反映状态，同时保持模拟代码的可读性。

Treat asset loading as a pipeline

将资源加载视为一条管线

GLTF is a useful delivery format, but imported assets still need conventions: scale and orientation; origin and pivot placement; animation naming; material expectations; collision representation; texture compression and dimensions; fallback behavior when an asset fails. Write validation tools or loading assertions early. One inconsistent model can create hours of debugging across animation, collision, and camera behavior.

GLTF 是一种实用的交付格式，但导入的资源仍需遵循规范：缩放与方向、原点与轴心位置、动画命名、材质预期、碰撞表示、纹理压缩与尺寸，以及资源加载失败时的回退行为。尽早编写验证工具或加载断言。一个不一致的模型可能会导致在动画、碰撞和相机行为方面花费数小时进行调试。

Design for mobile constraints from the start

从一开始就针对移动端限制进行设计

A desktop GPU can hide expensive decisions. Mobile hardware and thermal limits expose them. Watch: draw calls and material switches; overdraw from transparent effects; shadow-map cost; texture memory; object churn that triggers garbage collection; high-resolution rendering on dense displays; touch input and viewport changes. Adaptive quality is usually more useful than one rigid “high” setting. Resolution scale, shadow quality, particle counts, and effect density can respond to device capability.

桌面级 GPU 可以掩盖昂贵的计算决策，但移动硬件和散热限制会将其暴露无遗。请注意：绘制调用（Draw calls）和材质切换、透明效果导致的过度绘制（Overdraw）、阴影贴图成本、纹理内存、触发垃圾回收的对象抖动、高密度显示屏上的高分辨率渲染、触摸输入以及视口变化。自适应质量通常比单一固定的“高”画质设置更有用。分辨率缩放、阴影质量、粒子数量和效果密度都应根据设备性能进行调整。

Make the camera part of gameplay

将相机作为游戏玩法的一部分

An isometric camera must balance readability and atmosphere. Occlusion handling, character contrast, floor transitions, and click or touch mapping all depend on camera decisions. Test crowded scenes and small screens, not only attractive empty rooms. If input uses raycasting, keep the relationship between screen coordinates, camera projection, navigation surfaces, and interaction targets explicit.

等距视角相机必须在可读性和氛围感之间取得平衡。遮挡处理、角色对比度、地面过渡以及点击或触摸映射，都取决于相机的设置。不仅要测试美观的空房间，还要测试拥挤的场景和小屏幕。如果输入使用射线检测（Raycasting），请确保屏幕坐标、相机投影、导航表面和交互目标之间的关系明确。

Build observability into the loop

将可观测性构建到循环中

Track frame time rather than relying on how the game “feels” on one machine. Separate update cost from render cost. Record asset-load duration and failures. Add development overlays for entity count, draw calls, triangles, and memory-sensitive resources. Performance work becomes much easier when a regression has a subsystem and a timestamp.

追踪帧时间，而不是依赖游戏在单台机器上的“感觉”。将更新成本与渲染成本分开。记录资源加载时长和失败情况。添加用于显示实体数量、绘制调用、三角形数量和内存敏感资源的开发覆盖层。当性能回退有明确的子系统和时间戳记录时，性能优化工作会变得容易得多。

Eidolon is a public Mendola.Tech experiment in browser-based isometric action gameplay built with Three.js. Its source repository exposes the implementation for inspection.

Eidolon 是 Mendola.Tech 的一个公开实验项目，展示了使用 Three.js 构建的浏览器端等距视角动作游戏。其源代码仓库公开了实现细节以供查阅。

Prefer a small coherent engine

优先选择小型且连贯的引擎

It is tempting to add a library for every subsystem. Sometimes that is correct. But a browser game benefits from understanding its core loop, entity lifecycle, asset pipeline, and rendering ownership. The goal is not to avoid dependencies on principle. It is to keep the game’s critical path small enough that you can reason about startup, input, simulation, rendering, and cleanup as one connected system.

为每个子系统添加一个库很有诱惑力，有时这确实是正确的做法。但浏览器游戏如果能深入理解其核心循环、实体生命周期、资源管线和渲染归属，将大有裨益。目标不是原则性地避免依赖，而是保持游戏的关键路径足够小，以便你能将启动、输入、模拟、渲染和清理视为一个连贯的系统来思考。