himeshi’s blog

Simutrans本体改造まわりのお話をつらつらと

Simutransで今、これからやりたいこと

ここ半年ほど、Simutransに対してまとまった時間を割くことが難しくなってきました。理由は仕事だったり私生活だったりいろいろありますが、30代手前となれば人生そうなるコースにもなるよなと自分自身では思います。少なくとも学生の時みたいに時間の大半を(趣味としての)Simutransに費やすようなことはもうないでしょう。

バグ報告や各種お問い合わせに対応できないことが増えており各方面にご迷惑をおかけしている一方で、他の方が問い合わせに答えてくれたりイシューの調査をしてくれたりすることが増えました。私が動けていないのでしかたがないので界隈の皆様がフォローしてくださっているというのが実情ではありますが、ともかくOTRP、Simutransの本体まわりに関することが特定一個人ではなくコミュニティによって支えられていく流れが始まったことは大変喜ばしいことです。

今は目の前にあるイシューや質問に対する対応が少しずつ委譲され始めている段階ですが、もう少し未来の話やスケールの大きな話もコミュニティに委譲されていく未来が来ることを願って、ひめしが今OTRPやSimutransまわりでやりたいこと、必要だと考えていることをここに書き残しておきます。直近でやるべきことからロングスケールで考えるべきことまであるので、そこに注意して解釈していただければと思います。

所要時間ベース経路探索まわり

OTRPの所要時間ベース経路探索自体の詳細については、下のリンクを参照してください。ここでは、所要時間ベースルーティングまわりで今後やるべきことについて整理しておきます。

github.com

動作の安定化、バグ取り

Simutrans交流会議(Discordサーバ)のotrppatch開発フォーラムにかなりの件数のバグ報告が溜まってきました。特に、既存のroute costベースでの経路選択にも不具合が生じており、どれも早急に解決したい問題ばかりです。

積載時の待ち時間計算の改善

旅客/貨物を列車に積載するかどうかを判定する際に、最速列車の待ち時間判定に課題があります。現在は積載実績から平均を出して待ち時間として使っていますが、実際優等の接続や待避を含むダイヤを組んで運用してみると過度に優等列車に旅客が偏る(実際には各駅停車が先着なのに優等に乗ろうとする)傾向が見られます。過去の実績を使うのではなく、実際に最速列車のうち一番すぐ到着しそうな列車を特定した上で、その列車の到着待ち時間を予測するようにしたいものです。

所要時間ベース経路探索下での最適な輸送戦略を整理したい

所要時間ベース経路探索は、Simutransの根幹である輸送シミュレーションのルール、理を根本から変えるものです。したがって、長年研究されてきたRoute cost法における輸送戦略とは全く異なる戦略でマップ開発を行う必要があるはずです。

所要時間ベース経路探索のトライアルNS鯖に参加させていただきましたが、初期には致命的な問題が次々と発生し、その解決で手一杯になりました。末期には逆に過度に旅客が集中する路線の輸送改善に手一杯となり、最適な輸送戦略の探求にはまだ遠い状態です。まずは早く動作を安定化させた上で、コミュニティの皆様にあれこれ試していただき輸送戦略のナレッジを蓄積していきたいなと考えています。

macOSでのNotarization問題

現在、Simutrans standardのapple silicon (arm64) mac版は配布されているバイナリが動作しません。これは、macOSが数年前に導入したNotarizationという仕組みによるものです。OTRPでは配布方法が異なるため現在は起動時の警告を無視すれば起動できますが、新OSであるSequoiaではNotarizeされていないバイナリの起動がさらに難しくなったようです。

macOSでは意図しないアプリケーションの実行を防ぐため、信頼できる開発者によるアプリケーションのみ実行を許す仕組みが用意されています。アプリケーションバイナリが信頼できる開発者によるものだと認識されるためには、開発者がApple Developer Programに登録した上で各種申請を行い、アプリケーションバイナリに署名する必要があります。

このフローのうち「Apple Developer Programに登録した上で」の部分が問題で、個人でやるにしろEnterprise扱いにするにしろApple Developer Programの年会費を支払う必要があります。Simutransは特定個人がオーナーのプロジェクトではなくコミュニティによる無償のプロジェクトなので、Apple Developer Programの費用負担を根拠をもって安定的に行うことは簡単ではありません。この問題に対する対応策は現在はまとまっていませんが、macOSへの対応を取りやめることを含めて対応策を検討する必要があると思います。

HMD(ヘッドマウントディスプレイ)環境のサポート

2024年現在、Apple Vision ProやOculus Quest 3といった日常使いに耐えうる汎用HMDが普及を始めており、ユーザが日常的に使うデバイススマートフォンやパソコンの時代からHMDに移り変わるパラダイムシフトが始まったと考えています。Simutransもこの先25年楽しく遊び続けられるゲームとして存在し続けるべく、HMD環境への対応をすべきだと考えています。

HMDのサポートといってもゲームを3Dにしようということを言いたいのではなく、ゲーム中のツールバーやミニマップなどを別ウィンドウに分離できるようにしたり、タップや視線といったHMD特有の操作方法に対応したりすることを想定しています。まだ世の中の交通、都市シミュレーションゲームにおいてここを考えられているゲームはそれほど多くないので、HMDサポートを早期に行うことによってHMD時代が到来した際には大きなアドバンテージになると考えています。

Simutrans Pak Manager

本体からは少し離れた話題になりますが、アドオン周りのアップデートも進めたいところです。C:Sやminecraftなどではユーザが作ったMOD(シムトラ的に言えばアドオン)はSteam workshopで一元管理され、ユーザはそこにアクセスさえすればMODを追加したり管理したりできます。(Steam workshopは個人的にはだいぶ使いづらいと思いますが。)

一方で、Simutransのアドオンは相変わらずユーザが配布サイトを自分で見つけて手動でダウンロードしてディレクトリに配置する形式です。また近年は諸事情により特定のNet Simutransにのみ提供されるアドオンが増えてきており、ユーザが自分でPak環境を構築しづらくなってしまいました。時代を考えれば、Simutransでも配布サイトを問わずユーザが自分の好きなツールでアドオンを一元管理し、簡単にアドオンを追加できるようにすべきです。またアドオン作者にとっても、配布したアドオンにアップデートが必要になった際には簡単にアップデートを配信できるようにすべきです。

このような状態を実現すべく、昨年10月にSimutrans Pak Managerをリリースしました。aptやhomebrewと同じようにSimutransのアドオンを管理できるようになることを目指しています。残念ながら開発自体はプロトタイプ版で止まっており今は動いていませんが、構想自体は捨てていませんので時間を見つけて動かしたいところです。

github.com

Steamでのアプローチ

これは定量的な調査結果ではないのですが、最近SimutransをSteamから知る人が増えているようです。Steamについて思うことはいろいろありますが、それでもSteamはゲーム配信のデファクトスタンダードになりつつあります。

一方でOTRPはSteamでの配信を行えていません。正確には、RoboronさんよりBeta版扱いでの配信をご提案いただいたのですが、それ以来十分にメンテナンスができていない状態です。

いつだったかのペルリさんによる調査で日本のSimutranserの6割超はOTRPを使っているとの結果がありましたが、おそらく時間が経って今は状況が変わっているはずです。少なくとも、OTRPの利用状況ログではOTRPユーザ数は微減を続けています。(このあたりについては別記事でまとめます)

また、これはOTRPに限った話ではありませんがSteamユーザにはworkshop経由で配布されているもの以外のアドオンを追加する難易度が高いです。これまで長い時間をかけて蓄積されてきたSimutransアドオンたちが活用される機会が失われ始めているわけですが、Steamから入ってくるユーザにもアドオンが供給され魅力的なゲームとして存在し続けるための策を何かしら打たなければならないと考えています。

収益化による開発人員の安定的な確保

ここまで書いてきたようにSimutransおよびOTRPではやらねばならないことが山積みな一方で、ひめし個人としての趣味の開発リソースはおそらくこの先先細りしていきます。Simutransはこれまでその時代その時代ごとにポッと開発者が出てきてその人が本体開発を担うという状況が続いてきましたが、ゲーム産業がますます発展しC:Sなどの競合タイトルの成長が加速する中で、Simutransも安定的な開発リソースを確保しないとこのさき安定的にプレイヤーに楽しさを届け競合タイトルに対して競争力のある状態を保つことは難しいと思います。

開発リソースの安定的な確保はなにもSimutransに限った課題ではなく、世の中のオープンソースプロジェクトがいつも苦しめられてきた課題です。ひめしはこれまで開発リソースを見出すべく開発ゼミを開催したり本を書いたりしてきましたが、やはり完全非営利の趣味のコミュニティでは限界です。一方、世の中の大規模なOSSを見ると、大抵の場合企業が自らの利益のためにスポンサーし、開発リソースも提供しています。この先Simutransを魅力あるゲームとして持続させ発展させていくためには、ユーザの規模を拡大し、何かしらの収益に繋げ、それでもって開発リソースを確保することが重要だなと考えているところです。ユーザ規模的にC:SとSimutransが同列に語られるような世界線を作りたいですね。Simutransはマルチプレイができたり旅客の流動計算が精密だったりと他の街づくりゲーにはないユニークな特徴があるので、ポテンシャルとしては十分にあると信じています。

とはいえ具体的にどういった仕組みをつくれば良いのかは全くアイデアがありませんが...orz

おわりに

今すぐやらないといけない話からものすごくふんわりとした話まで書きましたが、特に最近はSimutransコミュニティをもっと大きくしたいという思いが強くなっています。今年に入ってからはiOSエンジニアリングコミュニティにSimutransの布教を試みたり、欧州のSimutranserとオフ会をしたりしました。このあたりの話は年末のアドベントカレンダーにでも書こうと思います。

とはいえ私一人でできることはそう多くありませんので、界隈の皆様のご賛同、ご協力をいただければうれしく思います。