_
JEV 游戏演示将一个抽象问题转变为一个可观察的问题：决策模型能否接收不断变化的 游戏状态，在 可执行动作 中进行选择，并在游戏需要继续之前返回有用的答案？ JEV 不能替代发动机。这是较大游戏循环内的有限决策步骤。具体参考，请比较JEV末日实验，JEV Pong 实现_、_NPC 架构指南 和JEV 实验室棋盘游戏和本地-NPC 示例_。这些是需要研究的示例，不能保证每个游戏都具有相同的延迟或集成合约。JEV 游戏演示证明了什么一个有用的演示使边界可见。游戏代码拥有世界状态和规则，生成当前可能的操作，要求 JEV 评估键入的决策，并在执行前验证答案。公开的例子包括街机风格的游戏、棋盘游戏位置以及实时控制实验，例如《毁灭战士》或《乒乓球》。它们的细节不同，但模式是状态输入，有限决策输出。JEV 在游戏循环中的位置_观察权威事实.不可能过滤操作.询问 JEV 输入的问题。根据当前响应验证响应状态.通过命令、行为树、能力系统或控制器执行。在事件、完成意图或有界后重新考虑定时器._
渲染和物理可能会在每一帧运行，而战术决策则运行得更慢。每个渲染帧调用决策服务都会增加延迟和抖动。 JEV 应该处理有意义的 Choices；转向、碰撞、动画、复制和多人游戏权限保留在确定性系统中。
什么游戏代码拥有
_世界状态、物理、导航、碰撞、命中检测和权限。允许 NPC 感知和信息知道.可执行动作，参数、前提条件和执行处理程序.超时、过时响应检查，速率限制和 兜底策略 行为._
- JEV 的贡献
- JEV 可以选择一名候选人，Score 候选人，或回答有界的是或否问题。它对游戏呈现的 Choice 做出上下文敏感的判断；它不应该发明一个完整的动作序列。从三到六个有意义的选项开始，并在现有游戏代码中保持执行。
- 延迟、频率和
- 没有通用的节奏。回合制游戏每回合可以决定一次；战术游戏可能会在威胁出现后或每隔几百毫秒做出决定；探索伙伴可以决定其目标何时改变。测量从状态捕获到验证执行的完整路径。每个请求都需要一个截止日期。如果已经晚了，请保持当前意图，移动到掩体，运行编写的行为树，或保持立场。
- 如何评估演示
- 检查状态投影和 可执行动作 是否可见，是否安全地拒绝无效响应，决策节奏是否与渲染分开，以及是否显示确定性 兜底策略。强大的演示会记录所选操作、延迟、有效性和 兜底策略 原因。
值得比较的四种演示模式
Arcade 演示测试 rAPId 在小状态下的动作选择。类似于《毁灭战士》的实验测试智能体是否能够在视觉状态快速变化的情况下继续行动。乒乓球和类似的游戏使行动空间变得明显，并立即暴露错过的最后期限。 NPC 或棋盘游戏演示测试一个较慢但更丰富的问题：模型能否在不掌握规则的情况下权衡目标、威胁和合法举措？
- 这些演示不应通过单个标题延迟进行比较。它们在观察成本、操作计数、网络路径、渲染循环和 兜底策略 策略方面有所不同。公平比较会记录每次运行的相同字段：状态大小、候选数、决策截止时间、中值和尾部延迟、有效结果率、兜底策略 率和任务结果。
- 实用演示Score卡
- 尺寸什么记录为什么事项 _决定节奏事件驱动、回合制或定时显示模型是否在右侧使用层操作空间候选计数和参数类型显示结果是否有界并且可测试 新鲜度状态版本和陈旧结果率测量实时竞争条件播放行为超时或无效输出后将演示与弹性游戏分开系统 _结果获胜率、生存率、客观进展或设计者评级衡量有用的行为而不是模型活动_
- 将演示转变为生产切片
_记录确定性基线策略.选择一项具有明确所有者的决策和三到六个决策可执行动作.在将网络调用添加到实时关卡之前离线重播记录的状态。介绍截止日期和时间扩展操作空间之前兜底策略s。比较质量、延迟、成本和兜底策略速率分别._
最强的JEV游戏页面因此不仅仅是一个画廊。它解释了演示证明了什么、未证明什么以及团队在发货前应收集哪些工程证据。
对于 NPC 架构，请阅读
JEV 。对于 API 合约，请参阅JEV API 用法_。对于 Unity 集成，请继续
JEV Unity 教程
.
Four demo patterns worth comparing
Arcade demos test rapid action selection over a small state. A Doom-like experiment tests whether the agent can keep acting while the visual state changes quickly. Pong and similar games make the action space obvious and expose missed deadlines immediately. NPC or board-game demos test a slower but richer question: can the model weigh goals, threats, and legal moves without taking ownership of the rules?
These demos should not be compared by a single headline latency. They differ in observation cost, action count, network path, rendering loop, and 兜底策略 policy. A fair comparison records the same fields for each run: state size, candidate count, decision deadline, median and tail latency, valid-result rate, 兜底策略 rate, and task outcome.
A practical demo scorecard
| Dimension | What to record | Why it matters |
|---|---|---|
| Decision cadence | Event-driven, turn-based, or timed | Shows whether the model is used at the right layer |
| Action space | Candidate count and parameter types | Reveals whether the result is bounded and testable |
| Freshness | State version and stale-result rate | Measures race conditions in live play |
| Fallback | Behavior after timeout or invalid output | Separates a demo from a resilient game system |
| Outcome | Win rate, survival, objective progress, or designer rating | Measures useful behavior rather than model activity |
Turning a demo into a production slice
- Record a deterministic baseline policy.
- Choose one decision with a clear owner and three to six legal actions.
- Replay recorded states offline before adding network calls to a live level.
- Introduce deadlines and 兜底策略s before expanding the action space.
- Compare quality, latency, cost, and 兜底策略 rate separately.
The strongest JEV game page is therefore not just a gallery. It explains what the demo proves, what it does not prove, and which engineering evidence a team should collect before shipping.
For NPC architecture, read JEV NPC. For the API contract, see JEV API usage. For Unity integration, continue to the JEV Unity tutorial.
