himeshi’s blog

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

Simutransカンファレンス2021 運営の振り返り

先日10月16日に開催したSimutransカンファレンス2021は、最大同時参加人数33人と、大盛況のうちに幕を閉じました。参加、発表していただいた皆様、ありがとうございました。

ひめしは本イベントの運営チームとして参加しました(なお主催はかわごえ氏であり、ahakuoku氏にも運営に尽力いただきました)。来年の開催に向けて、参加後に実施したアンケートの結果とその考察をここに書き残しておきます。アンケートの回答数は24でした。

なお、アンケート自体は匿名ですが、個人の特定を防止するため個別の回答の開示はいたしません。ご了承ください。

アンケート結果とその考察

本イベントに対する満足度を教えて下さい

f:id:himeshi:20211021193135p:plain

5段階中4と5が半々でした。全体的に満足度の高いイベントとなったようです。

次の開催はいつ頃がよいと思いますか?

f:id:himeshi:20211021193350p:plain

22年中の開催を望む声が大半のようです。個人的にはネタの蓄積のことを考えると22年後半が妥当かなと考えていますが、22年前半を望む声が7割となっています。たしかに年末はアドベントカレンダーの季節と重複するので、次回は6月か7月頃を検討しても良いのかもしれません。

次回の開催場所としてふさわしいのはどこですか?

f:id:himeshi:20211021193722p:plain

次回もオンライン開催をしてほしいとの声が6割近くになりました。たしかに、会場を借りて開催していた2019年までの実績では参加者が30人を超えたことはなかったので、オンライン開催による地理的ハンデの解消はかなり重要であると考えられます。対面開催はカンファレンスとくっつけて大規模な飲み会などを開催できることが大きなメリットですが、Simutransの知見を共有し、広くあまねくプレイヤーどうしが交流するというカンファレンスの目的を考えると、コロナウイルスが収束してもずっとオンラインのほうが適切なのかもしれません。なお、オンライン開催の場合は運営上の理由により次回はDiscord以外の会議ツールを使用することを考えています。(後述)

次回の開催内容として望ましいのはどれですか?

f:id:himeshi:20211021205308p:plain

スライド発表、マップ展覧会ともに好評だったようですので、次回のカンファレンスでも2本立てで行こうと思います。ただし、2つのイベントを同日開催するのは詰め込みすぎ感も否めないので、参加者が増えれば2日間開催も検討すべきなのかもしれません。

【スライド発表】今回は7名が発表しましたが、発表者数は適正でしたか?

f:id:himeshi:20211021205513p:plain

スライド発表者7名程度では、枠に制限を設ける必要はなさそうです。

【スライド発表】今回は発表枠を10分に限りましたが、次回はどうしてほしいですか?

f:id:himeshi:20211021205605p:plain

オンライン開催では20分枠は長過ぎるという考えから今回は10分枠のみの設定としましたが、5分枠、20分枠もあったほうがよさそうです。勝手に20分ほど発表するケースも数件見られたことから、20分枠を設定した上でタイムキーピングを厳格化する必要があると考えられます。

【マップ展覧会】試遊システムで快適にマップを触れましたか?

f:id:himeshi:20211021205935p:plain

大きな支障はなかったものの、快適性に難ありという意見が多かったようです。

【マップ展覧会】試遊システムでどんな不具合がありましたか?

  • 画質が荒いと思った
  • ドラッグアンドドロップはかなり感度が高めだと感じました。
  • クリック関連の操作に支障を感じた
  • 不具合というよりは同時に複数人触るので見たいところが見ずらかった。発表者だけが触れるルームなどもあるとよかったかもしれない。
  • 複数人の操作が共有される為、操作の指針などがあるとよかった

やはりローカルで遊ぶよりは快適性に劣るようです。「複数人で触る」システムをどう使えばいいのかわからなかったとの声も目立ちました。結局、発表者が触るのを聴衆が見るというGo Live的な使い方をしている場面が多かったようです。

参加者が自分で見るだけであればローカルで実行するほうが快適に遊べることは否めませんので、導入の手間の問題および配布による著作権の問題とどう向き合うかは今後も課題になると考えられます。次回は、ファイルの配布とブラウザアクセス両方を提供してもいいのかもしれません。

【マップ展覧会】同時に発表する人数は適切でしたか?(今回は3人でした)

f:id:himeshi:20211021210834p:plain

同時に開催されているセッションを全部聞けないのは惜しいという声も多く聞かれましたが、同時に3人のほうがよいという声のほうが多数派なようです。

【マップ展覧会】発表時間30分は適切でしたか?

f:id:himeshi:20211021211016p:plain

今回は発表時間を30分としましたが、事前の説明に時間を要したため実際にマップを触れた時間は20分程度でした。事前説明の時間をきちんと考慮して、実際にマップを触る時間を30分となるようにするのがよさそうです。

 

その他の運営上の課題

アンケート項目とはしませんでしたが、運営の視点から課題として感じられた点がいくつかありましたので、それについてまとめておきます。

発表時間の管理について

今回スライド発表の発表時間は一律10分でしたが、20分にわたって発表がつづいたケースが数件見られました。本来発表者に対して適切に残り時間をお知らせし、スケジュールの維持に務めるべきでしたが、運営の準備がそこまでまわっておらず参加者の皆様にはご迷惑をおかけしました。

残りの発表時間をお知らせする定番としてベルを鳴らす方法があります。今回もahakuoku氏がベルを鳴らしていたのですが、Discordの仕様によりベルの音がほとんど発表者に届きませんでした。次回のカンファレンスにおいては、発表者に残り時間をわかりやすく提示するとともに、タイムオーバした発表者に対して毅然とした対応を行うことが必要だと考えられます。

Discordの使用について

昨年のシムトラ学会6につづき今年もDiscordのGo Liveを用いましたが、運営上深刻な問題が2つありました。

  • GoLiveの視聴は自動的に開始されないため、発表者が変わるたびに参加者全員が手動で視聴先を切り替える必要がありました。この結果、30人近い参加者全員の視聴開始を毎回待つ必要があり、著しい時間のロスが発生しました。
  • 一部のPowerPointユーザで、アニメーションを用いたスライドが共有されない不具合がありました。このため、一部の発表者は発表が不可能になりました。

これらはDiscordの仕様でありイベントの進行に著しい支障をきたすものでしたので、次回はDiscord以外の会議ツールを使うべきだと考えています。具体的なツールとしてはzoomを想定していますが、zoomにも以下の問題が考えられます。

  • 荒らし参加者の流入制御がDiscordよりも手間になる。(Discordの場合は事前にサーバに参加している人だけがイベントに参加できる。また、なりすましユーザかどうかの判別がつかない)
  • zoomを普段使いしているユーザが本名暴露事故を警戒し、使用に対して難色を示される。また、参加者によって名前が適切に設定されないとDiscordやTwitter上の名前と紐付かない。
  • Simutransカンファレンスのイベント規模では有料プランの利用が事実上必須。

会議ツールの選定は今後の課題だと考えています。

対面開催の併用およびサテライト会場設置の際の機材運用問題

今回のSimutransカンファレンスは完全オンラインイベントということになっていましたが、実は一部で非公式にサテライト会場が設置されていました。ただし、こうしたサテライト会場ではマイクとスピーカの配置および運用に起因するハウリング問題などが発生しがちで、実際に今回もその問題が見られました。

サテライト会場の発生自体は禁止すべきではないと考えていますが、適切に機材を運用しないとハウリング問題や回線容量不足による通信障害が発生します。特に前者はイベント参加者全員の体験を悪化させるので、運営側がノータッチというわけにもいきません。よって、サテライト会場を設置する際のハウリング対策を義務化するとともに、代表的な対策方法を提示するといった取組が必要になると考えられます。

 

以上、来年の運営の参考になれば幸いです。

 

日本人プレイヤーのための本家フォーラム参加のてびき

本記事では、機械翻訳の利用を前提にして、Simutransの本家フォーラムに参加するにあたって知っておくべきことを紹介します。

日本勢が本家フォーラムに参加する最も典型的な目的は新機能の開発、導入に関する交渉だと思いますので、本記事では新機能について議論することを前提にお話します。

機械翻訳の利用

本家フォーラム(https://forum.simutrans.com/)は英語での議論が原則であり、これまで英語が苦手な日本人の参加を阻んできました。しかし、近年機械翻訳技術の著しい進展により、機械翻訳単体でも安定してそれなりに読める文章を生成することが容易になりました。

言うまでもありませんが、本家フォーラムに参加している人たちは全員が英語ネイティブではありません。したがって、多少の英語の乱れは許容されています。英語を日本語にするときも、日本語を英語にするときも、以下のどちらかのツールを利用すれば良いと思います。

Google Chromeには、ページをまるごと翻訳する機能がブラウザに組み込まれています。使い方は下のリンクを参考にしてください。

Google Chromeのページ翻訳ツールを有効にする方法 | パソコン工房 NEXMAG

オススメは、フォーラムのスレッドを読むときはChromeのページ翻訳機能を使い、メッセージを投稿するときはDeepLで日英翻訳を行う方法です。こうすることで、素早く快適にスレッドを読むことができ、かつ正確に意思疎通を行うことが期待できます。

メッセージを投稿するときに英語ができる人に英文をチェックしてもらうことはあくまでオプションです。チェックをお願いするのが面倒であれば、さっさとDeepLの出力結果をそのまま貼って投稿しましょう。

本家フォーラムのルールおよび慣習

本家フォーラムでは英文の乱れには寛容であるかわりに、ルールの遵守が求められます。必ず一度は以下の記事に目を通してください。英語で書かれているので、早速Chromeのページ翻訳機能を使いましょう。

forum.simutrans.com

特にこのフォーラム特有のもので重要な条項は以下のとおりです。

  • 同一人物が同じスレッドに2回以上連続して投稿すること(double post)は禁止されています。但し、24時間以上間隔があいていればこの限りではありません。
  • 1つのスレッドでは1つのことがらだけ議論してください。2つ以上の事柄を議論する必要があるときは、スレッドを分けてください。

議論及び交渉の一般的な心がけ

英語の壁がなくなったからといって本家フォーラムでスムーズに議論できるわけではありません。本家フォーラムで目的を実現するためには、以下のことに気をつける必要があります。

  • いわゆる「クレクレ星人」的な振る舞いは嫌われます。本家nightlyの開発を担っている人たちもヒマではありませんので、要求ではなく提案をし、自ら開発プロセスに参加してください。
  • 本家フォーラムに参加している人たちは、「欧州に住んでいる人」と「米国に住んでいる人」が多数派です。鉄道や街づくりに対する認識は、日本人とかなり異なります。また、欧州勢と米国勢でも認識が異なることが多いです。日本人の価値観を勝手に前提とせず、参加者が持つ鉄道や街づくりに対する価値観を最大限尊重し、それらを整理しながら議論を進行することが必要です。
  • フォーラムには下の画像のようにバッジがついているユーザがいます。バッジがついているユーザは基本的に2年以上フォーラムで活動し、かつ何かしらの業績を上げた人であり、「常連さん」の扱いです。議論するときは、バッジがついているユーザの同意を得ることを目標にしてください。

f:id:himeshi:20211007205930p:plain

本家フォーラムの主要人物

本家フォーラムには長年にわたって貢献し続けている人々がいます。彼らの立場を知ることは、議論をすすめる上で重要です。その一部をここで紹介しておきます。この情報は記事を執筆した2021年10月時点の情報です。Extendedで活躍している人物については原則省略しています。

  • Prissi氏 ... Simutrans standardの開発リーダー。nightlyへのコミット権を持つ
  • Dwachs氏 ... Squirrelまわりを中心に見ている。nightlyへのコミット権を持つ
  • ceesac氏 ... コードのリファクタリングを中心に活動。nightlyへのコミット権を持つ
  • Isaac Eiland-Hall氏 ... Forumのサーバー提供者。アメリカ人。機能開発に口を挟むことは少ない。
  • Jamespetts氏 ... Extendedの開発リーダー。Extendedの参考にするために、たまにstandardの案件にも顔を出してくる。
  • Leartin氏 ... pak192.Comicの開発リーダー。機能開発のスレッドに対して積極的に建設的な意見を発信する。
  • Yona-TYT氏 ... 開発者。機能開発のスレッドに対して積極的に意見を発信する。

現在Activeなユーザのうち、nightlyへのコミット権を持つのはPrissi, Dwachs, ceesac氏の3名のみです。その他の開発者はフォーラムにパッチファイルを投稿した後、コミット権を持つ人のうちいずれかが代理でコミットする仕組みです。そのため、最終的にパッチをnightlyに取り込むかどうかの決定権はこの3名にあります。但し、ceesac氏とDwachs氏は主に見る領域が限定されているため、基本的にはPrissi氏の判断によってパッチはnightlyに取り込まれます。

新機能に関する議論と交渉をスムーズに行うために

本家フォーラムにおける議論のスピードは、日本のTwitterやDiscordにおけるそれと比べてかなり遅く、スレッドに投稿するのはせいぜい一日数回です。よって、機能追加を行うための議論は基本的に数ヶ月かかることが普通です。

機能追加のための議論を実際にフォーラムで行うときは、以下のことを意識しましょう。

  • 提案する機能は可能な限り小さいものにしましょう。いきなり大きな構想を語っても、誰も議論できませんし実装もすすみません。大きなプロジェクトも小さな単位に分割し、一つ達成するごとに次を出すようにしてください。
  • 最初の投稿では、まず数文で完結に「何を実現したいか」を述べます。その後、そのモチベーション、実現したいこと、機能の詳細などを、可能な限り詳細にかつ具体的に述べます。可能な限り、図や動画を併用して説明してください。
    なお、フォーラムのスレッドには64KBまでのファイルしか添付できませんので、画像は下のサービスなどを用いて別途アップロードしてください。(本家フォーラムと同じid, passwordで入れます。)

    simutrans-germany.com

  • バグ報告を除き、コードの実装は基本的に提案者が行うものです。よって、こちらが行うのは「提案」であり「要求」ではありません。
  • フォーラムでは頻繁に議論が発散します。議論の発散を防ぐために、スレッドに返事が来たらすぐに返信し、議論の主導権を常に持ち続けてください。投稿が来たことを把握するために、メールによる通知機能を使用してください。
  • 機能要件の議論をするうちに、あれもこれもと要件が膨らんでいくことがよくあります。要件が膨らむと実装が大変なだけでなく、パッチを投稿しても大きすぎて見てもらえなくなるので、追加された要件についてはスレッドを分けて議論するようにしてください。

このように、本家フォーラムで機能追加に関する議論を行うには、数ヶ月の間継続的に、スレッドへの投稿に素早く反応することが求められます。これを一人で行うのはしんどいので、フォーラムに慣れないうちは2,3人でチームを組んで議論に参加するのがおすすめです。

おわりに

少し前までは日本人プレイヤーの要望はとりあえずOTRPが吸収していましたが、そんな時代も終わりました。日本勢に必ずしも好評とは言えない仕様変更も見られるようになった今こそ、日本のプレイヤーが本家フォーラムで議論に参加することがこの先のSimutransの明暗を分ける状況になっています。

英語という障壁を機械翻訳で克服したとしても本家フォーラムでの議論には忍耐と辛抱が必要ですが、その先にはよりよいSimutransが待っています。皆さんが少しでも本家フォラームでの議論に参加するようになり、Simutransが魅力的なゲームになることを期待しています。

 

 

Simutransカンファレンス2021 開催のお知らせ

Simutransカンファレンス2021を以下の通り開催することにしましたので、お知らせいたします。皆様ふるってご応募ください。

スケジュール

  • 10月3日(日)スライド発表応募締切
  • 10月9日(土)マップ展覧会発表応募締切
  • 10月16日(土)13:30-18:00 Discordサーバ「Simutrans inst Japan」にてオンライン開催

プログラムは10月10日ごろに発表する予定です。

聴講は「Simutrans inst Japan」Discordサーバにご加入であればどなたでも自由にしていただけます。参加ご希望の方で当サーバに加入されていない方は、ひめしにお声がけください。

イベント概要

本イベントの主催者はかわごえ(@EF65_536)です。ひめしは運営スタッフとして参加しております。本イベントに関するお問い合わせは、Twitter @simumeeting2017 もしくは適当なDiscordサーバにてお願いいたします。

なお、本イベントは昨年まで「シムトラ学会」として開催していたものを引き継いだものです。

Twitterハッシュタグは、 #SimuConf2021 です。

スライド発表

Simutransに関する話題について、1枠10分で発表していただきます。DiscordのGo Live機能を使用して、スライドを流しながらお話していただく形式です。あなたのSimutransに関する知見を共有し、議論しましょう。

イメージとして、昨年開催したときの動画を掲載します。

www.youtube.com

 

マップ展覧会

あなたが普段遊んでいるローカルやNSのマップを、参加者の皆さんにも遊んでもらう企画です。WebブラウザでSimutransを遊べるシステムを用いて、Discordで通話をしながらマップを眺めたり議論したりします。Go Liveでただマップの様子を配信する形式とは異なり、参加者は見たい箇所を自由に見ることができます。また、参加者へのpak配布は不要です。あなたのマップの魅力を全力でアピールしましょう。

なお、参加者にマップについての理解を深めてもらうため、マップを触る時間の前に、マップについて2分以内のスライド発表をすることができます。

f:id:himeshi:20210807164723p:plain

ブラウザでSimutransを遊ぶシステムのイメージ

 

応募方法

締め切り前の早めの応募にご協力をお願いいたします。

応募フォーム(共通):

forms.gle

スライド発表

10月3日(日)までに、応募フォームにお名前と発表題目を入力し、送信してください。

発表枠は1枠10分(質疑応答としてさらに5分)です。異なる題目で2枠以上の応募も可能ですが、応募多数の場合は1枠のみの発表とさせていただきます。

マップ展覧会

10月9日(土)までに、応募フォームに必要事項を記入の上、マップの動作に必要な環境一式をまとめたzipファイルをひめしに提出してください。提出いただいたファイルはマップ展覧会で用いるシステム構築のみに用い、参加者に対して配布されることはありません。OTRPv30で動作しないマップを用いる場合は、提出時にひめしにご連絡ください。

スライド発表とマップ展覧会は、両方応募いただいても構いません。

 

ご意見ご質問等ありましたらお気軽にひめしまでどうぞ。皆さまの参加をお待ちしております。

 

OTRP開発終了によせて

私,ひめしが4月より就職することをうけ,OTRPの開発を3月末で終了することにしました.OTRPの今後の扱いなどについては,下のツイート群を参照してください.

 

 

アナウンス的なお話は先のツイートで済んでいるので,この記事ではポエムっぽいことを書き連ねていこうかなと思います.

結局OTRPとは何だったのか

ひめしが欲しかったSimutrans.これに尽きます.

本家にあまり取り合ってもらえなかったので派生版として自分で自分が欲しい物を作った,というだけの話です.

OTRPの成果物に関する研究は皆さんがんばってください(丸投げ).ひめしは主にローカルマップで楽しく遊んでおります.

開発者の育成の試み

Simutransのメジャーな派生版として,Extendedがあります.ExtendedはExperimentalの時代から随分と長い間開発が続けられていますが,これは継続的に複数の人々が開発に関わっているから,というのが大きいです.

OTRPの開発を始めた当初から,私には就職というタイムリミットがある,という話は分かりきっており,この4年間,OTRPのコードをいじれる人をどうにかして作れないかと試行錯誤してきました.2017年の夏には新宿で丸一日の開発ゼミをやり,18年の年末には教科書を書き,20年にはそれをフリーアクセス化,同時にDiscordで開発ゼミも開催しました.

この試み自体が失敗に終わったのかどうかは,まだ結論には早すぎると考えています.ただ,OTRPの開発を引き継げる人を作るという観点では,完全に失敗です.

この話をTwitterに投げたところ,コードに関するドキュメントを整備してくれというご意見をいただきました.たしかに,コレコレこういう処理はここに書いてありますという日本語のドキュメントがあれば便利だとは思います.しかし,全てのクラスのドキュメントを整備することはあまりにも工数がかかりすぎ,かつコードは頻繁に変更されるので,せっかくコードに関するドキュメントを整備しても一瞬で陳腐化してしまいます.結局,ヘッダファイルをドキュメントとして読めるように書いておくのが現実的であり,現在のSimutransのコードはそのようになっています.こういったコードの読み解き方については「Simutransの本体開発」に書きましたので,ぜひお読みください.

teamhimeh.github.io

 

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がどのような形であれ今後も進歩を続け,多くのプレイヤーを魅了し続けるゲームであり続けることを心から願っています.

 

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

どうも,ひめしです.

この記事は,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をサポートするための本体開発が必要になるでしょう.

 

おわりに

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

 

路線図メーカーの使用状況データを眺めてみる

どうも,ひめしです.
いつも路線図メーカーをご利用いただきありがとうございます.

先日OTRPの使用状況ログを解析したので,路線図メーカーについても合わせて解析を行いました.

基本諸データ

  • データ集計日:2020年11月28日
  • データ収集開始:2019年12月
    2020年3月23日〜4月9日は,ログ収集用サーバーに障害が発生したため,ログ収集件数がゼロとなっています.
  • 対象本体バージョン:バージョン12以降(バージョン11は集計項目が不足しているため対象外です.)

OTRPとは異なり,MACアドレスを収集しているため,MACアドレスをもとに集計を行います.これにより,端末としての利用実態を把握できます.

累計ユーザー数

路線図メーカーは,一般的にたま〜に使うソフトウェアであるため,特定期間のアクティブユーザーではなく,累計ユーザーを第一の指標とするのが妥当です.
横軸は月(月の末日を基準としています),縦軸はその月までの累計ユーザー数です.2020年の1月から11月までを表示しています.

f:id:himeshi:20201128205938p:plain

路線図メーカーはそんなに頻繁にアップデートしているわけではないのですが,コンスタントに新しいユーザーが流入し,概ねリニアにユーザー数が増え続けているのが非常に興味深いところです.

なお,11月27日までログ収集非対応のv10_5を安定版として案内しており,そちらはDL数がv15の5倍以上あるので,実際の累計ユーザー数はこの数字の5倍程度と推測できます.OTRPのダウンロード数がせいぜい250程度で,実ユーザー数が200弱であることを考えると,路線図メーカーは実はかなり巨大なユーザーを抱えていることになります.今なお新しいユーザーが流入し続けていることを考えると,路線図を簡単に作るというニーズは実はそれなりの市場規模を持つものだったのかもしれません.

日ごとのアクティブユーザー数

f:id:himeshi:20201128210831p:plain

 先月2020年10月の,日ごとの起動端末数です.OTRPが毎日100〜130人に起動されているのに対して,路線図メーカーはせいぜい30人です.路線図メーカーはOTRPと比較して「たまに使う」ものであることがわかります.

OSの割合

f:id:himeshi:20201128211120p:plain

MACアドレスごとに,最後に稼働したときのOSを集計したものです.約86%がWindows 10上で走っているという結果になりました.Macは5%強で,レガシーなWindows OSで動かしている例も散見されます.文字が重なっているところはLinux(2件)とWindows Server 2016(1件)です.

本体バージョンの割合

f:id:himeshi:20201128211446p:plain

MACアドレスごとに,最後に稼働したときの本体バージョンを集計したものです.15系が多いですが,これは単純にリリースタイミングを反映したものだと考えられます.路線図メーカーは「たまに」使うソフトウェアですので,長い間使用せず本体もバージョンアップされないケースが多いと考えられます.

 

おわりに

こうして眺めてみると,OTRPとはだいぶ違った傾向が見れておもしろいですね.今なおコンスタントに新しいユーザーが流入していることは大変喜ばしいことです.今後とも路線図メーカーをよろしくお願いいたします.

OTRPの使用状況データを眺めてみる(10・11月)

どうも,ひめしです.
いつもOTRPをご利用いただきありがとうございます.

今年5月に使用状況データの取得を開始して半年が経ちましたが,結局ちゃんと分析することなく放置していたので,ここらで最近の動向を簡単にまとめておこうと思います.

アクティブユーザー数と起動バージョン

10月1日〜10月31日
f:id:himeshi:20201123164549p:plain

11月1日〜11月21日
f:id:himeshi:20201123164551p:plain

v28系のシェアはリリースから伸び続け,6-7割ぐらいになったところで伸び悩んでいます.v26〜v28_1は影響の大きいバグが残り続けた時期であり,その中で比較的安定したv26_5を一部のNSが使い続けていることが影響していると考えられます.

ユーザーごとのメインのpakセット

一番多く使われているpakセットをIPごとに数えました. 最近の動向を見るということで,11月のデータだけで集計するとこうなりました.

f:id:himeshi:20201123171602p:plain

NSの影響かはわかりませんが,128jp系に勢いがあるようです.前回5月に分析したときは,128jpと128無印,nipponが拮抗していたので,128jp系がココ最近になって伸びてきたと言えます.最近はアドオンもたくさん出ているようなので,実際に流行っているのでしょう.

起動時間の分布

IPアドレスごとの,1日の起動時間を集計してみました.いくつかの日にちをピックアップして傾向を見たいと思います.
起動時間1分未満は除外しています.

  • 11月11日(水)
    f:id:himeshi:20201123180933p:plain
    起動時間の中央値は2.7時間です.

  • 11月15日(日)
    f:id:himeshi:20201123180944p:plain
    起動時間の中央値は2.6時間です.

プレイヤーの数自体は平日よりも休日のほうが多いようです.あたりまえですが.
休日は起動時間3時間未満のライトユーザーの割合が増える傾向にあります.一日に5時間も6時間もSimutransするヘビーユーザーは平日も休日も区別なくシムトラ廃人しているようですw
6時間以上起動しているユーザーも一定数見られますが,これらのユーザーはプレイしていないときも起動したまま放置していると考えられます.

なお,現状話が止まっていますが,OTRPがSteamに載った時点で使用状況の収集は終了する予定です.