それぞれの時刻制御方式の比較


用語:
  planned_split_time
    TTTでの駅間計画時間指定のこと

  offset/cycle
    TTTでのcycleとoffsetを指定しての始点発時刻指定のこと

  timing_signal
    (これから作ろうとしている) 周期時間制御での鉄道信号機のこと

  「時間」と「時刻」の使い訳 (できるだけ)
    「時間」は量をあらわし「時刻」は時間軸上での位置をあらわすことにしたい


性質1:
  planned_split_time は、絶対時刻から独立。相対時間にもとづく運用計画
    一つの列車を安定して走らせる技術

  offset/cycle と timing_signal は、絶対時刻にもとづく。
    (一般に)複数の列車の間の関係を決める

性質2:
  timetable由来のもの(planned_split_time と offset/cycle)は、物体(乗り物)に直接作用する

  timing_signalは乗り物が移動する「場」に直接作用する


timetable系は全ての乗り物に対してまとめて有効だが、
timing_signal は船舶や飛行機には使えない。
(制約をかける場の性質が無いため。だったら作ればいいという話も)


TTTのplanned_split_time:
  Pros:
  - 一つのスケジュール画面で一つの列車種別の運行全体を管理できる
  - ダイヤの感覚をつかみやすいし、把握もしやすい
  - 全ての乗り物に使用できる。(乗り物共通のコードを修正するだけでよい)
  Cons:
  - 時間設定を修正すると大騒ぎが起きることも
  - ダイヤが無茶だと自律回復は不可能 (ダイヤ改正と遅延リセットが必要)
  - スケジュールに記憶が必要になる (timing_signalよりも、おそらく量が多い)

TTTのoffset/cycle:
  Pros:
  - planned_split_timeとまとめて管理できる (見る場所がスケジュールまわりだけ)
  - 必ずしも等間隔である必要はない
  - 全ての乗り物に使用できる。コードも一つだけ。
  - 細かく設定していけば施設を他種別と共用して節約できる
  Cons:
  - 列車ごとにoffsetを与えていかないとならない
  - 一周後の遅延が酷いと悲惨なことに (ある程度はロジックで吸収可能)
    段落ちというかパターン落ち
    (次回の出発を決めておくとか、自動調整とか、結局ピッチベースとかいろいろ考えられるけど、どれも複雑度が増すだけのような気もする)
  - かならずスケジュールの先頭での調整になる
    (調整対象の駅を入力できるようにすれば良い？ でもUIが繁雑になる)

timing_signal:
  Pros:
  - 筋をかんたんに落とせる
  Cons:
  - 自動車、線路もの系にしか使えない (船、飛行機はまず無理じゃないかと)
  - 必ず等間隔
    (ただしこれに複雑なタイムテーブルを持たせるという方法もあり得る。
     ただそれやっちゃうと、timing_signalのシンプルさが完全に失われる)
    (もしくは複数を直列に使って公倍数による制御とか？)
  - 全てをこれに頼るとあちこちに建てることになり、まとめて管理するのが面倒
    (UIの整備で対応可能？)
  - 制御点では種別ごとにホームが必要 (一つの信号が一つの種別の出発間隔を決めるので)

これらは組み合わせ方でいろいろ変えられる。


planned_split_time と offset/cycle の併用:
  完全なタイムテーブル
  しかし大遅延に弱い

planned_split_time と timing_signal の併用:
  要所だけtiming_signalでおさえて、全般的な安定性は planned_split_time に任せる
  大遅延があっても筋を落として継続
  ただし、この組み合わせの時に遅延計算がどう作用するかは微妙

ちなみに、offset/cycle と timing_signal は併用する意味がない。


なんとなく想像する使い分け:

  比較的シンプルな種別数、パターンのとき:
   timing_signalベース (適宜、planned_split_timeを併用)
   種別ごとの等間隔が基本
   なんといっても設定、調節が簡単。
   大遅延対応も問題なし。一度決まればメンテフリー
   同時に扱う種別が増えてくると計画、設定、設備などどれも負荷が高まる

  複雑度の高いパターンや多数の種別、路線での施設共用のとき:
   どうせ頭を使うことになるので、かっちりtimetabling (offset/cycleベース)
   ホームや引き上げ線などを複数種で共用できる (しっかりした計画が必要だが)
   大遅延時の手動対応(運輸指令の手間)が必要 (現実世界の鉄道事業者と一緒)


コードで考えると:

  timetable 系:
    乗り物のsync_step()呼び出しはどうせいつもやってるし、
    その中で発車判定もやっているので、あまり処理量、計算量は増加していない。
    記憶量を喰っていることの方が問題としては大きい
    パッチとしては: セーブデータが変わる以外はプログラムの修正だけで済んでしまう

  timing_signal:
    welt から sync_step() が呼ばれる対象が増えるので、
    シミュレーションインフラでのオーバヘッド (正確には見積れていないが) も増えてしまう。
    記憶は相対的に見て圧倒的に小さい
    パッチとしては: obj 種別 (あるは副種別) が増えてしまう -> makeobj にも影響
      pak も作る、配布する、入れる必要がある

処理負荷についてはたぶん、車両数と駅数でどっちが多いかみたいな判断も必要かな。



結論(?)
つまりまあ、適材適所だし、それぞれ違う「組む楽しみ」があるというわけで。
どっちもあっていいんじゃないかな。