東電の退職金とかボーナスとか

確かに退職金五億円とか被災者で割っちゃえば、たいした金額にならないけど、それだけのお金があれば最前線で頑張っているJビレッジの環境が相当良くなるんじゃないかな。
ボーナスだって、ボランティアに行った人のみ支給しますとかだったら、世間からの反発はもうちょい少なくなるだろうに。

スケジュールとか

この業界の悪いところで、ギリギリまで頑張った方が素晴らしいと勘違いしている人が多いです。
確かに入ってる要素の数も重要ですが、プレイテストやバランス調整より重要な訳ではないはずです。
ギリギリまでソースコードをいじっているのは、有能な開発者ではなく、単にスケジュールを切るのに失敗した無能な開発者です。
多分東京ゲームショー前で頑張っている開発者は多いと思いますが、なんでこんなにギリギリまで作業しているのか、冷静になって考えた方が良いです。

ちいさいお姉さんが来たよ！

待に待っていた、ちいさいお姉さんの単行本が出ました！
発売したのちょっと前なのですが、体調悪くしたりで受け取るのに時間がかかってしまい、ようやく読めました。
これでいつ灯さん分が不足しても大丈夫だZE!

連載読んでる時は気にならなかったのですが、結構キャラの顔変わってますね。
特に初期の講ちゃんは目付きが怖いです。
そして同僚の紀子さんの眼力メイクが凄い。

こうやって読み返すと、作画のゆとりさんのベタ塗りが自分好みなのに気づきました。
ベルセルクや幻超二みたいな超絶黒って訳ではないのですが、なんか好きです。
とにかく、灯さんの百面相が可愛すぎて、生きるのがつらい。
本当に表情が豊かで、作者の愛が感じられていいです。

紀子さん登場の回で単行本が終わっているので、２巻はそう遠くないかも。
今から楽しみです。

ちいさいお姉さん （電撃コミックスEX　電撃4コマコレクション） [ ゆとり ]

恥ずかしい

昨日のIsoparametricさんのエントリーに対する記事は、Isoparametricさんがゲーム開発をご存じないと思い込んで書いた記事ですの、今から読まれる人はを注意してください。
私が書いたような事を当然判った上で、あのスライドを書かれています。
まさに釈迦に説法。

いやー、久しぶりに恥ずかしい思いしました。
でも、この恥ずかしい記事を書いたおかげて、DSでSTLを実用的に運用していた話が聞けたのは良かったです。
次にDSに関わることがあったら、試してみたいと思います。
とはいえ、恥ずかしいのには変わりないですけど。
クーラーつけてるのに、マジ汗が止まらない。
体温測ったら37.5℃くらいありました。
それくらい恥ずかしいです。
いやもう、穴があったら埋まりたいって、こういう事を言うんだなー。
今すごい実感しています。

C++の話（本当にあった怖い話）に反応してみる

http://d.hatena.ne.jp/Isoparametric/20100712/1278898618
id:Isoparametricさんが面白いスライドを投稿されていたので、思ったことをつらつらと書いてみたいと思います。
思った事を書いているだけなので、C++のdisを反論しているわけではありません。
私が書くのはゲーム業界のプログラマーという狭い世界で生きている人間が思った事なので、一般的なC++と思わないでください。

ディレクトリ構成が機能単位でなくプログラマの名前幽霊

これ実際に見たことあります。
アセンブラを使っていて、プロジェクトの規模が小さかった時代の名残らしいです。
その頃は、この辺りを気をつけなくてもプロジェクトのソース全体が見通せるので、あまり問題にならなかったみたいですね。
私が見たのは１5年くらい昔のプロジェクトのソースなんで、さすがに今はこんな事してるプロジェクトは見たことありません。

バージョン管理システムを使わない幽霊

昔はプロジェクトの規模が小さかったので使ってなかったですけど、うちでは10年前位から導入してますね。
ネットワークドライブはあるのですが、ネットワークはNetWare Lite使っているので、CSVとか使えないとかありましたが（笑）。
そろそろ分散バージョン管理も試してみたいのですが、昔と違ってプロジェクトの規模が大きくなっているので、動きが鈍くなってしまったので、難しいですね。

コミットは朝しろ　帰る前にするなと言う幽霊

コミットの谷間でたまたま通らないコードをコミットしたらしょうがないけど、どう見ても通らないソースをコミットして帰られたら、ムカつかないっすか？
いや、いるんですよ、マジで。
それは極端な例ですけどね。
あと、ビルド通らないなら分かりやすいのですが、不定アドレス塗りつぶしとか判りづらいバグ仕込まれたときに、本人居ないのはキツイっすよ

手動でビルドテストしなければならない幽霊

ゲームもマルチプラットフォーム化すると、自動ビルドテストは必須です。
ちなみにCEDEC2010の「タダで始めるゲーム開発自動化のススメ」というセッションで、Hudsonが紹介されます。
これからのゲーム開発には欠かせなくなりそうです。
まさに、やらなきゃHudson（定番ネタ）

オレオレコンテナしか信じない幽霊

これは難しいですね。
うちのプロジェクトはコンテナライブラリ自作してますし、EAもEA-STLというSTLに似たインターフェイスをライブラリ自作してますね。
boostやSTLってゲームには使い辛いんですよね。
例えるなら、メダカを解剖する為に自作の小型ナイフを使っている人に、中華包丁を勧める感じです。
中華包丁が便利なのはわかるけど、ゲームで使う分にはtoo muchなんですよね。
これはゲーム本体に対する話で、STLやboostを否定しているわけではなく、ツールの方ではboostもSTLもバリバリ使ってます。

C++で「よくわからんから」多重継承は禁止すべしという幽霊

禁止はやりすぎたけど、積極的には使ってほしくないですね
「C++ 設計と進化」に書かれていある「多重継承は脱出用のパラシュートである。普段はいらないが必要なときには不可欠だ」というGrady Boochの意見に賛成です。
それと、ゲーム屋しか関係なくて申し訳ないですが、__m128のようなアライン必須のメンバ変数を持つクラスが多重継承すると管理が面倒なんですよね。
設計方法によると思いますが、クラスの構造見直してテンプレートとか使うと多重継承使うの回避できることが多いので、私はあまり使った事が無いです。
なので、的はずれな事を書いていたらすいません。

C++は遅いしか言わない幽霊

確かにC++は遅くないのですが、前のエントリーにも書きましたが、遅くなる罠が埋まりやすいのが難しいんですよね。
実際にDSのタイトルでC++使ってないチームも居ました。
DSはメモリは少ないしCPUは遅いからキツイんだよねー。
と言っても、いまさらC言語だけでゲーム作れって言われても耐えられないかも。

Luaとか既存のものより優れたスクリプトを作れるとか言い出す幽霊

コルーチン最高ですよね！
あれ無しでAI組むとか、もう無理です。
ちなみに、GDC2010のLua tutorialのライオンヘッドスタジオのJonathan Shawのスライドで、FABLE1では自前のマクロで組んでいたAIを2からはLuaに変えた話があります。
あとは、スクエニでほぼSquirrelでゲーム作ったタイトルもありますし、これからのゲーム制作にLua等のスクリプト言語は必須かも。
GOALみたいな例もあるので、自作スクリプトを全否定するわけではないですが、上手く行くのはノーティドックみたいな天才のいる会社だけだと思います。

最初にも書きましたが、スライドの内容を否定しているわけではありません。
思った事を書いただけです。
スライドの56Pの盲目的に従うのはダメよ「なぜ」大事という言葉は金言だと思っていますし。

C++の見えないコスト

ちょっと古い記事ですが、C++のパフォーマンについて面白い意見が書いてあったので紹介します。
http://www.rachelslabnotes.com/2009/10/the-hidden-cost-of-c/

例えば、

a = func(b,c);

というコードは、C言語の場合はこのコードのコストは、funcの中身と関数呼び出しのコストぐらいしか無いので、非常に分かりやすいです。
しかし、C++の場合は、

• これは関数なのか、メンバ関数なのか？
• b,cにデフォルトコンストラクタはあるのか？
• オペレーターのオーバーライドはあるのか？

等、のコストがある可能性があります。
これが見えないコストです。
単体ではたいしたことないけど、このコードがループの中で呼ばれたりすると、そのコストは大変な事になるので、注意する必要がある。

しかし、これはコードを見ればわかるので、「見えない」コストではありません。
真に見えないコストなのは、このコードのコストがどれくらいなのかを調べる必要がある事なのです。

はてなスターすげぇな

id:tikani_nemuru_Mさんのエントリーのはてブにスターを付けたので、それに対してid:tikani_nemuru_Mからスターに対してのトラックバックが来ました。
そんな事出来るんですね。
はてな頑張ってるなぁ。
いや、私が情弱なだけなのかもしれませんが。

で、折角トラックバック打ってもらったので、返答しようと思います。

あのブックマーク

とはいえ事故が起きたらまず死亡するであろう飛行機に人は乗っているわけでして。

に星を付けたのは、
・個人としては、飛行機でもメルトダウンでも死ぬのは同じ。
→ならこのエントリーは個人ではなく社会全体で考えているのか？
→それなら公共の福祉はどうなる？
→他に今の日本で現実的な低炭素な安定した電力供給が原発しかない
→じゃあやっぱり個人として考えるの？
→それならやっぱり、どっちも同じじゃん
という考えでした。

その点について

「現代文明の恩恵を享受しているというだけで、結果的には原発に賛成していると同じことさ」
さて、どうかにゃ？

と、説明されているのは、自分の脳味噌が覗かれているみたいで、ドキッとしました。
偶然かもしれないけど凄いです。

で、追加で書かれたエントリーを読ませていただいたのですが、

この大規模リスクを提示されたら、生活レベルをおとしてもよいと考えるヒトはけっこう出てくるのではにゃーのか？

この点が私の想像と逆なので、やっぱり腑に落ちませんでした。
どんなに懇切丁寧に説明しても、ケツに火がつかない限り、人間は一度手に入れた生活レベルは絶対に落としませんよ。
少なくとも、今の地球温暖化対策の各個人の取り組みをみれば、想像できると思います。

それと、飛行機の例に対して

飛行機に乗るってのは、自分の意思でリスクをとっているんですよにゃ。

と書かれていますが、日本全体がアボーンする原子力発電が無いと成立しないような社会の望んだのも日本人全体ですし、リスクコミュニケーションについては、私個人の経験で申し訳ありませんが、飛行機に乗る際に墜落の確率など詳しい解説を受けたことはありません。
なので、やっぱり私にはどちらも同じに思えます。

あと、話の本筋と関係なくて申し訳ないのですが、数式について
ご自身でも
http://d.hatena.ne.jp/lever_building/20091127#c1259477039

例えば、数式は一種の記述言語であといえる。
そして、僕は数式という記述言語を上手に読み書きすることはできない。数式という記述言語を十全に読み書きできない人は、漢字が苦手な人よりはるかに多いだろう。しかし、ある種の記述をするためには、数式という記述言語は必要不可欠であることはわかる。数式という記述言語を扱えるようになるためのハードルは高いが、それゆえに数式という記述言語は有用であるともいえるわけだ。

と書かれているのに、数式を無くても説明できる話しを、ご自身が上手に読み書きできな上に難易度の高い無限をあえて使われた理由が分からないです。
無限は数学的な意味じゃなかったらしいので、それだったら最初から数式使わないほうが良いと思います。
半端な数式は、トンデモ本臭さが増しますし、モヒカン族に狙われやすいので、お勧めしないです。

リスクコミュニケーションについては、あまり真剣に考えたことが無かったので、とても勉強になりました。
書き慣れない長文を書いたので、話がまとまっていなくてすいません。
コメントで私と似た感想を書かれた、こてさんに対しての追加エントリーを書かれるそうなので、楽しみにしています。