himeshi’s blog

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

2024年のOTRP

この記事は、Simutrans Advent Calendar 2024 6日目の記事です。

adventar.org

本記事では昨年と同じく、OTRPの今年の動きをかんたんに振り返ってみようと思います。なお、今後やりたいと考えていることについては先日別の記事でまとめてありますのでそちらを参照してください。

himeshi.hateblo.jp

開発状況

今年はv35_2からv42_0_1まで計16回のリリースを行いました。アップデートの細かなヒストリーはGitHubのReleasesを参照していただければと思います。

github.com

追加した主な機能を箇条書きすると以下のようになります。

  • 所要時間ベース経路検索
  • 他社駅接続
  • Contributionの受け入れ
    • 編成、編成の連結の向きの反転
    • 都市の人口一覧をcsvクリップボードにコピーする機能
    • 「駅一覧」ウィンドウの並べ替えオプションの追加

実際には、一年のうち大半を所要時間ベース経路検索の開発に費やしました。いまだにたくさんの要改良点を抱えていますが、ひとまずローカルやNSでそこそこ楽しく遊べる段階にまでたどり着いたかなと思います。

所要時間ベース経路検索はパッと見るとExtendedの真似ごとをまたいきなり始めたように見えますが、思えばここに至るまでの下地はこの数年で徐々に整えられてきたのかなと考えています。ダイヤを増解結を組み合わせて所要時間的に効率的なダイヤを組むことが一般的になり、金沢版によってより優等列車に旅客を強く誘導するためのスケジュールオプションが追加されました。所要時間ベース経路検索の第一目的は「優等列車を適切に利用する安定的な経路選択」の実現ですが、この要請に直接的な手段で応えることは必然であったと思います。

一つ補足をしておくと、OTRPは引き続きRoute Cost法による経路検索をサポートし続けますし、デフォルトのオプションはRoute Cost法です。所要時間ベース経路検索はSimutransのゲーム性自体を強く変えてもはや別ゲームにしまうため、時にはRoute Cost法で、時には所要時間ベース経路検索で遊ぶという遊び方で良いと考えています。とはいえ、所要時間ベース経路検索を採用するNS鯖が今後増えていくとイチ開発者としては嬉しく思います。

OTRP利用ログ解析

例年のように月ごとのアクティブユーザ数を...と行きたかったのですが、今年はログ収集サーバを安定運用できたのが11月しかありませんでしたorz

というのも、自宅鯖の回線をJCOMからNUROに切り替えたのですが、数年前と違って昨今のNUROはv4グローバルアドレスをくれなくなりました。それどころか、MAP-Eでの限定的なポート解放すら無効化しており、サーバの公開は事実上IPv6のみになりました。正直この状況になると高い月額料金を払ってNUROを使う意味はないので、光回線を使うにしてももう少し割安なフレッツ系プロバイダで良いと思います。

IPv6ファイアウォールにしろDNSにしろIPv4とはかなり別世界なので、全く知らない世界でいろいろあれこれ試行錯誤していたのですが、結局一年の大半でログを失う結果になってしまいました。今時自宅鯖なんかやるもんじゃないですねorz

という言い訳をしつつ、直近11月の日別アクティブユーザ数のグラフです。

ユーザの識別はIPアドレスを用いています。数値言えば去年と比べておよそ半減なのですが、v4とv6ではIPアドレスまわりの事情が全く異なるのでユーザの絶対数については去年のものと比較に適しません。とはいえ、v6では1日ごとにグローバルなtemporaryアドレスを作り替えながらアクセスするクライアントが多いと思いますので、日別ユーザ数を出すにはこちらのほうが実際のトレンドに即していると考えられます。

バージョンの普及としては、KUTA版マージ前(v24 users)のバージョンはごく少数であり、所要時間ベースルーティング導入以前(v31 users)のバージョンも2割未満となっています。v36以降も経路検索のデフォルトはルートコスト法のままなので所要時間ベース経路検索の普及とは関係ないのですが、ともかく新バージョンを出すたびに皆さま素早く導入していただいているようです。ありがとうございます。

続いて、pakセット勢力図です。2024年11月のみのデータで算出しています。

ここ数年のトレンドから一気に変わって128無印が復調し再び最大勢力となりました。128無印:128jp:64系がおよそ同じ割合になる昔の状態に戻ったようです。

オフ会やネットワーキング

OTRP自体の開発や日本のSimutrans界隈の中だけではなく、今年はSimutrans界隈の外への発信や、海外とのSimutranserとの交流を行うことができました。せっかくなので今年できたことを書き残しておきます。

try! SwiftでSimutransの話をした

try! SwiftはiOSアプリ開発界隈の中でも特に著名な国際カンファレンスの一つです。今年は4月に開催され、国内外から800名(?)ほどが集まりSwift言語の技術的な話を学ぶカンファレンスなのですが、光栄なことにその1枠でお話しさせていただきました。

中身としては実際のところSimutransを題材にしたSwift - C++ interoperabilityという技術的トピックの話なのですが、題材としてのSimutransをかなり強く打ち出したので、カンファレンス後には多くの方に「Simutransの人」「交通系ゲームの人」という認識を持っていただくことができました。

youtu.be

iOSDC JapanでSimutransの布教セットを配布した

iOSDC JapanはiOS開発界隈において日本最大級の規模を持つカンファレンスです。今年は8月に開催され、私も(Simutransに関する話ではないのですが)トークをさせていただきました。

try! SwiftではSimutransの認知を高めることはできたのですが、実際に遊んでくれる人を増やすには導入障壁を取り除く必要がありました。そこで超軽量なスターターセットを用意し、それをその場でAirDrop配布することですぐに試せるようにしようと考えました。実際に会場で数名の方に興味を示していただき、その場で遊んでいただくことができました。

ちなみに先日の「やりたいこと」記事で書いたmacOSにおけるNotarization問題はこのときに発覚したものです。次にカンファレンスでスターターセット布教するときはとりあえず自腹でAppleにお布施してバイナリをNotarizeした上で布教活動をしないと、受け取ったバイナリを起動するために毎回四苦八苦することになりそうですorz

欧州のSimutranserとオフ会した

9月に欧州に渡り、イギリスとオランダを訪れました。イギリスでiOSDevUKというカンファレンスで登壇させていただいた後、オランダに行きイギリスに戻ってきたという流れです。ちなみにiOSDevUKではSimutransの布教活動をする余裕は全くありませんでしたorz

オランダでは土日にわたりドイツ人のMariculousさんとオランダ人のDanivenkさん(こちらは日本のDiscordサーバでもおなじみですね)とオフ会していただきました。特にDanivenkさんにはオランダの街をいろいろ案内していただいてアイデアをいただいただけでなく、OTRPへのcontributionに繋げることができて大変大きな収穫になったと思います。

その後ロンドンに戻り、Model Railways Clubという鉄道模型サークルの集会所でJamespettsさんとお会いしました。時間的な制約があり2時間だけでしたが、DCCという日本ではあまり見かけない方式の鉄道模型についていろいろ教えていただいたり、増解結の実装について議論をしたりしました。

今は日本にいながらでもDiscordで海外Simutranserと気軽に交流できる時代ではありますが、言語の壁は昨今の技術でどうにかなっても時差だけはどうにもなりません。その場所、その時間を共有し濃密な交流ができたことは、なかなかに得難い貴重な経験になったと思います。

おわりに

例年通り、来年どうするかは全く計画がありません。とはいえ、先日「やりたいこと」記事でも書いたように、Steamから流入するプレイヤーが増えていたり本家との互換が失われていることによる弊害が拡大していたりと、どちらかというと負債の解消系タスクをやらないといけない時期に入ってきているかなと思います。正直負債解消プロジェクトはお仕事だけでお腹いっぱいではあるのですが、もう8年もやっているプロジェクトですのでそういう苦しいことにも向き合っていかなければいよいよどうにもならなくなってきました。

ともかく、来年も界隈の皆さまとともに楽しくSimutransをできたらいいなと思います。

最後に告知です。2025年1月25日(土)に、オフラインイベント「超シムトラ井戸端会議2025」を東京、上野で開催します。イベントとしては、去年横浜で開催されたSimutransオフ会のコンテンツを大幅に強化した版です。情報の詳細、および参加申し込みは下の調整さんリンクよりご参照ください。皆さまのご参加お待ちしております。

chouseisan.com

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とオフ会をしたりしました。このあたりの話は年末のアドベントカレンダーにでも書こうと思います。

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

2023年のOTRP

この記事は、Simutrans Advent Calendar 2023 5日目の記事です。

adventar.org

本記事では昨年と同じく、OTRPの今年の動きをかんたんに振り返ってみようと思います。

開発状況

今年はv33_1からv35_1まで10回のリリースを行いました。斜めタイル停留所を実装した関係でリリース回数は多めですが、主な新機能としては斜めタイル停留所と路線間での発車枠共有の2点です。アップデートの細かなヒストリーはOTRP更新情報サイトを参照していただければと思います。

otrp-info.128-bit.net

去年の年末のノリと勢いから2023年のあけおめリリースとして実装した斜めタイル停留所でしたが、開発段階からアドオン作者の方々にアドオンの試作をしていただきました。また、機能のリリース早々に高品質なアドオンが公開されました。アドオン作者の皆様ありがとうございます。

斜めタイル停留所といえば、いつも熊谷半島の白井-西白井間の長い駅間を思い出します。この動画は2011年なので12年越しにようやく斜めタイルに駅を置けるようになったわけですが、12年前に斜めタイル停留所が実装されていたらここにも駅が置かれていたのでしょうか...

白井 - 西白井間の斜め線路(熊谷半島開発記 第13話より)

OTRPは当初から本家standardとの互換を意識しており、OTRP専用のアドオンを要する機能は一部の例外を除き開発しない方針でした。しかし年月が経つにつれてOTRPとstandardの互換は失われ、2022年にKU-TA版のマージを行ったことでstandard追従は実質不可能になりました。こうした状況を考慮し、今回OTRP専用アドオンを要する機能を解禁することにしました。斜めタイル停留所のようなOTRP専用アドオンを要する機能はSimutransコミュニティのアドオン制作リソースをstandard用とOTRP用に分散させるため、アドオン資産の有効活用という面でコミュニティに負の影響をもたらす可能性があります。したがって本家standardにも斜めタイル停留所の仕様を持って行き、アドオンだけでも両者共通で使えるようにすべきではあるのですが、斜めタイル停留所リリース後しばらくは不具合修正が続いていたこと、斜めタイル停留所機能の仕様および実装がそれなりに大きいことから本家に提案を行うに至っていないのが現状です。

新機能の話ではありませんが、長い間配布バイナリの置き場として使っていたOSDNがついに使用不能になってしまいました。ファイル自体はまだミラーサイトからダウンロードできますが、インターネット上のサービスは今回のように突然利用できなくなるリスクと隣り合わせであると改めて実感させられる出来事でした。現在、最新版のバイナリの配布自体はGitHubに移行しています。

余談ですが、v33_4はついに幻のバージョンとなってしまいました。某プロ野球チームもアレしたので、33-4ネタでいじられることも今後減っていくことでしょう...

OTRPの利用ログ解析

それでは毎年恒例のOTRPログ解析のコーナーです。まずは月毎のアクティブユーザ数です。解析は12月初頭に行っていますので、11月までの数値でお考えください。

主に今年の前半にMAUが800前後から600前後に減少しました。月毎にDAUを解析する限りでは3月下旬にDAUの減少傾向が見られるのですが、なぜこのようになったのかは不明です。ちょうど新生活が始まる時期ですので、新生活の開始とともにシムトラ漬けに日々から足を洗った層が存在していたりするのでしょうか。

なお、今回は本体バージョンを4つに分類しています。グラフ中赤色は現時点での最新版(v35_1)、緑色は斜めタイル停留所実装(v33_1)以降、オレンジ色はKU-TA版取り込み(v31)以降、青色はそれ以前の本体を利用しているユーザ数です。

直近月の11月の日毎のアクティブユーザ数も見てみましょう。DAUは80前後で安定しており、ほとんどのユーザが斜めタイル停留所実装(v33_1)以降のバージョンを利用しているようです。


最後に、OTRPユーザにおけるpakセットの利用分布をみてみましょう。最近の傾向をつかむために、今年6月以降のログを解析しています。

分類不能な割合が多いのですが、"other"のうちの半分ほどは64系のpakセットであるようです。昨年に引き続き128jpが全体の半分に迫る構図となっており、128jpの勢いを感じます。一方で64系も少し復調が見られ、128無印勢力が縮小する構図となりました。

おわりに

Simutransコミュニティに視点を移してみると、今年はコミュニティとしては元気な年だったかなと思います。ちょくちょくNSが開催されたりUlyseesさんが参加されたオフが開催されたりプレス即出しアドオンリリースが行われたりと、界隈のメンバーは変わりつつ皆さま活発に活動されているなという印象です。

来年2024年のOTRPについては例によって更新を行うか行わないか含めてまだ計画がありません。新機能の実装も良いネタがあればしたいですが、シムトランス交流会議鯖(Discord)にだいぶ不具合報告が溜まってきているのでバグ修正も適宜行えればいいなと考えています。また、近年流行している生成系AIをこれから開発フローに取り込むにあたり、どうやら自動テストの整備が重要であるらしいので、本家で既に整備されているSquirrelベースの自動テストをもとにOTRPでも自動テストを整備できればいいなと考えています。

私自身も最近は状況がめまぐるしく変化しておりなかなか先が見通せないですが、来年も界隈の皆さまとともに楽しくSimutransをできたらいいなと思います。

iOSDCでポスターセッションをしたら発表者体験が最高だった話

この記事は、iOSDC Japan 2023の参加レポートです。

iosdc.jp

軽く自己紹介

ひめしです。iOS開発のお仕事を始めてから2年半ですが、Twitter (X) を中心としたiOSコミュニティには最近顔を出し始めたばかりです。

twitter.com

ちなみに、お仕事とは全く関係ないプロジェクトとして、Simutransという交通シミュレーションゲーの日本向けforkを開発、運営しています。C++96ベースで書かれたいにしえのコードベースと日々格闘しています😇

github.com

iOSDCの参加自体は、去年に引き続き今年で2回目です。が、去年は都合がつかずオンラインでニコ生をチラ見するだけだったので、現地でガッツリ参加するのは今年が初めてでした。

今iOSDCで話したこと

今回のiOSDCでは、なんとありがたいことにポスターセッションと20分トークの2本を採択していただきました。

ポスターセッション

『大規模アプリにおいてデバイス上のユーザデータを安全に暗号化する』というタイトルで、今現在所属している会社でお仕事としてさせていただいている話を書きました。(スポンサーセッションではありません)

twitter.com

ポスターの高画質版はこちらからご覧ください。

20分トーク

 『ActorでCoreDataをスレッドから解放しよう』という題目で、Swift 5.9のCustom Actor Executorを使ってglobal actorの実行を NSManagedObjectContext.perform に縛ったらいいのでは?という話をしました。

ポスターセッションは発表者体験がかなり良いです

ようやく本題です。今回20分トークとポスターセッションをさせていただきましたが、個人的にポスターセッションは発表者としてiOSDCに参加するにはかなり良い形態だなと感じました。以下、理由を書き並べていきます。

見にきてくれる人と一人ずつじっくり交流できる

これが最大の醍醐味だと思います。iOSDCのようなカンファレンスにオフライン参加する最大の意義はやはり参加者間の交流だと思いますが、ポスターセッションを出展すると1:1での会話がとても弾むので、とてもよい交流になります。 ですので、ポスターを出したら可能な限りポスター前に常駐した方がよいです。

ニッチな内容でも伝わりやすい

レギュラートークのように大勢の聴衆の前で時間制限つきでトークをすると、ニッチな内容の場合前提知識を説明しきれず聴衆をトークの内容から置いていってしまうことがあります(私の今回の20分トークがそうでした)。 ポスターセッションの場合、基本的にポスター前に来てくれた人に1:1で説明をするので、相手の知識レベルの合わせて説明することができます。 逆に、ポスターを出してもそこに発表者が常駐せず貼ってあるだけだと、レギュラートークと同様に前提知識問題が発生することになります。ですので、ポスターを出したら可能な限りポスター前に常駐した方がよいです。

会期中ずっと主役になれる

レギュラートークやLTの場合、発表者として振る舞えるのは登壇中とせいぜいAsk the speakerぐらいです。しかし、ポスターセッションの場合ポスターの前に立てば会期中ずっと発表者として主役になれます。

会期中の居場所ができる

iOSDCのオフライン会場は非常に人口密度が高く熱気に溢れているので、ずっとその中にいると多少気疲れを起こしてしまいます。そういった場面で自分のホームポジション的なものが存在するのはとてもありがたいものです。 実は今回のiOSDCでは私の所属企業もスポンサーブースを出していたのでそこを居場所にしてもよかったのですが、弊社のブースはCode review challenge(私も出題しました)の影響で常にかなりの人だかりができていたので、自分のポスターの前をメインの居場所にしていました。

twitter.com

良いポスターをつくるために

LTがレギュラートークとだいぶ違った技術を要するように、ポスターセッションも特有のコツが必要だなと感じたので簡単に列挙しておきます。

  • 遠方(5m以上)から見たときにパッと目につくポスターにしましょう。
    • 今年のA4 10枚レイアウトだとこれがちょっとやりにくいので、運営に改善を要望しました。
  • 5秒だけポスターの前に立ち止まってくれる人に対して目の動線を提供しましょう。
  • ポスター内で説明を完結させましょう。
    • スライドとことなり、図だけポンポン並べても見る人が理解しきれないことがあります。
    • 詳細な説明は、小さいフォントサイズで書いてもOK。(近づいて見れば良いので。)

さいごに

今回のiOSDCでは、暇ができればとりあえずポスターの前に立っていました。ポスターセッションをやるのであれば、会期中可能な限りポスター前に常駐し、参加者との交流を楽しむのが良いと思います。(トークは後からでも見れますからね。)

今回は多くの方に多大なサポートをしていただき、登壇にまで漕ぎ着けることができました。感謝してもしきれません。 来年もスピーカーするぞという決意を胸に、ネタ探しの旅に出かけてきます👋

2022年のOTRP

この記事は、Simutrans Advent Calendar 2022 15日目の記事です。

adventar.org

本記事では昨年と同じく、OTRPの今年の動きをかんたんに振り返ってみようと思います。

開発状況

昨年3月をもって開発を終了したはずのOTRPですが、今年はv31 ~ v33の5回のアップデートが行われました。アップデートのヒストリーはOTRP更新情報サイトを参照していただければと思います。

otrp-info.128-bit.net

今年は、いわゆるKU-TA版(金沢版)の取り込みをv31で行いました。KU-TA版は、金沢大学・金沢工業大学鉄道愛好会によって配布されたOTRPの派生版で、OTRP v30に多数の新機能が追加実装されたものでした。昨年6月に一般公開されその後数回アップデートが行われており、KU-TA版を本体として採用するNS鯖も見受けられるようになりました。

kanazawaxpress.blog.fc2.com

KU-TA版は多くの有用な機能を有していましたが、修正が必要な不具合が複数含まれていたことも事実です。しかし、配布元は不具合修正を行う予定がない旨をアナウンスしていました。これらの不具合を修正し、より使いやすい形で日本のSimutransプレーヤーに行き渡るようにすることを目的として、OTRPをKU-TA版ベースに切り替える形で取り込むことにしました。KU-TA版の取込みおよびソースコードの提供を快諾してくださった金沢大学・金沢工業大学鉄道愛好会様には、あらためて御礼申し上げます。

来年2023年のOTRPについては、更新を行うか行わないか含めてまだ計画がありません。ただし、本家Simutrans standard nightlyの変更を取り込むことは、本家側で大規模なリファクタリングが行われたりOTRPがKU-TA版ベースになったなどの理由により、より困難になっています。ソースコードのビルド方法ですらstandardとOTRPでだいぶ差が生じてきました。

余談ですが、Simutrans 25周年企画として開発者インタビューを受けました。OTRPの開発モチベーションに関する話なども含まれていますので、まだお読みでない場合はぜひお読みください。日本語で読めます。

store.steampowered.com

OSDNのダウンロード動向

OTRPはNSに同梱されて配布されるケースも多いため、配布サイトの統計が普及の実態を表しているとは言いがたいのですが、参考までに今年一年のダウンロード数グラフを貼っておきます。

傾向としては昨年と大差なく、バージョンアップを行った日やその週末にはダウンロード数が大きく伸びるようです。また、Ribi-Arrowのダウンロード(赤線)も一日数件ながらコンスタントに見られます。Ribi-Arrowは通常バージョンアップ時に再ダウンロードすることはないため、新規さんの流入が少ないながらもコンスタントに発生していると考えてよさそうです。

OTRPの利用ログ解析

OTRPの起動ログ収集ですが、今年は運用上のミスにより下記の期間で障害およびデータの消失が発生しました。OTRPをご利用の皆さまにお詫びいたします。

  • 1月20日~2月18日 ... DNS設定不具合によるアクセス障害
  • 5月26日~8月7日 ... ハードウェア故障によるログ消失
  • 8月20日~9月15日 ... DNS設定不具合によるアクセス障害

それではまずは、今年一年間の月毎のアクティブユーザー数です。解析は12月初頭に行っていますので、11月までの数値でお考えください。

ログに障害が起きなかった月が3, 4, 10, 11月しかないのですが、この4ヶ月についてはMAUが800程度となっており、これは昨年と同程度の数字です。

データが完全である直近月の11月でも、半数弱のユーザがv30以前のKU-TA以降前バージョンを使っているように見えます。11月はv32_2のリリースがあったので、11月について日毎のアクティブユーザー数を見てみましょう。

月のはじめは半数弱がv30以前(KU-TA移行前、緑色の領域から上)でしたが、v32_2のリリースによってv30以前を使っているユーザがある程度移行しているように見えます。v29系も未だにある程度の勢力を保っています。

最後に、OTRPユーザにおけるpakセットの利用分布をみてみましょう。最近の傾向をつかむために、今回はデータの欠損がない10月以降のデータ(約2ヶ月分)のみで集計したIPアドレスベースの分布を計算してみました。

pakセット利用分布は長らく無印128:128jp:64系が1:1:1になる傾向が続いてきましたが、今年は128jp系のpakが明らかに頭一つぬける構図となりました。128jpは近年NSにおいて採用例が増えているようなので、その傾向を反映していると考えられます。一方でnippon系は勢力を縮小することになっているようです。

おわりに

OTRPは特に手を加えられることもなくこのまま陳腐化していく... と去年あたりは考えていましたが、KU-TA版の登場とその取込みによって今年もOTRPにとってなかなか楽しい年になりました。また、直近では久々にコードのコントリビューションをいただきました。

一方で、KU-TA版の取り込みと本家リポジトリとの差分拡大によって、OTRPの開発を継続する技術的な難易度はいっそう高くなってしまいました。とはいえ、Simutrans自体が非常に古い規格のC++のまま今なお開発が続けられるしぶといプロダクトですので、OTRPもなんだかんだでこの先もまだ手が入れられそうな気もしますw

Simutransのコミュニティ自体の変化も進んでいると思います。Discordサーバなどでの海外勢との交流も少しずつ進んでいますし、アクティブメンバーの入れ替わりもみられます。また、pakセットとしては128jpが大きく躍進した年でもありました。

私自身は最近は隠居ぎみですが、今年はとあるNSにプレイヤーとして参加し手植えによる景観プレイの技法を習得するなどしました。来年もローカルやNSでまったり遊ぶ人になりそうですが、界隈の盛り上がりのために少しでも貢献できたらいいなと考えていますので、よろしくお願いいたします。

2021年のOTRP

この記事は、Simutrans Advent Calendar 24日目の記事です。

adventar.org

本記事では、OTRPの今年の動きをかんたんに振り返ってみようと思います。

開発状況

今年は、3月をもって4年間のOTRP開発に終止符を打った年でした。

その後も小規模なアップデートを数回行いましたが、基本的に以下のことを行ったのみです。

  • 各種バグ修正
  • Squirrelまわりの本家追従、I/Oライブラリの追加
  • スクリプトジェネレータ(そんなものもありましたね)
  • スケジュールにおける「出発直前に積載」オプションを追加

詳しくは、以下のサイトを参照してください。

otrp-info.128-bit.net

実は就職した現在もOTRPの開発を行う時間が取れないような状態ではないのですが、どちらかというとモチベーション的な問題でしばらくOTRPの開発を再開することはないと思います。このあたりの話はまた別の機会にでもさせていただければと思います。

OSDNのダウンロード動向

OTRPはNSに同梱されて配布されるケースも多いため、配布サイトの統計が普及の実態を表しているとは言いがたいのですが、参考までに今年一年のダウンロード数グラフを貼っておきます。

f:id:himeshi:20211224000432p:plain

2021年のOTRPダウンロード数


横軸が日付、縦軸がその日のダウンロード数です。年始は数回アップデートを行ったためダウンロードが多い日がありますが、基本的に一日一桁で推移しています。特に今年11月以降はきわめて少ない数値で推移しています。一通り必要なユーザには普及しきったということでしょうか。

OTRPの利用動向

OTRPの開発はすでに終了しましたが、より実態に即した利用状況の把握を行うため、ログ収集は引き続き行っています。まずは、今年一年間の月毎のアクティブユーザー数を見ていこうと思います。

f:id:himeshi:20211221214115p:plain

月ごとのOTRPプレイヤー数

全体として大きな変動は見られませんが、7月以降は微減傾向になっていることがわかります。ちょうど6月に金沢版OTRPの配布が開始されましたので、その影響が出ているとも考えられますが、Simutransのアクティブプレイヤー数がそもそも少し落ち込んでいると考えることもできます。

なお、比較的最近の今年11月の日毎のアクティブユーザー数は次のとおりです。

f:id:himeshi:20211221205803p:plain

11月のDAU

月のはじめに落ち込みがあったのは、ログ収集サーバのDNS設定不具合によるものです。最盛期はDAUが毎日100を超えていたのでそれよりは落ちていますが、それでも80以上は毎日キープしています。

ただし、未だに半分近くのプレイヤーがv30系に移行していません。v30系では車庫表示にバグがあると報告されており、それを要因としてバージョンアップを行っていないNSが一定数存在していると聞いています。

なお、2021年のpak利用動向(ユーザーごとに最も起動回数の多かったpakを抽出)は以下のとおりでした。無印128:128jp:64系が1:1:1になる傾向はあまり変わっていないようです。

f:id:himeshi:20211221233225p:plain

pak勢力図

おわりに

今年の早い段階でOTRPの開発を終了したこともあってOTRPに関しては動きの少ない一年でした。どちらかといえばスクリプト周りの方で動きがあった年だと思いますので、ご興味がある方はぜひ下のSimutransカンファレンスの動画をご覧ください。

www.youtube.com

現在進行系でいくつかプロジェクトは進めているのですが、あまりペースは早くありません。しばらくはのんびりローカルやNSでまったり遊んで、機会があればまた面白いことができればいいかなと思っています。

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

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

 

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