一种基于优先队列的元素量程序模拟方法(草案)
本帖最后由 贝露赛布布 于 2022-10-9 07:38 编辑从萌新开始我们只知道元素火碰水，雷碰水之间会有一些交互，我们称之为元素反应
但是其中隐藏的官方未宣布机制其实相当多：{:5_225:}
例如：
- 附着计数器机制，即并不是每一次带元素的普攻，都能成功对对象附着对应元素量。
- 元素反应计数器机制，即并不是每一次可能发生元素反应时，对应反应一定发生。
- 上述两个机制都使用了计数器，配合一些标签进行操作。
针对这一套机制，目前的研究方法基本使用的是手动运算。{:5_214:}
例如对于衰减，通常是基于初始元素量和衰减速率来进行运算。{:5_214:}
对于程序相关的模拟，则处理方式不一。{:5_212:}[能够非常快捷地模拟面板变化，对于打轴分析buff进行了自动化。但是对于元素反应计时器相关问题，仍然需手动指定是否发生蒸发，扩散或者其他反应。对于著名模拟器gcsim，能够模拟相关问题，但是具体实现过程未有档案记录。
对于程序实现，大多数人可能会重于实践，而轻于写文档，对于程序文档背后隐藏的思想则更加少提及。
这可能会导致想法并没有广泛讨论，然后进行了某种未经广泛验证的实现，从而导致最终难以理解的现象偏差。日后有人想要实现时，又因为前人的文档未留下记录，而又继续重复造出另一个可能并不精确的车轮。
因此这篇文章，主要想提出对一种基于优先队列的元素量模拟方法，本质上而言，是一种数据结构思想，是一个对数值模拟本身的讨论和留档。
这篇文章可能的用处：
- 为各工具和程序创作者提供一种可能的实现思路。
- 对于原神本身程序如何运作的猜测。
- 对原神伤害程序模拟的理论打开一个良性讨论。
感谢各位前辈的研究。希望读者们能够对这种想法提供更多的思路或讨论。{:5_214:}
程序员君，你也在玩原神吗？{:5_235:} 程序员要早死的·。{:5_141:}
页:
[1]