公式の説明が示す中心は、Artifact をインベントリに配置し、Tablet で強化する関係です。全てを同時に動かすのではなく、一つの Artifact を見える場所へ置き、Tablet の表示を読み、移動前後の effect を比べます。weapon、chapter、他の upgrade は固定し、どの変更が結果を作ったかを追えるようにします。
Tablet の形や名前だけから hidden rule を推測しません。現在の表示、配置できた場所、起きた visible result、失敗した条件を分けて記録します。古い community の画像は問いを見つける手がかりであり、current base game の確定表ではありません。
制御した配置試験
最初に、確かめたい仕事を一つ決めます。例えば Artifact の effect が変わるか、移動の余白が残るか、weapon の action が安定するかです。配置前の状態を記録してから一箇所だけを動かし、同じ room と mode で同じ action を繰り返します。
戻す道を残す
Tablet を置くために全ての space を使い切らないでください。失敗後に元へ戻せる余白、次の reward を試す場所、敵から離れる movement を残します。きれいな layout が、run の安全を失わせるなら、その cost も結果の一部です。
現在のページが公開すべきもの
名前、形、仕事、必要な space、確認した version を分けます。数値が画面に出ていないなら埋めず、confirmed、observed、community lead、pending の label を添えます。Tablet 解放は条件を、Buildsは目的を担当させると情報が混ざりません。
再現できる配置記録
記録には開始時の inventory、変更した部品、固定した weapon と chapter、見えた effect、失敗時の位置を入れます。二つの部品を同時に変えると原因が分からないため、次の試験で一つだけ戻します。solo と co-op は別の context として扱います。
残すかを決める
同じ条件で結果が再現できたら、現在の観察として残します。一度だけの成功は興味深い lead ですが、万能な recommendation ではありません。更新後は最小の配置試験へ戻り、過去の結果を version 付きの history として保存します。
配置試験を終えるときは、良い結果だけでなく戻す手順も書きます。Artifact を元の場所へ戻せるか、Tablet を外した後に movement が回復するか、次の reward を受ける space が残るかを確認します。これらが分かれば、別の player が同じ layout を試すときに、失敗した後の安全な状態まで再現できます。
一つの表示だけで全ての interaction を説明しないことも重要です。weapon の timing、chapter の room、solo と co-op の差が結果に影響する可能性があります。固定できなかった条件は limitation として明記し、次の試験では変える条件を一つに絞ります。こうした記録は、更新後にどこから確認をやり直すかを示す地図になります。
配置を紹介するときは、読者が先に守るべき space と、試験を止める条件も示します。安全を失ってまで effect を追わない方が、長い run では有用なことがあります。