Livesplit の SoB を使う上での注意点

Livesplit の SoB は区間ベストの和なので、確率の大小があるにせよ SoB は実際に出せる可能性があるタイムです。

しかし、正しくない区間ベストが保存されてしまうと実現不可能な SoB になる場合があるため注意しましょう。

この記事では、正しくない区間ベストが保存されてしまうことで現実不可能な SoB になってしまうケースを紹介します。

SoB とは
正しくない区間ベストが保存されてしまう例
正しくない区間ベストの影響範囲
1. 標準機能
2. 標準外のコンポーネント

SoB とは

SoB は全ての区間の区間ベストを合計したタイムです。
Livesplit では正式には Sum of Best Segments という名前で、Sum of Best と短縮して呼んだり、さらに略して SoB と呼んだりします。

それまでの履歴データから考えると全ての区間で完璧なプレイができればこのタイムが出せる、ということから理論値と呼ぶこともあります。

タイマーレイアウトに SoB を表示するには、レイアウトに Sum of Best というコンポーネントを追加します。（コンポーネントはレイアウト編集で追加・削除できる機能の単位）

正しくない区間ベストが保存されてしまう例

次のようなケースでは正しくない区間ベストが保存されてしまうことがあり、それによって SoB が実現不可能なタイムになってしまう場合があります。

SoB は自分にとって実現可能な最速タイムだからこそ指標としての意味があるので、実現不可能な SoB は指標としての意味を失ってしまいます。

チャートを間違えた・変えた

事例

例えば、区間 A, B, C とあって、区間 C に到達する前にとある行動 X を消化しておく必要があるとします。

区間 A で行動 X を消化するチャートだったのを間違えたり変えたりして、区間 B で行動 X を消化しました。
この時、元々は「区間 A のタイム＝区間 A の必須行動＋行動 X」となるところを区間 A の必須行動だけの時間で通過するため、区間 A の区間ベストを更新します。

この状態で区間ベストを保存してしまうと、本来必要な行動 X を消化する時間がどの区間からも消えてしまい、実際に通したタイムを考えた場合にあり得ない SoB になってしまいます。

対策・対処

チャートを間違えた場合

正しくない区間ベストがあったときは保存しないようにしましょう。

Livesplit は区間ベストを更新するとタイマーリセット時に更新した区間ベストの記録を保存するかを確認してくれます。

チャートを変えた場合

タイムの履歴データを消してしまって仕切り直すのが最も楽な対処だと思います。

履歴データをテキストエディタなどで開いて、チャート変更前のタイムをチャート変更後相当のタイムに書き換える方法も考えられますが、あまり現実的ではないと思います。

スプリットを忘れてスキップした

事例

区間 A でスプリットを忘れてスキップして、区間 B はちゃんとスプリットした、ということは割とあることだと思います。
この時、連続でスキップした区間の全てのプラスマイナスが最後の区間にまとめられます。

もしも区間 A も区間 B も区間ベストを更新していた場合、2 区間分のマイナスがまとめて区間 B のマイナスとして記録されてしまいます。

その結果、区間 B 単独の本来の区間ベストよりも早いタイムが区間 B の区間ベストとなってしまい、実現不可能な SoB になってしまいます。

対策・対処

Splits Editor で Others → Clean Sum of Best で SoB を再計算することができます。

また、Settings で Simple Sum of Best にチェックを入れておくと、スキップを含む複数区間分のタイムが区間ベストの計算から除外されるようになります。

計測誤差

事例

現実的に、タイマー操作が手動であっても自動であっても、タイマースタートやストップ、スプリットをする際に計測誤差が発生します。

例えば、区間 A 通過時にスプリットするタイミングが遅れて、区間 B 通過時にスプリットするタイミングが早かった場合、記録上の区間 B の区間タイムは本当の区間タイムよりも短くなってしまいます。
これ単独ではわずかな誤差でしかないことが多いのですが、区間の数だけ誤差が発生して累積するため、全体で見るとそれなりの誤差になることがあります。

これにより実際の区間ベストよりも早いタイムになってしまうため、実現不可能な SoB となります。

対策・対処

計測誤差を 0 にすることは原理的に非常に困難であり、残念ながら根本的な対策はありません。
しかし、次のような対策をすることで計測誤差の影響を低減することはできます。

区間を細かく分けていると、測定誤差による正しくない区間ベストの影響が累積しやすくなります。
明確な意図がないなら、程よい粗さで区間を区切るのが無難です。

Autosplitter などのタイマー操作自動化機能・ツールを導入することで手動操の誤差を無くすことができます。
ただし、このような機能・ツールを使ったとしても、計測誤差そのものを 0 にすることは原理的に非常に困難です。

経路の中間地点が乱数で変わる

事例

位置固定のスタート地点から出発し、ランダムで位置が決まる中間地点を必ず経由して、最後に位置固定のゴール地点に向かうような場合を考えます。
スタート地点から中間地点までを区間 A とし、中間地点からゴール地点までを区間 B とします。

ある試行ではスタート地点の近くに中間地点が配置され、区間 A（スタート→中間）で区間ベストを出しましたが、区間 B（中間→ゴール）は区間 A と比較して移動距離が長くなりました。
また別の試行ではゴール地点の近くに中間地点が配置され、区間 A（スタート→中間）の移動距離が長くなりましたが、区間 B（中間→ゴール）で区間ベストを出しました。
この時、区間 A（スタート→中間）と区間 B（中間→ゴール）の両方ともが区間ベストで通過できるような中間地点が理論的に存在できないため、実現不可能な SoB となります。

このケースでは部分的には区間ベストそのものは実際に出した正しい区間タイムなのですが、全体で見ると全ての区間で同時に区間ベストを出すことが不可能な状態です。

対策・対処

それぞれの区間ベスト自体は正しいタイムなので、他のケースよりも気付きにくいように思います。

このケースについては残念ながら有効な対処法を思い付きません。
このような性質のゲームでは SoB を有用な指標として活用することが難しいため、PB や Average など他のタイムを指標とするのが良いように思います。

正しくない区間ベストの影響範囲

SoB で注意したいポイントのそもそもの原因が「正しくない区間ベスト」なので、その影響範囲は SoB に限りません。

標準機能

Livesplit の標準機能の中では、SoB の他に次のようなものが正しくない区間ベストの影響を受けます。

Best Possible Time

想定ゴールタイムを表示する Run Prediction コンポーネントを使用して、想定ゴールタイムの計算元のタイムを区間ベストタイムにした時のタイムが Best Possible Time です。
計算元のタイムが正しくない区間ベストだと、計算結果の想定ゴールタイムが実現不可能なタイムになります。