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

作者: 平山尚(株式会社セガ)
出版社/メーカー: 秀和システム
発売日: 2008/11/15
メディア: 単行本
購入: 112人クリック: 3,473回
この商品を含むブログ (194件) を見る

セガの新人教育から生まれたと聞いて、ざっと流し読み。

タイトルそのまんまですが、まさに「ゲームプログラマになる前に」読んでおくべき一冊。学生の頃に読みたかったと、心底思った一冊でした。

私がこの本を書こうと思ったのは、新人研修の教官をやった時に大変困ったからである。これを読んでおけ、と言える本がないのだ。この分野はこれ、あの分野はあれ、と列挙することはできるが、5冊も10冊も詰まれても新人が困ってしまうだろうし、そもそも部分の総和は全体にはならないのであって、プログラミングの本とCGの本をバラバラに読んでもゲームは作れないのである。(846ページ)

「これを読んでおけ」と言える定番になるであろう本でした。本当にありがとうございました。

日本で必要なのは内容が薄くて分厚い本だと私は考えている。雑談の合間に必要なことが書いてあるぐらいの密度の濃さでないと。1ページ進むのに三日かかる、というような事になりかねない。

さすがに、「雑談の合間に必要なこと」ではなく、「必要なことの合間に雑談」を入れて欲しいですｗ　で、この本の必要なことの合間に書いてある雑談が面白かったので、そのあたりをメモ。

「発売日から逆算すると今から絵を作らないと間に合わない。しかしこのゲームが面白くなるかどうかはまだわからない」という自体はありふれたものだが、こんな状況で作ったゲームが面白くなると一体誰が信じられるだろうか？（181ページ）

こんな感じの現場への本音がこもりすぎていると思われる文が多数出てきて、読み物としてみても面白い本でした。

画面写真のタイトルが違うのは気にしないでほしい。絵描きの趣味である。「ダイナマイト侍」にする案もあったそうだが、21世紀という時代を鑑みれば正しい選択であったと言えよう。（191ページ脚注）

私は画面写真のタイトル絵のカラーが見たくて、付属のCD-ROMを開封しました（バカ）。

裏技や隠しコマンドといったものがゲームから消えて久しいが、なんとも寂しいことだとは思わないだろうか。（208ページ脚注）

ファミコン時代（というかアセンブラで作ってた時代）って単にデバッグコマンド削るのがめんどくさかっただけなんじゃないのかと思わないこともない。簡単に隠しコマンドが入れられる時代なんだから、どんどん入れてもいいのにねー。

家庭用ゲーム機の場合はジョイスティックのチェックは更に面倒くさい仕事となる。最近は途中で差したり抜いたりもできるからだ。まして無線だったりすると、あるコントローラーが1Pなのか2Pなのかを判定するのが途端にめんどくさくなる。（242ページ）

めんどくさくなるハードもあるらしいｗ

とりわけ三角形の分割についてはちょっと前まで王者だったゲーム機がその機能を持っていなかったため、未だに分割を自力でやらねばならない状況にある人も結構いる。（379ページ）

ちょｗｗｗｗｗ　つか、据え置き機ならともかく、携帯機を入れると結構いるどころじゃ（以下略）。

脱線：コンパイルの頻度について（411ページ）

この本は「脱線」や「おまけ」と書かれているところに、割と重要な事とか考えさせられることが書いてあるからあとで見るとき困るな。本文中にも「感覚の範疇」と書かれてるけど、こういう感覚が驚くほどない人がいるんだよなぁ‥‥。まぁ、他の人から見たら私もそうなのかもしれんが。

ライブラリを分けることの欠点
まず何より面倒くさい。

元も子もない！！！ｗｗｗ

誰かが、「ライブラリに機能を足したい」と言い出したらどうすればいいか？
選択肢は二つしかない。ライブラリのソースを全部もらって勝手に改造するか、ライブラリ担当者に頼んで待つかのどちらかだ。
前者はせっかく分業したものを台無しにしてしまう選択で、いわば最後の手段である。私もたまにやるが、褒められたものではない。（446ページ）

たまにやるなよ！ｗ　しかし、規模のでかいところって、こういうのって結局どうしてるのん？というのは小規模なものしかやったことのない私には非常に興味がある。

ちなみに、私は自身がライブラリのチェックも担当することで解決しました（どーん）。ソースは全部もらう手間もなく手元にあって、機能を追加したら事後報告（最悪だ）。‥‥仕事増えただけで全然解決になってない。

ライブラリの名前は凝りすぎると正気に返った後が辛いので、適度にしておくといい。流行に乗りすぎた名前は後悔の元になるだろう。（449ページ）

そんな凝った名前つけねぇよｗｗｗ　しかし、名前は重要。超重要。

そんな私は、当時作っていたスクリプト言語もどきのテキスト形式に“Fine”、バイナリ形式に“Rain”という名前をつけていたことがある。当時、ふたご姫が放送中だったことは言うまでもない。‥‥結構、気に入っている名前なので*1、どこかでまた使おうと思っているのは内緒だ。

しかし、一旦ライブラリがある程度固まってしまえば、ゲームはそれを使うだけでよいので非常に楽になる。
もっとも、「ライブラリが固まる」などという幸せな状態は一度も見たことがないわけだが。（452ページ）

元も子もない！！！！！ｗｗｗｗｗｗｗｗ

493ページの二分探索のコード。まぁ、ゲームに使う検索で問題になることはまずないと思うけど、二分探索のバグとあわせて読みたい *2。

C++に詳しくない人は、配置newやoperator new()のことはまず知らないだろう。（515ページ）

他にも何回か placement new が玄人好みだといって紹介されてた気がする。 placement new って、C++ でゲーム作るなら割と必須だと思うんだけどなぁ。むしろ私は、ただの new 使わないで、全部 placement new にするぐらいの勢いで使ってますが少数派なのかなぁ。つか、ライブラリっぽく使いまわせるものを作るなら、アロケーターとか渡せるようにして、placement new するのが必須だろう。常考。メモリ確保する関数だけ切り出しやすくしておいて、再定義でもいいけど。

placement new と関係ないけど、どこかに実体のコピー禁止対策のがイマイチだったような気がして、あとで読もうと思っていたのに、何ページだったかわからなくなってもうた。

私は、中身がどうなっているかを知らない人にvectorを使う資格はないと考えている。さらに言えば、根本的にvectorを使う必要はないと考えている。（517ページ）

配列を使わずに、vectorを使えという、Effective C++とは間逆の主張なんだけど、私も割りと同意かなぁ。最近ようやく、Effective STLを読んで、やっぱ使いたいなぁと思う気持ちが強くなってきたけど。まぁ、STLに限らず、C/C++は危険なものと相場が決まってるからなんとも‥‥*3。

海外では「Frontend」と呼び習わしているそうだが、日本においては用語が一定しておらず非常に困る。メニュー、2D、スプライト、インターフェース、などなどあまり適切とは思えない言葉ばかりで、しかもまるで統一されていない。（578ページ）

「Frontend」に統一する。ちぃ覚えた。

脱線：試作品について（580ページ）

脱線に大切な事が書いてあるシリーズ。

それともうひとつの罠は、試作品のつもりで作ったものを捨てずにそのまま使いたくなることである。「もったいないから」「時間がないから」という理由でしばしば強行されてしまうのだが、これは確実に災いの元になる。（581ページ）

全俺が泣いた。

グラフィックスに関し「次世代」という言葉が馬鹿みたいに使われた時期があった。いろいろと試して何をやったら一番「次世代」っぽいかを探ってみたわけだが、結局は光って派手なのが一番という結論になった。「次世代＝まぶしい」である。目の肥えた玄人には通用しないが、普通の人相手であればこの原則はまだ有効であるように思う。（606ページ脚注）

馬鹿みたいにピカピカ反射したり映りこみしてるの多かったよなぁ‥‥360とPS3の出始めの頃は。さすがに、最近はそうでもなくなってきたような、そうでないような。逆にライトを以前よりは真面目に計算するようになったせいで、やたらと暗いゲームあるよな。

ここまでのサンプルは、ライティングがおかしくなっている。プログラマは気づかなくても、絵描きなら目ざとく見つけて文句を言ってくるだろう。（617ページ）

あるあるｗｗｗ

625ページ。ノードのあらわし方の二つの流派。長くなりそうなのであとで書くかもしれないし、書かないかもしれない。

例えばファイルの位置を16バイト単位ということにしてしまって、16で割った数字を格納すれば、64GBまで扱える。これで足りなくなる日はあと10年は来ないだろう。（714ページ）

ブルーレイディスクってすでに市販されているもので50GBありますがっ*4。ゲームがそんな容量になるのはカンベンして欲しいもんです。

なお、floatしか使う気が無いのであれば、考え無しに全部 f をつける癖をつけてしまうのも手である。ちなみに私はすでにそういう状態になっているため、今回は少し苦労した。この前の章までは f がつく定数は一つもないのだが、ついつい間違ってつけてしまうのである。（759ページ）

あるあるすぎるｗ　私の場合は、Ruby をやってると必ず 1.f とか書いてしまって undefined method というのをよくやらかすｗ

思わず、

class Integer
  def f; self.to_f; end
end

とかしてしまいたくなる！　やらないけど！　1.5f とか書いて syntax error になるのはすぐ気づくからいいんだけど、undefined method は、しばらく気づかないことあるから気をつけないとね！

ちなみに、私は処理落ちに悩まされずに開発を終えられた例を一つも知らない。（801ページ）

ちなみに、私はメモリあふれに悩まされることがなかった例を一つも知らない。（803ページ）

全俺が泣いた。引用の順番変わるけど

最近誤解している人が多いのだが、速いコードは常に良いのである。速いコードを書く作業に悪い印象がついて回るのは、速いコードを書くことと綺麗で保守しやすいコードを書くことがしばしば矛盾するからだ。しかしそれは速いコードそのものの罪ではない。正しい知識を身につけて日頃から訓練を積むことで、「それなりに綺麗で」「十分に速い」コードを「呼吸するように」書けるようになれば、それが最良だろう。（692ページ）