himeshi’s blog

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

スクリプトツール機能開発の背景と今後の展望

どうも,ひめしです.

この記事は,Simutrans Advent Calendar 2020 6日目の記事です.

adventar.org

私にとって学生生活最後の年となった2020年は,OTRPの開発を続ける傍らでスクリプトツール機能の開発を行っていました.

 

この記事では,スクリプトツール機能の開発の背景と,中長期的な今後の展望についてお話したいと思います.

 

開発の背景

スクリプトツール機能を開発したのは,過去に幾度となく登場したfork版に存在する問題を解決するとともに,ゲームの機能開発を加速し,C:Sやminecraftといった商用MODゲームにSimutransを近づけるためです.

SimutransはC++で書かれており,一般に機能追加を行うためにはコードを変更し,コンパイルすることが必要です.この状況では,本家ではない外野の人間が機能追加を行う場合,コードをforkして,独自版として開発を行うことになります.これまでに私が知る限りでも,iron bite,ttt(tiny time table patch),OTRP,extendedが派生版として登場しています.

機能を追加するためにforkして派生版を作ることには2つの問題があります.1つめは,複数の作者による追加機能を同時に使うことができない点です.例えば,extendedに搭載された旅行時間に基づく旅客経路選択をOTRPで使うことはできません.派生版Aにある機能を派生版Bで使うためには,手動による移植を行い,コードの再ビルドを行う必要があります.これは大変手間のかかる作業であり,新規性のない機能移植作業に開発者は膨大なリソースを割く必要があります.

もう一つの問題は,本家追従の難しさとそれに伴う陳腐化の問題です.extendedを除くSimutransの派生版はほぼすべてが事実上単一の開発者によってコードの維持管理が行われているため,本家の変更点を継続的に取り込むことは容易ではありません.追従作業が行われなくなった派生版は本家と比べて陳腐化し,ユーザーは派生版独自の機能を諦めるか陳腐化した派生版を使い続けるかの選択を迫られることになります.大抵の場合取られる選択は前者であり,派生版で開発された機能は利用できなくなります.

機能開発をスクリプトによって行うことは,これらの問題を完全ではありませんが解決します.ユーザーは異なる作者によるスクリプトを(競合する場合はあれど)同時に使うことができますし,スクリプト自体の維持管理がされなくなった後も本体側との互換性が失われるまでは本家の新機能も問題なく利用できます.本家統合を目指す場合と比較した場合,統合に関するすり合わせが必要ないため,圧倒的な自由度と開発スピードを得られることは言うまでもありません.

C:Sやminecraftといった商用MODゲームが台頭する中,Simutransにおいてスクリプトで機能を開発できるようにすることは喫緊の課題でした.商用MODゲームがそのMODシステムにより有志の力を借りながら加速度的に機能を充実させていく中で,Simutransが本家コミュニティによる機能開発だけを待つのでは,他のゲームと比較しても急速に陳腐化が進むことは明らかだったからです.Simutransはソフトウェアの構造上C:Sのような自由度の非常に高いMODシステムを導入することが難しいのですが,少しでも外部からのアルゴリズム注入をしやすくするのは非常に重要です.

Dwatch氏の尽力により,Simutransではプレイヤー,シナリオ,ツールの3つをスクリプトで記述可能になりました.今後は本体開発とコミュニティ形成の両面から,有志によるスクリプト開発を促進し,新機能開発を加速させていく必要があると考えています.

 

スクリプトツールにおける今後の展望

とかく難しそうなイメージを持たれがちなスクリプトツールですが,スクリプトツールはアドオンと同等,もしくはそれ以上にプレイヤーが簡単に導入,使用ができるべきだと考えています.既存ユーザーの心理的障壁を考慮し,アドオンと全く同じように使えることが必要です.これを踏まえて,今後行われるべきであろうことがらを以下に3つ列挙します.

スクリプトツールのpak化

現行の仕様ではスクリプトツールの導入を行うとき,tool.nutおよびdescription.tabが含まれたフォルダをpak/tools/に配置し,カーソルpakをpak/に配置します.単一のpakファイルを配置すれば良いアドオンの導入と比較して若干煩雑に見えます.生のテキストファイル(nutとtab)を配置するこの仕様は,開発のしやすさを考慮した上での仕様なのですが,完成品のツールに関してはカーソルpakも含めて単一のpakファイルにまとめて配布できるようにするべきだと考えています.

menu項目の標準命名規則の策定と普及

ツールをメニューバーに表示させるためには,menuconf.tabで定義されたキーと同じ値をdescription.tabのmenu項目に記述する必要があります.このキーに関する取り決めがないと,ツールを導入するごとにツールに応じてmenuconf.tabを編集する必要があります.そこで,menuconf.tabにおけるスクリプトツールのキーの命名規則を策定し,日本語化Wikiで提案しています.

japanese.simutrans.com

Ayura氏の「らくらくクリックくん」は,この規格に準拠したメニューバーです.

https://www.simutrans.sakura.ne.jp/portal/articles/らくらくクリックくん-ver2-0

GUIのサポート

ツールの中にはパラメータを渡すのが望ましい(例えば信号の等間隔設置ツールでは,間隔を数値で渡したい)ものがあります.しかし,現行のスクリプトツールの仕様では取れる入力はツールの実行座標のみです.このため,パラメータは予めコード内で定義してある必要があります.例えば,JCT自動建設ツールも,コードを編集して道路アドオン名を指定する必要があります.この仕様がユーザーにやさしくないのは言うまでもないでしょう.

この問題に対する一つの答えは,GUIのダイアログを用意してあげることです.スクリプトでウィンドウを構成できるようになれば,対話的なツールを実装することも可能になります.しかし,現行のSimutrans Squirrel APIGUI部品およびウィンドウの表示をサポートしていません.したがって,GUIをサポートするための本体開発が必要になるでしょう.

 

おわりに

本稿では,スクリプトツール機能を開発するに至った背景と,今後必要な施策についてお話しました.私に残された時間を考えると,これらの施策は私がやるというよりは,誰かやってくださいという感じのものですが,今後スクリプトツールが多くの人に使われるようになれば幸いです.