核心战斗机制的设计理念

为什么是”副附着→主一击”的二段攻击？

在原神本体中，元素反应通常通过切换角色来实现：一个角色附着元素，另一个角色触发反应。但在千星奇域的自定义地图中，玩家只能操控一个角色，无法通过切人来组合元素。

这个限制催生了本作的核心设计：用一个角色的两次攻击来模拟”两人配合”。

  • 第一次攻击（副元素附着）：用当前副元素攻击，伤害系数为 0，只负责”附着”——相当于”辅助角色”
  • 第二次攻击（主元素一击）：用当前主元素攻击，全额伤害——相当于”主 C 角色”

两次攻击之间有 10ms 的间隔，确保副元素的附着先于主元素的爆发，让千星奇域的反应检测机制可以正确触发。

为什么用元素球切换元素？

既然不能切角色，那就需要一种方式让玩家在战斗中更换持有的元素。元素球就是答案：

  • 拾取元素球 → 主元素变为球的属性 → 原主元素变为副元素
  • 这相当于”用一个操作同时更换了主 C 和辅助的角色属性”
  • 玩家需要根据战况判断：当前需要什么反应？先收集哪个球？要不要留着某个元素等下一个球？

这种设计让”收集”不再是简单的跑腿，而成了战斗策略的一部分。

灵感来源

本作的玩法设计受到一些经典游戏机制的启发：

灵感来源 在本作中的体现
闯关爬塔 逐关推进、难度递增、每关有独立的通关条件
元素反应 原神本体核心机制，6 种反应各有效果
节奏管理 限时倒计时、5 秒可拾取窗口、10 秒敌人生成节奏
资源取舍 拾取一个球会替换当前主元素，旧的变成副——需要规划拾取顺序
风险奖励 超时未拾取 → 深渊球（风险）；深渊球可用净化道具恢复（奖励）

为什么有些事不能全交给 Genshin-TS

Genshin-TS 擅长的是将游戏逻辑从可视化节点图转换为可管理的 TypeScript 代码。但它不是万能工具，有些事情必须结合千星奇域编辑器来完成：

需要在编辑器中完成的工作

工作 说明
地形搭建 场景的地面、墙壁、平台、装饰等需要手动放置
预制体放置 敌人出生点标记、触发器边界、UI 控件等在编辑器中摆放
UI 布局 计时器显示、球数统计、元素图标、消息队列等 UI 控件在编辑器中排版
节点图框架 在编辑器中创建空的节点图，Genshin-TS 将代码注入到这些图中
结构体定义 千星奇域的自定义结构体必须在编辑器中定义，代码无法创建
碰撞触发器 碰撞触发器的范围、启用/禁用等需要在编辑器中配置
资源 ID 管理 Prefab ID、UI 控件 ID、Config ID 等需要与编辑器中的实际对象对应

Genshin-TS 的固有约束

  • 节点图作用域不支持：递归、async/await、Promise、JSON.*、Object.*、class 实例化
  • while(true) 有执行上限，必须改用定时器或显式计数器
  • 编译时 Math.random() 的值在构建时固定，运行时随机必须用 f.getRandomInteger()
  • TypeScript 代码中看似普通的操作（如字符串 + 拼接、if 判断），在节点图作用域中可能编译为不同的行为

更多实现层面的迂回方案和踩坑记录，请参见开发笔记。

设计原则总结

原则 说明
一条规则只做一件事 击杀=设置可拾取、超时=变深渊球、触碰=更新元素，每个行为职责清晰
有限资源 + 有限时间 元素球数量有限、可拾取时间有限、关卡时间有限——玩家需要在约束中做决策
清晰的反馈 收集球 → +30 分 + 图标更新、反应击杀 → +100 分 + 反应名显示、深渊球 → 追踪攻击
容错和逃生 死锁检测弹重置窗、防掉落拉回、断线超时判负——避免玩家卡死
渐进式教学 第 1 关只学收集、第 2 关只学净化、第 3 关只学战斗——每关引入一个新概念