ゲーム制作においてどのようなバージョニングを採用すべきか
目次
ゲーム制作におけるバージョニングとは、ここではゲームにバージョン番号を振ることを言います。
こういう振り方をしましょう、という指南書が軽く探しただけでは見つからず、さてこれはいったいどうするのが標準的なのか、と疑問に思ったため筆者が調査して考えたことをまとめました。
プログラムを書かない人にも理解できるよう平易な表現を用いています。
バージョニングって何？
ゲーム（あるいはその他の制作したソフトウェア）にバージョン番号を振ることです。
例えば、（特にPCで）ゲームをする人は ver 1.00a 等の表記をどこかしらで目にしたことがあるはずです。
この記事では、そのバージョニングがどのような規則に従って行われているか、そしてどのような規則を採用したら良いのか、筆者が調査し考えたことを記述します。
バージョニングは制作者の自由
まず最初に身も蓋もない結論を言うと、バージョンの振り方は制作者の自由です。
しかしながら、全くの気まぐれでバージョン番号を上げてみたり上げなかったりしてしまうのは、わざわざバージョンを振っている意味がなくなってしまうことでしょう。
バージョンを振る目的から考え始めるのがわかりやすいかと思います。
バージョニングの目的
バージョニングは、リリースするゲーム（を始めとするソフトウェア制作物）のある時点における挙動を一意に識別するための名前付けです。
同じバージョンのプログラムは同じ環境で動作させる限り、同じ挙動をします。
（話を簡単にするためにここでは環境の差異については考慮しないものとします）
バグ報告があった時に、そのバグが確認されたバージョンと同じバージョンのプログラムを用意することで、バグの再現が比較的容易に取れるようになるのです。
手元でのバグの再現は、制作者がそのバグの原因をつかむための大いなる助けになるでしょう。
また、最新バージョンで修正済みのバグであれば、制作者は「最新バージョンに更新してね」とプレイヤーに伝えるだけで済みます。
制作者とプレイヤーのやり取りだけに注目しても、バージョンは、互いにゲームの挙動について話す際に共通の認識を持つための役割を担っているのです。
チーム開発であったり、あるいはテストプレイの協力を依頼するといった状況でも同じ役割を持つことは想像に難くないことでしょう。
バージョンは必ず上がるし下がらない
先に述べた目的に沿うため、バージョンは以下の決まりを必ず守って運用されます。
- 更新内容がどんな小さな修正であっても、ゲームがリリースされるタイミングで必ず上がる
- 最新版のバージョン番号が下がることはない
一度広くリリースされたバージョンのゲームは誰かがプレイしている可能性があります。
ですので、バージョン番号を上げずに修正を取り込んでしまうと、同じバージョンで挙動が異なるゲームが存在することになってしまうのです。
そうなってしまっては、ゲームの挙動について話す際に共通の認識を持つことができません。
「このバージョンにはバグがあるので気をつけること」と言ったプレイヤー間での注意喚起も意味を成さなくなってしまいます。
同じ理由で、最新版のバージョンが下がることはありません。
基本的にはこの二つの決まりさえ守られていれば、どんなバージョンをつけようとも制作者の自由です。
セマンティックバージョニング
自由とは言っても、具体的な決まりが定まっていたりはしないのでしょうか。
ゲームのバージョニングという観点では説明されていませんが、ソフトウェア技術者の間に（おそらく）唯一広く知られている決まりが、セマンティックバージョニングです。
これはAPIのバージョニングという観点で策定されたものであり、そのままゲームに当てはめるのはやや難しいものです。
（API = Application Programming Interfaceとは、例えばライブラリが提供してくれるメソッドの入力と出力のことです）
しかしながら、プログラムの更新には3種類あり、それぞれについてバージョンの上げ方を変えるという考え方は、ゲームにも応用できるものです。
3種類の更新とは以下のようなものです。
- 破壊的な変更がされており、後方互換性がない更新
- 後方互換性を保ちながら機能性を追加する更新
- 後方互換性を保ちながらバグを修正する更新
破壊的な変更とか、後方互換性とかいう語句は専門的なものになりますが、そう難しいものではありません。
要するに、「バージョンアップ前と同じことをした時に、同じ（ような）結果が得られるかどうか」ということです。
例えば、「△ボタンでNPCに話しかけることができたのに、バージョンアップ後は△ボタンではなく○ボタンに変更された」というのは1の破壊的な変更に含まれるでしょう。
「△ボタンでNPCに話しかけることができたが、バージョンアップ後は○ボタンでも話しかけられるように変更された」というのは2の後方互換性を保ちながら機能性を追加する更新に含まれます。
「本来は△ボタンでNPCに話しかけられるはずがそれができず、バージョンアップ後にそのバグが修正された」が3です。
セマンティックバージョニングは、これらの3種類について別々のバージョンを上げる、という決まりです。X.Y.Z のように表記し、Xはメジャーバージョン、Yがマイナーバージョン、Zがパッチバージョンです。
このX,Y,Zはそれぞれ先に述べた1,2,3の更新の種類に対応しています。
破壊的な更新があればメジャーバージョンを、後方互換性を保った機能追加であればマイナーバージョンを、後方互換性を保ったバグ修正であればパッチバージョンを上げます。
ただし先程も述べたように、これはAPIのバージョニング――すなわち、ゲームそのものというよりはゲームに使われるライブラリ等のバージョニング――として都合が良いように定められた規則です。
盲目的にこれをそのままゲームのバージョニングに採用すべき、という主張は成り立ちません。（無論、これを採用すること自体が間違いというわけでもないはずです）
例えば、PS4のゲームではマイナーバージョンとパッチバージョンを区別していません。
機能追加であってもバグ修正であっても、マイナーバージョンを上げて 1.01 等のように記述しています。
実際に採用されているバージョニング
PS4のゲームでは、 1.00 のように2つの数字でバージョンを記述しているようです。
小数点の左側がメジャーバージョン、右側がマイナーバージョンです。
PS4のシステムソフトウェアも同様に 5.03 のような記述になっています。
メジャーバージョンが2以上になったゲームを確認できていないので正確なところは定かではありませんが、おそらくはメジャーバージョンは破壊的な更新を含む場合に上がるものなのでしょう。
マイナーバージョンも最大でどこまで増えるのか不明です。
ふし幻TODRで 1.22 でした。商業作品よりも積極的にアップデートがされるplay dojinの作品でこれなので、99まで枠を用意しておけば問題ないという判断かもしれません。1.99 の後は 1.100 になるのではないかと見ていますが、そこまでたどり着く作品は現実的に想定されていないのではないかとも思います。
PCの同人ゲーとして有名所の東方シリーズは 1.00a のように、マイナーバージョンの後ろにアルファベットがついた形式になっています。
このアルファベットがパッチバージョンのような役割を果たしているのではないかと推測されます。
幻想人形演舞は 1.103 のような表記になっています。1.017 から 1.100 に更新されていたため、小数点右側の数字の上一桁がマイナーバージョン、下二桁がパッチバージョンの役割を持っているようです。
ソシャゲ等のスマホアプリはセマンティックバージョニングに従うケースが多いのですが、アズールレーンはなんと 1135 という区切りのない表記を用いていました。
どういった規則でバージョンを上げていくかはわかりませんが、ゲームとしては珍しい表記です。
FGOは 1.33.0 のようになっていたため、セマンティックバージョニングに従っているのではないかと思われます。
また、Nintendo Switchのゲームもセマンティックバージョニングと同じ表記方法でした。
どのゲームもメジャーバージョンは1で固定されており、破壊的な更新はされていないようです。
メジャーバージョンを上げてはいけない
後方互換性を無くす更新が幾度もリリースされたとすると、プレイヤーには何らかの負担が生じます。
例えば、セーブデータの後方互換性がなくなったとしたら、プレイヤーはゲームを1から始めなければいけません。
操作方法が頻繁に変更されたら、ゲームの仕様を覚えられなくなってしまうでしょう。
破壊的な更新というのはプレイヤーに多大な負担を強いることがあるのです。
そういう理由もあって、広く遊ばれているゲームはメジャーバージョンが1なのです。
メジャーバージョンが0の場合は？
セマンティックバージョニングにおいてこれは開発中で、正式にリリースされていないことを表します。
このメジャーバージョン0は特別な意味を持っており、正式リリースまでの間であればどんな更新をしてもメジャーバージョンを上げなくて良いとされています。
開発チーム内で合意の取れる方法でバージョニングすると良いでしょう。
余談：例外的なバージョニング
表記方法がセマンティックバージョニングと同じだからと言って、バージョンアップの規則まで同じとは限りません。
基本的には互換性を意識したバージョニングになっているはずですが、scalaはマイナーバージョンアップの段階でガンガン後方互換を切っているようです。
余談２：細かいテクニック
ゲームシステム中にバージョン番号を含めるのであれば、必ず一箇所に定義するようにしましょう。
複数箇所に定義するとどこかの更新が漏れて、いったいバージョンいくつなのかわからなくなる恐れがあります。
システム中に１箇所、readmeに１箇所の最多で２箇所に定義しておくくらいに留めるのが良いでしょう。
システム中の１箇所に定義するのみにして、readmeにはバージョンを書かなくても良いかもしれません。
また、ファイル名にバージョンを含めてはなりません。
ファイル名を用いたバージョン管理は邪悪ですし、windows環境において、OS側のボリュームコントロールは実行ファイルのパスに応じて記録されます。
バージョンアップしただけでボリュームコントロール設定し直し、なんて最悪ですね。
まとめ
- バージョン番号はゲームの挙動について共通の認識を持つためのもの
- セマンティックバージョニングには必ずしも従う必要はないが、後方互換性を意識してバージョニングする
- よほどのことが無い限りメジャーバージョンアップ（＝破壊的な更新）はするべきではない