himeshi’s blog

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

OTRPのスケジュール機能を使いこなそう

どうも,ひめしです.

 この記事はSimutrans Advent Calendar 2019の記事です.

adventar.org

 

OTRPでは,車両の運行スケジュールにいくらかの機能が追加されています.下図の点線で囲まれた部分がOTRPで追加されている機能です.

f:id:himeshi:20191109161314p:plain

追加されている機能は

  • Route Cost調整(乗車不可/降車不可/臨時系統)
  • 増解結(連結相手を待つ/連結を試みる)
  • 発車時刻指定

の3つです.今回は,これらの機能の活用例を,いくつかのシチュエーションを想定してまとめてみようと思います.それぞれの機能の使い方自体についてはOTRPのページを参照してください.

 

ケース1) 長距離寝台列車を設定する

例えば東京,品川,岡山,広島に停車する在来線寝台列車を設定すると考えましょう.このとき,ふつうにスケジュール設定して運行すると次の問題が生じます.

  • 品川→岡山のルートコストが減少(東海道新幹線のぞみで6駅のところが新設列車で1駅になる)する.これによって,不必要に岡山を経由するトラフィックが生まれる可能性がある.
  • 東京→品川はとても需要が大きい(ということにする)ので,東京駅出発直後の下り列車に品川行きの客が大量に乗る.(東京⇔品川のような短距離客は寝台列車に乗らないでほしい)
  • 品川→東京の上り列車で,品川駅から東京行きの客が乗ってくる

これらの問題は,次の対策によって解決できます.

  • この運転スケジュールを臨時系統とする.すると,旅客の経由地点検索ではこの路線(寝台列車)は考慮されず,品川→岡山の最小ルートコストは14のまま(基礎点9+6駅)になる.
  • 品川駅下りは降車禁止とする.すると,東京駅下りでは岡山,広島行きの客が優先して乗るようになる.(現時点での仕様では「上り品川駅で降りることはできる」ため,最後に品川行きの客が乗ってくる.なお,降車禁止は旅客・貨物の積載にのみ影響を与え,実際に降車を禁止するわけではないため,東京駅で乗ってきた品川行きの客は下り品川駅で降車する.)
  • 品川駅上りは乗車禁止とする.すると,品川駅上りでは一切客は乗らなくなる.

似たようなシチュエーションとして,混雑路線を高速バスで救済するときにも使いやすいと思います.

 

ケース2) 拠点駅近辺でのみ混雑するのでそこだけ輸送力増強したい

JR東の高崎線では輸送力調整のため,籠原で付属5両編成を切り離します.それと同じことをしましょうという話です.

OTRPでの増解結の設定方法自体については,↓のページで図解しています.

github.com

混雑対策をするにあたって,都心側の駅のみで混雑し逆側では空気輸送になってしまうという状況はよくあると思います.Simutransにおいてこのような状況への対応としては従来,末端各駅停車になる急行を設定して遠近分離を行うという方法がよく取られてきました.OTRPではこれに加えて,末端では短編成として途中駅から増結する方法を選択することが出来ます.

例えば,高崎線籠原駅にて上り列車は増結,下り列車は解放する場合を考えます.このとき,付属編成を親編成として先に籠原駅に入線させ,増結待ちをし,基本編成は子編成として付属編成に連結させます.スケジュールとしては,上り籠原駅のエントリで付属編成に「連結相手を待つ」,基本編成に「連結を試みる」を設定する形になります.現実の高崎線とは連結の順序が逆になりますね.(現実では高崎方の11〜15号車が付属編成として籠原で切り離されます.)

f:id:himeshi:20191201183834p:plain

上り列車(東京方面行き)での編成の位置関係の図 

付属編成を親編成として籠原駅に先に入線させるのは,都心側で折り返して下り列車となったときに遠距離客を可能な限り主編成に乗せるためです.OTRPを含むstandard系のsimutransでは,折返しをしても付属編成が先頭になることに注意してください.Simutransでは「近距離の客から」順番に「先頭車両から」乗っていきます.よって,籠原止まりの編成を先頭側にすることによって,籠原までの客が籠原止まりに乗り,基本編成のキャパシティが遠距離客に割り当てられるようになります.

 

記事執筆時点では,旅客積載は近距離の客から先頭車両から積載されるルールがあるため,高崎線のような輸送力調整のための増解結はやりやすいです.その一方,東北新幹線はやぶさ&こまちのような増解結運用はやりにくいと思います.例えばはやぶさを先頭にした場合,下り列車において東京〜盛岡間の旅客がはやぶさ側に集中することになり,盛岡以北への需要を拾うことが難しくなります.盛岡までの客がこまちに乗るのは,はやぶさが満員でこれ以上積載することができない場合のみです.

 

ケース3) 優等退避を安定してキレイにきめられるようにしたい

需要に応じて複数の種別を設定し,同じ路線の上に流すことはSimutransの醍醐味の一つです.速度差のある種別を設定すれば,途中で追い越しをかけることが必要になります.

従来,Simutransでキレイな追い越しを実現することはきわめて困難でした.キレイな追い越しのためにはパターンダイヤ化が必要不可欠です.従来,運転間隔を揃えるために下のような設備がよく使われてきました.

f:id:himeshi:20191201185750p:plain

  ここでは,まず列車を検車区(オレンジ)に入線させ,折り返して発車待機地点(水色)に移動させます.そこで1/32月待機なり1/64月待機なりをして,発車させます.発車待機地点から列車が出発した後すぐに検車区から次の列車が供給されれば,間隔は概ね一定になるという仕組みです.

しかしここには次の問題点があります.

  • 何らかの要因で発車待機地点からの発車が一度でも遅れると,その間隔乱れは回復できない.
  • 特に運行間隔が短い路線の場合,検車区の入線する線路によって発車待機地点までの移動時間に差が生じ,間隔にばらつきが生じる

OTRPやextendedで導入されている発車時刻指定機能は,「1ヶ月に何本発車させるか」を指定した上で,1ヶ月を指定された数に等分して発車させますので,こうしたばらつきを排除することができます.

正確なパターンダイヤを実現できることを利用して,所要時間を計測して緻密なダイヤを組むのは一つのやり方です.しかし,それはとても大変な作業になるのでココではもう少しラクにすることを考えましょう.基本的な方針は以下のとおりです.

  • 1複線あたりの種別数は基本的に2種別に抑え,本数比は1:1や1:2といったわかりやすいものにする.
  • 種別ごとの使用車両は統一する
  • ダイヤの構築とともに待避設備の整備も一緒に行う

この条件下で,待避設備が一切ない路線で待避設備を作りながら優等(急行)を導入する作業を想定します.以下の作業を繰り返すと,比較的かんたんにキレイなダイヤが出来上がります.

  1. 各駅停車と急行を必要な本数分流す.基本的には端の1箇所で発車時刻を指定する.この時点では急行は各停を抜けないので,急行はひたすら各停のケツをほっている.
  2. 運転間隔が指定されている場所から急行を追跡して,急行が各駅停車に追いついた場所に待避設備を作る.各停が退避するようにスケジュールを変更し,しばらく放置する.
  3. 再び急行を追跡して,各駅停車に追いついた場所に待避設備を作る.各停が退避するようにスケジュールを変更し,しばらく放置する.
  4. 急行が行程を一周するまで以上のプロセス(2・3)を繰り返す

基本的には「急行が追いついた場所に待避設備を作ればスムーズに走れる」という単純な整備方法です.路線のある1箇所以外では発車時刻を指定しないのが特徴です.しかし,地形的な制約などで待避設備を作れない場合が生じると思います.この場合は,以下の2つの対処方法があります.

  • 発車時刻指定をする駅において,発車時刻にオフセットをかける.
  • 急行が追いつくより前の場所に待避設備を設けた上で,三現示信号(Priority Signal)を使用して各停を退避させる.

OTRPはstandardベースなので三現示信号が使えます.その点で,追い越し制御に使える信号が特に存在しないextendedよりもダイヤが簡単に組みやすいのではないかと考えています.この方法であれば,駅間の所要時間を計測する必要はありませんし,Oudiaを使ってせっせとダイヤを組む必要もありません.NSなどでも十分使いやすい方法であると考えています.

 

以上,OTRPのスケジュール関連機能について,3つのユースケースを取り上げてみました.皆さんの素敵なOTRPライフの一助になれれば幸いです.

 

OTRPのバグ報告について

どうも,ひめしです.

OTRPは日々多くの皆様からバグ報告をいただいております.残念ながら全ての報告に満足に対応ができているわけではありませんが,皆様のバグ報告は確実にOTRPの品質向上に役立たせていただいております.

近ごろ,「バグ報告をしたいけど何を投げればいいのかよくわからない」という声をいただきますので,バグ報告として投げていただきたいものを開発者目線から嬉しい順に列挙していきます.ご自身のできる範囲で情報を投げていただけると幸いです.

 

1) バグを修正するプルリクエス

GitHub上のteamhimeh/simutransのOTRPブランチ向けにバグ修正のプルリクエストを投げていただけると泣いて喜びます.

github.com

 

2) バックトレース(クラッシュする系のバグの場合)

クラッシュする系のバグの場合,gdbやlldbなどといったデバッガなどで得られるバックトレースを投げていただけると,クラッシュの原因となったコードが直接わかりますので大変助かります.

なお,最近のOTRPの実行ファイルは容量削減のためデバッグ情報を削減しています.意味のあるバックトレースを得るためには,ソースコードデバッグ情報つきでコンパイル(config.defaultのDEBUGを1以上にする)してからデバッガで実行する必要があることに注意してください.「デバッガの使い方はわかるけどコンパイルするの面倒」という場合には,私にお声がけいただければデバッグ情報付きの本体をコンパイルしてお渡しします.

 

3) バグを再現するセーブデータの提出

ここからは開発の知識がなくてもできる報告手段です.

バグ修正にはまずバグを再現しなければなりません.そこで,以下の仕様を満たすセーブデータを作成し,提出いただけると,速やかにバグの調査に入ることができます.

  • セーブデータを開いたら画面内に当該不具合が即時(もしくは数秒後に)発生するようにする.
  • 本家無印pak128を用いてマップを作る.(特別に必要な場合をのぞき,追加のアドオンは用いないでください.)
  • 不具合と関係ない車両などはマップ中に配置しない.

ある特定のマップでのみバグの発症が見られる場合(バグを再現するデータを新たに作成することが困難な場合),simutransフォルダ一式(pakやsaveデータ,configなど全てが含まれている状態)をzipなどで固めてご提供いただいても構いません.

 

4) できる限りバグの発生条件を特定し,文章やスクリーンショットで説明する

バグの発生条件はできるだけ詳細に説明してください.最低限,

  • 使用しているOTRPのバージョン
  • どのような不具合が発生しているのか
  • その不具合はいつ発生するのか

を説明してください.

 

バグ報告は2019年11月現在,twitter(@himeshi_hob),Discord(simutrans_japan),GitHubのissue(https://github.com/teamhimeh/simutrans/issues)で承っております.皆様のご協力をお願いいたします.

OTRPの跡継ぎをしてくださる方へ

どうも,ひめしです.

先日のシムトラ学会 in 東京 にて,OTRPの運営の跡継ぎを募集するという話をしました.これは,私が学生生活を終えてしまうとOTRPに継続的に関われる見込みが立っていないことによるものです.

OTRPの運営を継いでいただくといっても,OTRPの運営とはなんぞやという話になると思います.本記事ではあとを継いでくださる方々に向けて,OTRPが今後も派生版として生きていくために必要な作業を説明します.OTRPそのものの運営・開発方針などについては別の記事にまとめてありますので,そちらを読んでください.

himeshi.hateblo.jp

以下,必要な作業を優先度順に並べておきます.

① 本家nightlyへの追従(必須)

OTRPはリリース毎に本家nightlyへの追従を行っています.いくらOTRPが素晴らしい機能を持っていたとしても,本家nightlyより大幅に古いコードをベースにしていては使い物にならなくなります.また,OTRPは本家standardとの完全な互換性を一つの方針としており,そのためには本家nightlyに追従することが必須です.

追従作業は,gitを用いて本家のmasterブランチをOTRPブランチにマージするだけです.8割がたはconflictせずに終わりますが,マージ時にconflictが発生した場合は人力で解決することが必要です.人力でconflictを解決する作業は,それなりにコードへの理解を必要とします.また,conflictが発生しなくてもコードの意味的には壊れている場合がありますので,マージする本家のコミットを大雑把に把握しておくことは必要です.

マージ作業は定期的に行うことが望ましいです.少なくとも2ヶ月間隔で行うと良いと思います.本家stable版の更新に合わせて追従とかいうことをやると,差分が多すぎて手に負えなくなります.

 

② 本家フォーラムにOTRPの機能を持っていく

OTRPと本家nightlyのコード差分が大きいと,追従作業でconflictが発生する可能性が高まり,作業の大きな負担になります.OTRPは本来,本家に受け入れられない機能の受け皿ですが,本家に受け入れられるかもしれないのに本家フォーラムに持って行ってない機能があります(範囲建設ツールなど).OTRPの機能を少しずつ本家に持っていって統合してもらうことで,本家とOTRPの差分が小さくなり管理がしやすくなるだけでなく,OTRP(発祥)の機能をより多くのユーザーに触ってもらうことが可能になります.

 

③ 日本のプレイヤーの要望をOTRPに反映する

せっかくなのでOTRPをこれからも日本向け機能の受け皿として使っていただけたらうれしいです.

 

本家追従さえしていただければOTRPはレガシーとして生き続けることはできます.私の界隈からの引退がOTRPの喪失にならない未来が拓ければ,とてもうれしいです.

OTRPの運営方針について

どうも、ひめしです。

OTRPの運営(?)方針について尋ねられることが多くなってきましたので、自分の思考の整理も兼ねてここに書き残しておきます。

OTRPの方針はその起源から来るものも多いので、OTRPの起源あたりからつらつらと書いていこうと思います。

【1/9更新】本家フォーラムへの投稿について文面を変更しました。standard統合を目指す予定のない機能は本家フォーラムに投稿する必要はなく、OTRPのみにプルリクエストできます。

 

OTRPのはじまり

もともとは「二車線パッチ」として道路での二車線走行機能を実現すべくパッチを本家フォーラムに投げ始めたのが始まりです。動作確認のために本家フォーラムに貼っていた実行ファイルを日本のユーザーにも紹介したのが始まりでした。

その後本家フォーラムで「二車線パッチ」について議論を重ねましたが、主に私のコーディング技術が未熟だったことが原因で本家統合の見通しが立たなくなりました。そのままプロジェクトは終わるところでしたが、二車線パッチをこよなく愛してくださる方々がいらっしゃいましたので、2017年11月に独立を宣言し、私家版Simutransとして専用配布ページをオープンしました。

二車線パッチ時代から開発を進めるにつれて要求仕様が膨らみ、本来の二車線走行以外の付随機能も載せるようになっていきました。本家統合を放棄し独立したことで、二車線走行関連機能以外も実装し搭載するようになっていきます。日本人プレイヤーが好む「乱開発フレンドリー」な機能をそれなりのスピードで実装していったことで、OTRPはおかげさまで日本を中心にユーザー規模が拡大しています。

 

OTRPの役割

OTRPは、いろいろな事情でSimutrans Standardに組み込めない機能を受け入れるエディションです。

ですので、standardに組み込まれて然るべき機能がOTRPのみに搭載されているという状態を私はあまり良しとしていません。本家で議論が止まってしまった、そもそもstandardにはふさわしくないなどといったパッチを受け入れるというのがOTRPの立ち位置だと私は考えています。

ただし現実は、standardに入りうるのにOTRPのみになっている機能も少なからずあります。これは単に私がきちんとstandardに持っていくのをサボっているだけですので、2019年はこれらの機能も少しずつ本家に持っていくことを計画しています。

 

「OTRPについての議論の場」について

近頃OTRPに興味をお持ちの方が増えた上に、OTRPにプルリクエストを投げてくださる方も増えようとしています。議論がすぐ流れてしまうTwitterではなく、OTRPのための議論の場が欲しいという声は理解できます。

しかし、先に述べたようにOTRPはstandardに組み込むことができない機能を受け入れる場ですので、OTRPの為の機能の議論をする場を設けることはあまり適切だと考えていません。作るべきなのは「standard系(extended向けではない)の本体議論をする場」です。これについてはTwitterなり日本語フォーラムなり本家フォーラムなり既存インフラがそれなりにあります。

なおpull requestを投げてくださる開発者様とのやり取りは、基本的にGitHub上で行うこととしています。Twitter上での議論でも構いません。

 

OTRPの開発原則

去年の夏にも同じ話は書きましたが、再掲しておきます。

  • アップデート時は常にsimutrans standard nightlyに追従する。あくまでもstandardの拡張版であり、本家でされた改良、バグ修正の恩恵をプレイヤーが確実に受け取れるようにする。アップデートで必ずnightlyに追従することで本家の変更をmergeすることが困難になるのを防ぐ。
  • 独自アドオンを要求する機能は搭載しない。standard用のアドオンがあればそれで完結する設計にする。ただでさえ64, 128, extended用のpakとフィールドが分かれているsimutransのアドオン界隈において、OTRP独自の規格を設けてもうまくいくはずがないからである。
  • セーブデータの互換性を確保する。いつ何時も、standardのセーブデータは必ずOTRPで読み込めるようにする。standardのセーブデータを読み込んだときは、OTRPで開いたときにはstandardと全く同じ挙動をするようにする。(つまりOTRPはただのstandardとしても使える。)OTRPのセーブデータもOTRP独自の機能まわりを犠牲にすればstandardで読み込む手段を提供する。
  • UIの互換性に配慮する。standardからOTRPに乗り換えてきた人にとって、OTRPの機能について何も知らなくてもstandardとして遊ぶ分には困らないようにする。プレイヤーはOTRPの機能について少しずつ探求することができる。(extendedは始める前にある程度extended独自のゲームシステムについての知識がないと不自由する傾向にある。)

要するにOTRPがstandardの完全上位互換として使えるようにするということです。今のところRibi-Arrow以外についてはこの原則を守って開発しているつもりです。

 

OTRP統合の依頼について

OTRPに統合してほしい機能がある場合は、teamhimeh/simutransのOTRPブランチにプルリクエストしてください。先に上げた「OTRPの開発原則」に反することがない限りは、基本的に受け入れる用意があります。

ただし、standardに統合する予定のある機能に関しては、まず一度本家に投げることをお願いしています。これは専らメンテナンス上の都合によるもので、ある単一機能について本家リポジトリとOTRPリポジトリとで不必要な差分が生じることを防ぐための措置です。

ある機能についてstandard統合を目指すのか、OTRP専用に提供するかは開発者の自由です。standardに統合させる予定のない機能については最初からOTRPにプルリクしていただいて結構です。また、開発した機能をさっさと日本のユーザーに届けたいのであれば、本家フォーラムへの投稿とOTRPへのプルリクを同時にしていただいてもかまいません。皆さまのプルリクエストを心よりお待ちしております。

なお、OTRPはリリースごとに原則として本家リポジトリに追従しますので、standardに統合されればその機能は必ずOTRPユーザーにも届きます。

standardベースで開発するかOTRPベースで開発するか

OTRP固有の機能に密接に結びついた内容でない限りは、standardベースのコードで開発することをオススメします。standardとOTRPのコード差分はそこまで大きくないので、standardベースで開発したブランチをOTRPベースのブランチにmergeしてもあまりconflictしないはずです。

セーブデータの読み書きはstandardとOTRPでバージョン管理が異なるので注意してください。もしわからなければstandard向けのままプルリクしていただいてもかまいません。

 

機能の実装依頼について

私への機能の実装依頼はどのような形でしていただいてもかまいません。ですが、実装するかどうかは私の心の琴線に触れたかどうか次第です。

多くの皆さまにとってあまり現実的な話ではないことは承知しておりますが、ある機能がSimutransに載るための最速ルートは自分で実装してしまうことです。一人でも多くの方がこのルートを取れるように、私はこれまでパッチゼミをしたり本体開発本を書いたりとそれなりに活動してきたつもりです。

それはさておき、皆さまのご意見やご要望をいただくことは私のSimutrans本体開発活動の原動力の一つです。皆さまの声すべてにお応えすることはなかなか難しいですが、今後もぜひご意見ご要望をお寄せいただき本体開発を(コードを書かずとも)一緒に楽しんでいただければなと思います。

 

2019年の本体開発活動について

昨年はずいぶんたくさん実装をした覚えがありますが、今年はCities: Skylinesに手を出そうかななどと考えているので開発ペースは落ちると思います。

現時点で私がやりたいと思っている主なトピックは以下のとおりです。

  • 増解結
  • 範囲建設系ツールをOTRPからstandardに持っていく

それでは今年もよろしくお願いいたします。

C95日本シムトラ学会大盛況のお礼とBOOTH通販開始のお知らせ

どうも、ひめしです。

C95の2日目で出展しました「日本シムトラ学会」では大変多くの皆さまにおこしいただき、新刊もたくさんご購入いただきました。おかげさまで出品した7品のうち自由町を除く全てが完売(自由町も終了時点で在庫僅少)しました。ありがとうございました。

 今回私はコミケ初参加(サークル参加はおろか一般参加も経験無し)でした。右も左も分からない私を準備段階から支えてくださり、当日も巧みなトークでたくさん人集めをしていただいたMARKさん、ポスター作りをお手伝いいただき会計作業をがんばってくださったふぃすたむさん、そして、私が今回頒布した本体開発本の作成に多大なサポートを頂いたshingoushoriさんに、今一度お礼を申し上げたく思います。

 

夏コミ(C96)出展について

今回大盛況に終わった日本シムトラ学会ですが、私が次の夏コミでサークルを主催する予定は今のところありません。

個人的にはシムトラ同人誌頒布の機会は年一回くらいがちょうどいいのかなと思っています。シムトラ学会も2017年は3回もありましたが2018年は一回でしたので、まぁそのぐらいの頻度がちょうどいいのでしょう。とか言って年一回の申込みで落選してしまったらorzなのですが。

申込書は会場で購入し手元にありますので、シムトラ関連でC96に出展したいという方には喜んでお譲りします。ご興味をお持ちの方はtwitter @himeshi_hobに連絡をお願いします。

 

『Simutransの本体開発』の再販について

今回弊サークルで出品しました新刊のうち、ひめし著『Simutransの本体開発』と、ふぃすたむさん著『Simutrans-Extended 信号保安システム入門』は午前中に完売してしまい、午後にブースにいらっしゃった皆さまに頒布することができませんでした。そこで、『Simutransの本体開発』についてはBOOTHにて通販することとしました。

himeshi.booth.pm

本自体の価格はコミケと同じ1000円ですが、送料が上乗せされることをご容赦ください。手元の在庫がゼロなのと、年末年始で印刷所が休みなので、発送開始は2019年1月14日を予定しています。

なお、この通販に関しては2019年1月中のみ実施予定です。2月アタマには一旦店じまいする予定ですので、ご希望の方はお早めにご注文ください。

2018年版 みんなが欲しいアドオン・機能

どうも、ひめしです。おかげさまでSimutrans Advent Calendar 2018は大盛況のうちに幕を閉じることができました。記事を投稿してくださった皆さま、お読みいただいた皆さま、ありがとうございます。

adventar.org

 

今年で二回目のアドベントカレンダーですが、実はこんな企画をやっていました。

【アドオンをリクエストしようキャンペーン】
エントリーされた皆さま、記事の中に「今自分が欲しいアドオン」を書いてみましょう! 

というわけで、皆さまからいただいたアドオンリクエストを以下に列挙します。特記なき場合は主にpak128無印のアドオン需要です。

車両

建築物

  • 奥行きの長さが半分の箱積み
  • 中小規模の駅舎
  • 市内建築の公園、博物館、文化施設など
  • 「緑」な公園アドオン
  • コンテナホーム・ホッパ・フォークリフト・トラックヤードなどの貨物駅セット
  • 果樹園(田んぼや茶畑以外に農地が欲しい)
  • 商店街のアーケード
  • 温泉宿
  • 繁華街歓楽街のにぎやかなビル

軌道や架線

  • 架線柱2マスおき設置に対応したwayobj
  • diagonalで道路を2つ並べたときに真ん中を埋めるアドオン(中央分離帯やダミーの車線など)
  • SIS新幹線軌道の新描画位置対応版
  • OTRPで使いやすい大交差点対応道路信号(pak64系だと釘ニさんのアドオンが良い例です。)

本体の機能

  • 路線ごとの営業最高速度
  • 路線ごとに運賃n倍プッシュ(ルート検索でも考慮)
  • groundobjで雨を降らせる(雨雲がかかってるところを薄暗くするなど)
  • 土土地の上げ下げを,レールとかでCtrlと組み合わせるときれいな直線が引ける,適な機能

 

アドオン職人の皆さん、仕事の時間ですよ!

 

【1/1追記】

peing.net

ここにリストアップされたアドオンについて質問箱に配布先を書いてくださった方がいらっしゃいました。

『Simutransの本体開発』を書いて

この記事はSimutrans Advent Calendar 24日目の記事として書かれたものです。

adventar.org

私、ひめしはこの度Simutrans本体開発初の教科書『Simutransの本体開発』を執筆し、頒布させていただいております。環境構築から始まり、シムトラ本体開発の基礎知識の解説、そして本体改造の実践演習と、ゼロからある程度本体改造を楽しめるようになるまで一通りカバーしたつもりです。

 12月8日にはありす様主催のSimutrans学会in京都にて初回頒布をさせていただきました。おかげさまで売上部数22部を記録し、増刷をさせていただくまでになりました。ご購入いただきました皆さま、ありがとうございます。次回の頒布は冬コミ二日目です。ぜひいらしてください。 

さて、本自体はシムトラ本体開発の教科書として閉じた形にしたかったので、あまり余計なことは書きませんでした。(ページ数が増えて価格が上昇するのを避けたかったというのもありますが。)この記事では、本にまつわる与太話をつらつらと書いていきたいと思います。

 

本を書き始めた動機

本のあとがきのところには「去年のパッチゼミで教科書が必要と感じた」とか書きましたが、実際のところこの本を執筆したのは完全に院試勉強の現実逃避ですorz

院試(大学院修士課程の入学試験のこと)は8月末でしたので7月アタマぐらいから院試のための勉強を始めたのですが、いかんせん身が入りませんでした。院試が終われば卒論の中間発表なるものを提出することになっていましたので、「気分転換にTeXの練習でもするか」とおもむろにTeXのセットアップを始めたわけです。

このときふざけて本体開発本の序論的なものを書いてみたのですが、そこでスイッチが入ってしまいアレヨアレヨと筆が進み始めてしまいました。

 とはいえこのときはただ現実逃避のために本を書いていたので、どこで頒布するとかいう話はとくに考えていませんでした。ちょうどこの時期にC94(夏コミ)があったのですが、それもあって「次の冬コミに出せ」というお声をいただくようになります。

コミケ出展どころかコミケに行ったことさえない私は躊躇していましたが、MARKさんからトドメの一言が。

 そしてついに退路を自ら断ってしまったわけです(

 ありすさんによるシムトラ京都学会のアナウンスもあったので、京都学会に間に合うように執筆をするということがこの時決まりました。

 

 全然別の話になりますが、本体開発本を書いたのは私がいつSimutransの活動から離れても良いようにしたいからという理由もあります。私がSimutransを始めてから8年が経ちましたが、この間にずいぶんと界隈の人が入れ替わりました。あれだけ精力的に動画を上げていたうp主さんが、あれだけすばらしいアドオンを量産していた作者さんが突然失踪することはごく当たり前に起こることです。

アドオンであれ本体改造であれ、作者が引退すると、その制作物は程度の差はあれど使えなくなっていきます。緩急坂の導入によって古い軌道系アドオンは事実上使えなくなりました。本体のパッチの場合、本家のコードの変化に追従させないと、パッチを統合することさえすぐに困難になります。アドオンやパッチが継続的に使えるようにするには、「誰か」がメンテナンスを担う必要があります。この点で、アドオンや本体パッチの製作技術を次の世代に伝えることは重要なのです。

技術を次の世代に伝えることの重要性を私が痛感した一つのできごとは、俗にいうSISショックです。SISプロジェクトの構成メンバーの方々がいろいろな事情によりアドオン制作の第一線から引退され、多くのアドオンが「死に絶えた」というべき状況になりました。SISの後継を担うアドオンは私が知る限り未だ登場していません。作者が引退すると制作物が死を迎えるというのはあまりにも悲しいと私は思うのです。

アドオン制作の場合、その制作プロセスの全てをオープンにすることはあまり一般的ではなく、オープンにしようとしても簡単ではありません(それでも最近はAdvent Calendarなどを通じてアドオン制作ノウハウを公開する方が増えており、大変喜ばしいことです)。しかし、本体開発の場合はソースコードが成果物であり、原典です。ソースコードを読み、その意味を理解し、コードを書くことでアルゴリズムを表現する術を得れば、誰でも思うように開発をすることができます。ですから、『Simutransの本体開発』では、ソースコードの読み方を解説し、実践演習を通じてコードの書き方も習得できるようにしたのです。

私はまだ学生の身分です。いつSimutransの世界からバッタリ消えることになるかは自分でもわかりません。しかし、作ったものは当分そこに残ります。このとき、本体開発を嗜む日本人が少しでもいれば、メンテナンスがされなくなり死に絶えていく運命にある遺産を蘇らせることができるわけです。未来のSimutrans本体開発を担う人の育成に、今回執筆した本が少しでも役立つことができればとても嬉しいです。

 

書くペースとか

8月上旬から書きあげた本ですが、ページ数だけで言えば8月の終わりには8割以上紙を埋めていました。あとから知ったのですが、最初に一気にかきあげると本は完成にこぎつけやすいそうです(要出典)。9・10月はほぼ筆を進めず、11月に残りの2割を書きつつ、既に書いた部分の修正を重ねていきました。

書く内容に困ることはありませんでした。2017年にやった本体パッチゼミの内容をそのまま本に書き下すだけだったからです。(もちろん本の内容はパッチゼミよりも大幅に充実させました。)

特に技術書的なモノの場合、本を誰かに添削してもらうというのは大変有効だと思います。今回の本ではshingoushoriさんに文体・内容の両面から添削をしていただきました。

 

これから本を書く人へ

これからシムトラ系同人誌を書こうとする人にむけていくつか書き残しておこうと思います。

本を書き始めるときにまず最初にすべきことは、頒布イベントへの申込みです。というのも、コミケなどの大型イベントになるとイベントの3〜6ヶ月前というかなり早い段階で参加申し込みが締め切られます。シムトラ系だと主たるイベントはやはりコミケ、ということになると思いますので、本を書くなら12・1月中に決断すべきです。

イベントに申し込むとやる気に満ち溢れると思います。そのまま全体の8割ぐらいはページを埋めてしまいましょう。締切ドリブンな書き方は締切直前の時期に忙しくなってしまうとアウトなので、スタートダッシュでほぼ全部埋めてあとは修正をするだけという状態にまでしてしまうのが良いと思います。それでも締切直前は慌ただしくなるものですが。

本を有償で頒布する場合、気をつけなければならないことは権利関係です。これについてはMARKさん(自由町というシムトラ入門本を執筆なさっています)が12/8のシムトラ学会でわかりやすく説明されていました。一度は確認してアタマに入れておいたほうが良いと思います。(下の動画の5:30あたりから権利関係の話がはじまります。)

www.youtube.com

 

おわりに

『Simutransの本体開発』の次回の頒布はC95(冬コミ)二日目(日曜日)東ホールT-06b「日本シムトラ学会」にて行います。頒布価格は一冊1000円です。新刊5品、既刊2品の計7品を用意してお待ちしております。ぜひおこしください。

 

ネット通販はコミケ頒布であまった分だけやります。コミケで売り切れる可能性も無くはないです。入手したい方はコミケ来場をオススメします。どうしても入手したい方でコミケ来場が物理的に困難な場合はひめしにご連絡ください。

 京都学会で本をお買い上げいただいた方へ、このたびは本をご購入いただきありがとうございました。本体開発とどのように関わるかは各人の自由ですし、本をどのように扱うかもまた各人の自由です。しかし、せっかく本を手にとっていただいたので、ただ文章を眺めるだけではなく、ぜひ演習をこなして本体開発を習得していただけると著者として大変嬉しいです。

 

ほしいアドオン

アドベントカレンダーのキャンペーンでほしいアドオンを挙げようというのをやっておりますので私も書いておきます。私が欲しいのは基本的にpak128無印版のアドオンです。

車両系... TOQ2000・6000系(Qシートも)、都営浅草線5500系、シティーカーアドオン(バラエティ豊かな日本車をたくさん走らせたい)

インフラ系... SIS新幹線軌道の新描画位置対応版、OTRPで使いやすい大交差点対応道路信号(pak64系だと釘ニさんのアドオンが良い例です。)