バージョン管理運営

バージョン管理運営の仕方についてのお話です。

バージョン管理ソフト / マイルストーン / ローカライズ / 戻る

バージョン管理ソフト
バージョン管理ソフトとは、簡単に言うと、複数の人がソースや データを共有し、変更があったときにバージョン管理 (変更遍歴や昔のバージョンのソースが取り出せる) や変更点の 衝突を回避してくれるソフトです。 複数人での開発、特に仕様変更が頻繁に起こるゲーム開発においては、 必須の環境と言えるでしょう。
　
有名なバージョン管理ソフトとして、CVS, RCS, Subversion, Visual Source Safe, Alienbrain, Perforce などがありますが、 無料であることとチェックアウト等を意識しなくて良い点から、 CVS が比較的多く使われているようです (もちろん、プロジェクトや 会社によってどれを使うかはまちまちです)。 Subversion は CVS に似ていながらその問題点を解消すべく、 CVS の後継として開発されたバージョン管理ソフトです。 ソースファイルだけでなく、バイナリのデータファイル等も 扱えるようになっており、プログラマだけでなく デザイナ・企画職でも使うことができて便利なため、 今後はこちらに移行していくことになるのかもしれません。
　
CVS クライアントソフトとしては、 Windows では、WinCVS、 Tortoise Cvs などが有名です。 Subversion クライアントソフトとしては Windows では、 Tortoise SVN が有名です。
　
しかし、バージョン管理ソフトの衝突回避機能だけに頼っている だけでは不十分です。企画・デザイナがテストを行うためにも、 常に正常に実行できる環境は保っていなければならないためです。 もちろん、他のプログラマの変更で自分のコンパイルが通らなく なってしまう事態は避けないと、作業が止まってしまうためでもあります。 そこで、各プログラマは手元でソースの変更を行った後、 ゲームが正常に動作する確認をしてからアップロード (commit) するように 約束事を決めたり、そのためのツールを開発することがあります。 各自が手元に完全なソース・データを持ち、それぞれの判断で共有の レポジトリとの同期を取ります。 それぞれの持っている環境に微妙な差があり、個人的なミスが 見つけにくい欠点もありますし、個人作業となるためやりやすい利点もあります。

マイルストーン
プロジェクトを進めていくときの中間的な目安として、 α、β、Final、Master とバージョンを切って開発を進めて行きます。 それぞれのバージョンには盛り込むべき内容と期限を決め、 それを目標として開発を進め、当日にはそのゲームを CD, DVD, ROM などに「焼く」ことで区切りをつけます。 焼くことで開発中のゲームが実際の形となって残るため、 中途半端な状態にしたくないという気持ちが生まれ、 また区切りがつくことで作業の割り振りが容易になる利点があります。
　
各バージョンは大まかに言って以下のような状態を指します。
　
バージョンごとの内容
バージョン名 どんな状態
α版 仕様書に書かれている全ての要素が入っている状態。
β版 デバッグ、ゲームバランス取りが完了している状態。
Final 版 全ての仕様が実装され、デバッグされた状態。これが社外 (ゲーム機の プラットフォーマーなど) で品質チェックされ、規約に違反していた場合には、 修正が求められる。
Master 版 真の完成版。これが生産に使われる。
　
ゲームソフトは原則的に一度リリースされたら修正ができないため、 発売時にはほぼ全てのバグを潰さなければなりませんが、 その一方でゲームのクオリティを上げるためにぎりぎりまで 仕様変更を繰り返すこともします。そのため、実際のところ、 予定通りにいかないこともしばしばで、β版をβ1, β2 と数を増やしたり、 悲しいかな Master 後に大きな不具合を修正して 入れ替えるようなことも実際には行われています。

ローカライズ
国内だけでなく、世界的にゲームをリリースする場合、前もって 言葉の入れ替えなどを想定しておいたほうが良いでしょう。 単純に言葉を入れ替えるだけでも、言語によって文章量が増え (一般的に、英語は日本語の約 1.5 倍の文字数になります)、 そのために画面のレイアウトや改行位置、ウィンドゥの数が 変わることがあるためです。音声についても同様で、尺の長さが変わる 可能性があります。
　
文字の表示処理では、プログラム中に文字データを直接持つのではなく、 プログラムは ID で表示する文字を指定し、文字データファイルから 該当する文字を引き出して表示するような構造が望ましくあります。 このとき、改行や禁則処理、改ページはできるだけデータファイルと 文字表示モジュールで処理しておくことで、ローカライズの手間は 大幅に節約できます。
　
アメリカで遊べるようにするには当然英語化が、ヨーロッパで 遊べるようにするには英語、独語、仏語、伊語、西語の五国語の対応が 必要とされることが一般的です。ドイツ語などは英語に比べて さらに文字数が増える傾向にあるため、注意が必要です。
　
また、ヨーロッパの TV 画面の特性は、日本やアメリカのような NTSC とは違い、PAL (一秒間に 50 Hz で、画面の表示範囲も若干違う) と なっているため、その対応も必要とされます。

戻る