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に持っていく
それでは今年もよろしくお願いいたします。