今週月曜日から修行が始まりました。
新しい環境にビクビクしながらもなんとか一週間を終える。。。。。

今回の制作はC/C++での開発。
AndroidでのJavaやiPhoneでのobjective-C、
UnityでC#、
WindowsでのC/C++など、勉強はしていたものの現場でのコンシューマー機によるC/C++は世界が違った…！！

今回はこの業界でのベテランの方の下で仕事をするので
あらかじめその方が用意していたフレームワークの上での開発ですが、それでも難しい。


今回の修行ではそのフレームワークの作り方、コンシューマー機での考え方を学習します。


今週一週間で学習したのは
・テンプレートの多用には要注意、STL、boostとかは使わないほうが無難
テンプレートを多用した開発は失敗に終わる、デスマの原因になる可能性が非常に高いらしいです。
もちろん使って便利な部分もあるけれど、という付け足しの上で。
土台を作るには便利だが、それ以外の場面で使わないほうが良い、特にゲーム部分の実装では。

・クラスの関係はシンプルに
多重継承をしまくったり、継承関係が複雑になりすぎると追いづらいのであまりオススメはしないと言われました。


・実装内容はなるべく隠蔽化
ヘッダーに記述する内容が多いと、後の仕様変更に対応しづらくなっていく（わけではないけど面倒になっていく）そうです。
ヘッダーにはできる限り公開する内容のみを記述し、隠蔽する内容はソースに記述。
この関係からクラスをソースに直接記述するのが非常に多いようです。



・システムは汎用化せずに、利用用途は開発者にわかりやすいように、そして変更しやすいように。
例えば というような記述をすることによって、そこに引数を指定するだけでその色に変更できるという関数であったとします。
しかしこれを何千回も書く可能性もあるし、色変更するにあたって仕様が変わればすべてに変更をかけなければいけない。
非常に大変なので
というような感じで「どういう内容なのか」が開発者には明確で、
フェードカラーが255,255,255→240,240,240のように変更されるとしても一箇所をかきかえるだけで良い。
つまり引数を指定せずに「そいつを呼べばそいつの内容が実行される」ようにすること

というふうに教わりました。
(まぁこれはいろいろな場所で使うことを考えれば最終的にこう考えて当然とも言えますが…)
ただ、ここで一点教わったのは「汎用化してもどうせ汎用されない、決まった使われ方しかされないことが多い」ということ、
ここで変にこだわるのはプログラマーのマスターベーションに過ぎず、そういうことは日曜プログラマーでやってなさい、
というアドバイスをいただきました。


・宗教にはこだわらない
まぁこれは言うまでもなく。


・マクロはうまい感じに使う。
ヘッダーにはなるべくマクロは記述しないほうが良いと言われました。
さらに言うのであれば、ソース部分の限定的な使い方をしたほうが良い、とも。
defineしたら必ず使用後にundefする、
ローカル変数と同じように一時的にしか利用しないものは、最後にちゃんと片付ける。そうすればバグは起きない
上手に使えば恐れるものではないが、あまり多用しようと考えないように、とも言われました。



まぁこんな感じです。
「お客さんが納得のいくものを作るのが第一なのであってプログラムを書く事はその過程に過ぎない」
「お客さんはプログラムのことなんてわからないし、技術的な説明をしたってわからない。それなのに技術的に拘るのは愚策である」
「時間は有限でそれまでに完成品を用意しなければいけない」
「コンシューマーはPCのように莫大なメモリもないし、OSと言えるほどのものでもない。当然PCと同じ感覚では動かない」
「コンシューマーでのアプリ部分で発生し得るバグ、エラーはすべて開発者の責任である」


AndroidやiPhone、はたまたWindowsなんかはどれもOSなので、
そこでの開発しかしていなかった人間にとっては未知の世界とも言えます。


ベテランの方のアドバイスをしっかり聞くことができる今の間に、
昔の人のやらかしたミスや失敗談を取り入れながらも今後も学んでいければいいですね。



ではでは

せんちゃ さんが書きました: ただ、ここで一点教わったのは「汎用化してもどうせ汎用されない、決まった使われ方しかされないことが多い」ということ、
ここで変にこだわるのはプログラマーのマスターベーションに過ぎず、そういうことは日曜プログラマーでやってなさい、
というアドバイスをいただきました。

あるあるですねｗ
可変長テンプレート引数とか使って無駄に汎用化ﾜｰｲヽ('∀`)ノとか。

STLも使わないとなると面倒が増えそうな気もするのですが、
C++の機能を使うというよりはBetter C的な位置づけなんでしょうかね。

これはかなり参考になります。
仕様を汎用化しない、はたしかに重要ですねφ(.. )

標準ライブラリが標準なのはPCだけですからね。
ブログとかでコード公開するとSTLやboostを使わないことを必ず突っ込まれるのが面倒臭いです。

ゲームプログラムはコードをいじらずにテーブルデータやスクリプトデータでキャラなど制御することが多いので、そもそもキャラ単位とか細かくサブクラスを作ったりしないんですよね。
ネットにはさもサブクラスをたくさん作るのが当たり前のようにばかり書かれてますが。

私の経験だと関数で必ず想定外の使い方をするのでパラメータにはチェックをします。
例えばＲＧＢなので0から２５５なのに関数の引数に違う値が入る可能性は十分にあります。
なのでデバッグビルド時はチェックして範囲外アサートさせて、リリース時はそれなりの安全値になるようにガードさせる事をしてました。
まぁ、会社などでルールは違うと思います。

カロさん
そうですね、
Cよりの書き方をしながらC++をいじるような感じなのでBetterCと言えなくもないと思いますが、基本的な機能はC++の機能が多いと思います。
C++的な書き方をする必要のない部分（例えば入力パッドやカメラなど）はゲーム内で一つしか存在し得ない情報なのでインスタンス化したりする必要はなく、
かといってシングルトンにすると毎回getInstance()を呼ばなきゃいけないとか面倒くさくなるので、そういうのはじゃあグローバル関数にしましょうか。
といったようなノリです。

STLはやはりプログラムサイズが爆発的に増えるというのが使われない一番の原因かもしれません。
採用しているプロジェクトもあるようですが、僕の会社では「危ない橋渡るくらいなら最初から無難な方を選ぼうぜ！」って感じです。
おそらくこれは新人でよく使い方がわからない人でも危ないことにならないようにするための配慮なのかなと考えています。

涼雅 さん
あくまでもゲーム業界の一部分の人間の意見なので参考になるかはわかりません^^;
この業界の中でもある種の宗教論の話になってしまう部分も多いとおもうので…

ISLeさん
普段当たり前だと思っていた世界がコンシューマー開発だと当たり前ではない、というような違和感がまだあったりします^^;
傍からは見れば車輪の再発明にも思われそうですが、最終的にはこういったシステムを作っていかなきゃいけないんだなぁと。。。

ソフト屋さん
パラメーターチェックのASSERTとかはたくさんこちらにも入っていますね、
大体がプリプロセッサでデバッグ時とリリース時で挙動が変わるようになっているようです。

ゲーム業界内でも作り方や設計の仕方に関してはまだまだ議論が多そうに感じます

ちょっと気になったのですが、「汎用化しない」というのは「汎用のまま使わない(特殊化して使え)」というのが正確じゃないですかね。
fade_whiteやfade_blackの中からfade(r,g,b)を呼ぶ形がより良いと思いますが。
仕様変更に対しても、softyaさんがおっしゃっているチェック機構を入れるのにも効率が良いです。

汎用化の意味自体を図りかねるのですが、フレームワークを作る側としては構造化は必須だと思います。
フレームワークを作る側と使う側の視点がごっちゃになっているのも気になりますね。

わたしが趣味で作ったフレームワークを仕事で使ったら、いつのまにか本人の知らないところで会社標準になって、開発効率がかなり良くなったりするような現場があるのは事実です。
というか、下請けばっかりですが、いままで行った現場はけっこうそうでした。
日曜プログラマのマスターベーションの3倍4倍時間かけてそれでも品質の悪いコード書いてる現場は少なくないと思いますね。
日曜にやれというのは裏を返せば開発スケジュールに余裕がないということですから。

ISLeさん
「汎用化しない」はそうですね、話したときは仰るとおりの感じです。
「内部でfade(r,g,b)を作ってそれを利用したfade_whiteなどの関数を作成し、そちらを公開する」
という考え方なら問題ないけど、と教わりました。
なので土台を作るときはシステム的な部分なので当然汎用性も高く、だれでもすぐに使えるレベルまで作られていると思います。
実際のところ、テンプレートはあまり使わないほうが良い、とは言われましたがフレームワーク部分にはアロケータやファンクタ、
StringクラスなどSTLとほぼ同等のものをテンプレートを使って作成していたのを見ています。

そういったタスクフレームワークが出来上がった上で、トリッキーな処理は記述するな、という考え方だと思われますね。