Version control for game development
ちょっと思うところがあったので脳内をできるだけそのまま書き下してみる。
VCSについてはsvn/alienbrain/git/perforceを業務レベルで扱ったことがあるので、そこそこの話をする立場にはなれてるのかなーと思ってはいる。
現状の自分の感覚としては、master/trunkを全部チェックアウトしてきたときのサイズが20GB程度までならGit、それ以上ならPerforce、というくらいのかんじ。ローカルコミットやプルリク程度ならともかく、ブランチ周りの使い勝手はGit以外のVCSではどうにも代え難い。だから、扱うデータサイズがそれなりに小さければ是非ともGitを使いたい。そうでなければ、もっとパフォーマンスの尖った仕組みが欲しい。
それはそれとして。
これは完全に自分の主観なんだけど、ゲームってやっぱり、「もうお前システムとか効率とか一切考えなくていいからおもしろさのことだけをひたすら考えてくれ」って言える相手が何人いるかで決まる世界なのかなーって思ってたりする。尖った発想を尖ったまま実現できる環境。Unityとかもわりとそういう発想よね。システム屋視点でみると結構クソなとこ多いんだけど、あれのいう「民主化」ってそういうのとは違うし。個人的には、イマドキ以降のゲーム開発には是非ともそういう方向に進んで欲しいと思ってる。プランナやデザイナやゲームプログラマ（＝フロントエンドの技術者）が、100%に近い能力を発揮できる場所になってほしい。
そういう視点でVCSを考えると、Gitは控えめに言ってクソかなと思う。あ、いや、Gitは素晴らしいソフトウェアです、間違いなく。ソフトウェアとしての善し悪しではなく着想の違いというか。本職のプログラマですらちゃんとお勉強しないと事故っちゃうくらいのカチッとしたシステムが、Gitの強みを実現しているのだという認識。
じゃあGitは駄目なのかっていうと、小中規模ならやっぱGitかなぁと。ちゃんと扱えばちゃんと動くし、何よりチーム全体でちゃんと扱えるようにするのが自分の仕事の一部でもあるわけで。けど数十人以上の大規模案件になってくるとどうしても1人2人の技術だけでフォローできる限界を超えてくるし、正直つらいかなと思う。そういうケースではお金の力でPerforceを導入するとか、いっそsvnくらいのプリミティブな仕組みに戦略的撤退を決め込むか。TAまたはパイプラインTDを含む制作インフラチームを数人規模で組めるだけの予算とマネジメントがあれば話は別なんだけど、それもなかなかね。。
だいぶ話は逸れるけど、僕自身はそういう考え方の人なので、たとえばTAについていえば、デジタル・フロンティアさんみたいな「全社横断で制作フローをみれるチームが複数の現場を（場合によっては掛け持ちしながら？）行脚する形式」というのが、個人的な理想ではある。
話を戻すと、まぁなんていうか、Gitいいよね。あれのブランチ機能は本当にすばらしい。プルリクとかをサポートしてくれる環境（githubとかbitbucketとかstashとか）がシステムとして比較的手軽に導入できるのもいい感じ。けどテキストデータに特化しすぎてるせいで、バイナリや「diffが意味を為さないデータ」を大量にを含む環境下では致命的または不当に遅いし、LFSもまだちょっと成熟度が足りない感はある。それでもソフトウェアとしてとても強いから規模によっては使い勝手が良い。そうでない環境では、速度を求めてカネを積んでPerforceにいくか、シンプルさを求めてsvnにいくか。PerforceはPerforceで慣れないうちはインフラが死ぬ思いをするんだけど、少なくともインフラが死ぬ思いをした程度のメリットが制作には降ってくる。パイプラインTAと開発環境エンジニアがそのために死ねばいい。
……ていう話をすると「それはTAの考え方だ」って言われるんだけど、ちがうんですよ、これ。技術に依って環境を変える、便利にする、直感的にする。これをプログラマの発想と呼ばずしてなんと呼ぶか、っていうねｗ
