我正在 Prototyping 一款生存型跑路人/系统驱动模拟游戏，其 automation 是作为物理过程而不是 UI 层来实现的。
我不再通过菜单来配置机器，而是使用一种记录带将程序“编码”并物理地“捣鼓”成一系列。然后，将带子加载到机器中，并准确地执行程序。
玩家实际上操作的东西看起来是这样的：
00 00010
01 00010
02 00001
03 00001
04 00110
在程序过程中没有符号界面—只有一系列的二进制行。您一步一步地为这些程序建造，运行它们，然后观察结果。
在编程过程中并没有包含调解预览（在旁边显示的），它更像是一种诊断工具。核心交互仍在建造和推导这些编码序列。
一旦序列开始执行，它会一直运行到完成。您不能暂停，编辑或更正它。
目标不是真实主义，而是改变玩家对自动化的印象。相反，设置行为和微调行为变得不重要，而是设计一系列序列，承诺并观察其中的结果。
这会创建几个约束：
- 承诺 — 一旦执行开始，错误就会无法修复
- 执行成本 — 更长或效率更低的序列耗时和资源更多
- 信号暴露 — 游戏中，机器产生热/噪音，太多会导致系统被检测并移除
因此，优化不仅仅是关于效率——它是要在阈值范围内保持利用，同时仍然完成有用的工作。
我想要了解的是这种二进制、物理编程模型是否能够改善玩家对系统的思考模式，还是只是增加了摩擦力。
特定的问题我在探索包括：
- 是否通过直接与编码指令（而不是命令）来工作会改变玩家的理解能力和原因与效果之间关系？
- 缺乏可更改的可执行过程的意义在哪里？或者这仅仅是一种讨厌的性质？
- 进程中的承诺与迭代速度之间的界限在哪里？
- 是否decode预览的出现有用，还是它会破坏整个想法？
我会很感谢那些正在研究自动化系统、模拟设计或非传统交互模型的朋友们的想法：
P.S.：以下是游戏的界面的原型——Punch Machine，还有主界面是这么样的——Main
评论 (0)