ゲームプログラマになる前に覚えておきたい技術 届きました

在庫切れから入荷してamazonから届きました。

ゲームプログラマになる前に覚えておきたい技術

すらすら前に進めるように書いてあるとはいえやっぱり知らなきゃいけないこと多いよね・・・。
C++はグロいし。
さらに速度にも（他に比べたら）敏感にならないといけない分野だし。（だからグロいC++で書かないといけないんだろうけど）

O(N^2)でN=100あたりから怪しいっていってるあたり1フレーム16ms内に全部終わらせなきゃいけない(多分半分くらいは描画だけで飛んでく)世界と1s(=1000ms)くらい以内に全部終わらせなきゃいけないアルゴリズムプログラミングコンテストの世界とにギャップを感じます(自分はプログラミングコンテストはメインではないということにしてたのに(笑))。
メモリキャッシュによって15倍もの速度差が出たというのは恐ろしいことです。大きなデータはなるべく配列、みたいな感覚で書いてはいたけど。

本書でも何度も触れられていたけど多分ここから一番のクセモノはnewだなと思いました。書かれていたとおりマニアックではあるものの、placement newが一番いいように思えた・・・。なんて言語だよもう・・・。

そうだなあ、これだけの分量があってまだ増やせなんて言えないけれども

• デストラクタによる生成・破棄コードの分離の防止

いわゆるこれです

Object *p = new SomeObject();
//...
if(error){
    // delete p;
    // throw | return -1;
}
//...
delete p;

エラー時のメモリリークです。特筆すべきはこれをきちんと書くとしても面倒で、読みにくくなることです。保守性も下がります。(pの他にqもrもあってしかも間にいろいろコードが挟まっているとしてください)(ポインタ変数を最初に全部0(NULL)初期化しておいてdelete 0;が何もしないのを利用するとほんの少しましになるけどエラーの度に何行ものコードをコピペとか残念すぎますね)
こういう間に何か挟まるのは必ず全てデストラクタを利用してスコープを外れるときに自動で実行されるようにすればかなり良いコードになると思います。
終了処理は全てデストラクタとし、ポインタは全てスマートポインタで包むという方針はかなり良いものだと信じています。
Windows用ゲームだけじゃなくて家庭用ゲーム機なども視野に入れた考えがあるからboost::shared_ptrは出せないのかなあ・・・。C++0xで標準に入るっていうしあんまり容易に外部ライブラリに頼れない人々にも救いの手を・・・。
auto_ptrはゴミです。

• 例外

ゲームってほとんどの場合なんらかのエラーが起きたらもはや続行不能ということが多く、どこからでもポイポイ投げていちばん外側でcatch仕掛けておくだけでも結構いけそうに思う。返り値と違っていいところはエラーをそのまま外に流したいときは何も書かなくていいこと。悪いところは解放系のC++のごちゃごちゃ（例外安全性）。

• カプセル化・継承・ポリモーフィズムの活用

結局つまりはシーンクラスとかのことなんだけど

char *str = "baka";
char str[] = "baka";

この違いがわかってない場合、高確率でカプセル化や継承はともかくポリモーフィズムがわかってない（本当か！？）。
多分大きいプロジェクトになると変数の管理がごちゃごちゃになって詰まる。ゲームプログラミングはフレームごとに関数が呼ばれる性質上（マイクロスレッドでもない限り）変数が１段階グローバルなスコープに流出しやすいからそれをなんとか軽減しない限りバグの嵐に見舞われる。いや、その前にどこをどう編集していいか分からなくなってプロジェクトがストップする。無理やり前進しようとすると自体はさらに悪化する（書いてて嫌になってきた）。だからといってそれを説明してそういうコードを自分で書けるようにするのは至難だけどね！！

とにもかくにもまずは2Dゲームを作りたいっていうのなら半分弱の3Dの章はすっとばすことを許すとして、とりあえずこの本を渡せばOKな素晴らしい本です(そういう本を目指しているし)。これを諦めるなら諦めてもらい、マスターしたならかなりいけるようになっているでしょう。そして、まだ足りない(笑)。ここで挙げた設計指針みたいなのもあるし、本書の最後の方で紹介されている、シェーダ・AIとかも必要に応じて。あとスクリプト言語(コンパイラ論)もあるね。スレッドの恐ろしさをしっかり伝えているのもよかった。私も使うとしても同期をほぼ使わない（データのやりとりはスレッドが動く前にパラメータを設定し、スレッドが終了してから結果を得る）設計をします。
読んでいるうちに現在のC++言語やゲームプログラミング自体の問題点に自然と気づく（であろう）点が素晴らしい。

ただひたすら思いついたことを書いたため口調が変わったりだとかいろいろはある程度はご容赦を。
あとゲーム開発の現場で働いてたりしないので注意。会社で働いてすらいないので。数値計算をしたい物理科学者がCを超えてオブジェクト指向を学ぶ必要はないと思います。
あと''かなり''適当に流して読んだので思いっきり書いてあったことを再要求しているかもしれません（オイオイオイオイ）。

追記：
思い出した。
STLですら処理系によって怪しいことがよくあるんだった・・・。家庭用ゲーム機向けCPUのC++処理系ってどうなってんだろうなあ・・・。C++・・・！C++処理系はどんなことがあっても絶対に作らないと心に決めたことがありました。