OTRP開発終了によせて
私，ひめしが4月より就職することをうけ，OTRPの開発を3月末で終了することにしました．OTRPの今後の扱いなどについては，下のツイート群を参照してください．
【 #OTRPatch 開発終了のお知らせ】
— OTRP【公式】 (@OTRPatch) 2021年3月2日
4年あまりにかけて皆さまにご愛用いただいたOTRPですが，このほど @himeshi_hob の就職に伴い，3月末をもちまして開発を終了します．皆さまの多大なるご支援，ご愛用ありがとうございました．
（次ツイートに続きます）#Simutrans
アナウンス的なお話は先のツイートで済んでいるので，この記事ではポエムっぽいことを書き連ねていこうかなと思います．
結局OTRPとは何だったのか
ひめしが欲しかったSimutrans．これに尽きます．
本家にあまり取り合ってもらえなかったので派生版として自分で自分が欲しい物を作った，というだけの話です．
OTRPの成果物に関する研究は皆さんがんばってください（丸投げ）．ひめしは主にローカルマップで楽しく遊んでおります．
開発者の育成の試み
Simutransのメジャーな派生版として，Extendedがあります．ExtendedはExperimentalの時代から随分と長い間開発が続けられていますが，これは継続的に複数の人々が開発に関わっているから，というのが大きいです．
OTRPの開発を始めた当初から，私には就職というタイムリミットがある，という話は分かりきっており，この4年間，OTRPのコードをいじれる人をどうにかして作れないかと試行錯誤してきました．2017年の夏には新宿で丸一日の開発ゼミをやり，18年の年末には教科書を書き，20年にはそれをフリーアクセス化，同時にDiscordで開発ゼミも開催しました．
この試み自体が失敗に終わったのかどうかは，まだ結論には早すぎると考えています．ただ，OTRPの開発を引き継げる人を作るという観点では，完全に失敗です．
この話をTwitterに投げたところ，コードに関するドキュメントを整備してくれというご意見をいただきました．たしかに，コレコレこういう処理はここに書いてありますという日本語のドキュメントがあれば便利だとは思います．しかし，全てのクラスのドキュメントを整備することはあまりにも工数がかかりすぎ，かつコードは頻繁に変更されるので，せっかくコードに関するドキュメントを整備しても一瞬で陳腐化してしまいます．結局，ヘッダファイルをドキュメントとして読めるように書いておくのが現実的であり，現在のSimutransのコードはそのようになっています．こういったコードの読み解き方については「Simutransの本体開発」に書きましたので，ぜひお読みください．
OTRPと格言
OTRPはおかげさまでそこそこの完成度をもったプロジェクトに成長できましたが，開発，運営にあたってアタマに置いていた格言がいくつかあるので，紹介します．
千里の道も一歩から
古くからよく知られたことわざです．OTRPの開発では，二車線走行や増解結など，実装の難易度が高い機能の開発がいくつかありました．
こういった機能の開発で大切なのは，まず青写真を描いたあとに，手のつけられそうなところから少しずつやっていくということです．最初に青写真を描いておかないと，手を付けるべきところがわかりませんし，途中で軌道修正が必要になったときにゴールを見失ってしまいます．
全体像が見えたら，大事なところから実装...とはあまり考えずに，小さなところでも手のつけやすいところから実装していくと精神衛生上良いと思います．実装を進めるうちにこちらもレベルアップしていくので，難題にも立ち向かえるようになる，といった具合です．コアとなる処理はだいたい難易度が高い場合が多いので，いきなり手を付けるとたいていわけがわからなくなります．
Done is bettern than perfect.
（完ぺきにするよりまず終わらせろ）
FacebookのCEOであるザッカーバーグ氏の有名な格言です．
OTRPは，機能実装のスピードをきわめて重視していたので，とりあえず動きそうな状態になったら細かい調整をする前にリリースしていました．完ぺきを目指していたらいつまでもリリースできないからというのもありますが，どうせリリースすれば開発段階で見えていない問題がたくさん出てくるので，それらをあぶり出してから全部いっしょに解決してしまうほうが効率がよかったからです．
ただし，リリースするにしても「終わらせる」必要はあります．プロダクトが部分的にしか完成していない場合，既存のものと組み合わせるなど何かしらの形で可用性はしっかり確保してから出す，といった具合です．
なお，これは途中から気がついたのですが，特に日本のユーザーを相手にする場合，いたずらに開発途中の状態でリリースするのはユーザーの信用を損ねます．ユーザーがはじめてそのプロダクトを触ったときに，致命的なバグを踏むような状態では，あとからアップデートしてもそのユーザーはもう戻ってこないからです．なので，特にOTRP後半からは，基本的に手元のテストで何かしらの明らかな問題が見られるときはリリースを見送っていました．
早く行きたければ、ひとりで行け。
遠くまで行きたければ、みんなで行け。
ビジネス書とかで幾度となくお目にかかる格言です．OTRPは本家フォーラムとの交渉（みんなで行く）に耐えきれず，ひとりで行くことを選択してしまったプロジェクトなので，そんなに遠くまでは行けなかったわけです．
スクリプトツールの開発のときは，本家に載せないとどうしようもなかったこともあり，スピードを犠牲にしてきちんと交渉することを選択しました．「みんなで行く」ことを選択するのであれば，進捗に期限を設けてもだいたいどうにもならないので，いつか話しが通ればいいな程度の考えでどっしり構えるのがいいと思います．本家フォーラムでは，話が数ヶ月放置されたあとに突然拾われて採用，みたいな話がよくあります．
ひとりでやることと，みんなでやることははっきりと分離しましょう．そうすることで，ひとりでやることについてはスピード感をもって取り組むことができます．
今後のSimutransはどうなるのか
今後こうなりますという未来予想図を正確に描くことはおそらく誰にもできないと思います．ですが，これから4-5年はザックリこんなもんだろうと予想しています
- 2021年いっぱいまではOTRPが引き続き日本のデファクトスタンダードであり続ける．
- 22年あたりぐらいになると，本家standardが完成度の高い状態で様々な新要素を搭載するようになり，OTRPが見劣りし始める．
本家standardのスクリプトAPIがさらに拡充され，高機能なスクリプトを利用するためにstandardへの移行が始まる． - 23年になると，OTRPと新standardの勢力が拮抗するようになる．この頃になると，新standardでしか使えないアドオンが出現する可能性がある．この時期Extendedがなんか楽しいことをしてくれるかもしれない．
- 24年以降になると，OTRPを引き続き使い続ける人は少数派となり，今とは全く違う本体シェア構成となる．新しい派生版が出てくるかもしれない．
いずれにせよ2020年末からのstandard開発の盛り返しを見ると，OTRPの陳腐化は相当な速さで進むと思います．
謝辞 Acknowledgement
OTRPの開発にあたり， ahakuokuくんとLeartin氏の貢献は特筆すべきものとしてここに書き残しておきます．
ahakuokuくんには，OTRP開発と運営にあたり，コーディング以外のほぼ全てにおいて本当に助けてもらいました．彼は錯綜するバグ報告を見事にまとめ，ユーザーからの相談に的確に対応し，諸々の雑用を一瞬で片付けてくれました．4月以降TwitterのOTRP公式アカウントは彼が担ってくれるとのことで，本当に頭の下がる思いです．
Leartin (in the simutrans international forum) showed me deep insights and proper ways when I was stucked in difficult problems. The convoy coupling feature is one of the most difficult problems for me and I did the implementation of it three times. Leartin proposed me an uncomplicated and effective solution for this and the current architecture is based on Leartin's proposal.
（Leartin（本家フォーラム）さんは，私が難しい課題で悩んでいる時に，的確な道筋を示していただきました．特に，増解結は3回も実装をやり直す難題でしたが，Leartinさんは完結で効果的なアーキテクチャを提案してくださり，増解結の現在の仕様はLeartinさんの提言によるものです．）
おわりに
OTRPの時代はここに終わりました．Simutransがどのような形であれ今後も進歩を続け，多くのプレイヤーを魅了し続けるゲームであり続けることを心から願っています．
