数としては非常に少ないのですが、時々、「ゲームを作るためにゲームプログラミングを勉強しようとはしているんだけど、基礎から理解しようか、必要な部分だけ理解しようか迷っている」といったニュアンスのお問い合わせをいただくことがあります。これから理解しようとしているものの全容がつかめないわけですから当然の悩みかと思います。

そこで当サイトでは、基本は基礎から解説しつつ、課題を解決するためのライブラリや技術がある場合はそちらも同時に紹介するという方向で進めることに決定いたしました。「イチから作るとこうなる。この苦労を受け入れられるなら自分で作っていただければいいし、嫌なら課題を解決するためのライブラリなりを（名前だけになりそうですが）紹介するので利用を検討していただければいい」といった感じです。

中には「ゲームプログラミングでゲームを作る過程も楽しいし、基礎から知りたい」と思われる方もいらっしゃるでしょうし、基本は基礎でいいと思います。

かくいう自分も、 Win32API をどこまで勉強しようか悩んだ時期がありましたが、最近は DirectX のフレームワークがウィンドウ作成までやってくれますので、把握しておかねばなるまいと思われる範囲がだいぶ狭くなりました。

本来は移植性の高いコードを書くためのノウハウについて書かれた本ですので、当然ゲームの作り方には踏み込んでいないのですが、 DirectX と OpenGL について、ドキュメントではわからない現実の部分についての記述があって大変勉強になった１冊でした。

意外にもゲームに役立つ情報が書かれているみたいな書籍は他にもありそうです。こういった本は「ゲームプログラミング」のコーナーに並ばないでしょうし（近いところには並びますが）、みつけてまとめて紹介できると面白いかもしれません。

中古で良ければ出品者よりお求めいただけるようです。ただ、一時的に在庫ないだけの可能性もありますので要注意です。自分は一度、絶版になってしまったからと中古で購入した書籍があるのですが、リニューアルして再登場したらしく、普通に書店に並んでいるのを見たことがあります。内容は同じなんですが表紙が別物でした。こういうこともあるんですね…

実は以前、コンピューターの技術で食っていくのをやめようかと思った時期がありまして、持っている本を売りに出してしまったのです。入手できなくならないうちに買いなおそうと思って Amazon に突入です。

この本は最初に読んだ時と、ある程度わかってから読んだ時で違う面を見せてくれるのでためになります。どれだけ勉強が進んでいるかのバロメーター的な存在。

レビューで、「ソースコードの割合が多い」との意見がありましたが、自分は全部本で確認できた方がありがたい気がします（自分が書く本はページ数の関係で無理そうですが…）。

以前注文していた Windows API の本が届きました。基礎的な部分は再確認。ちょっと進んだ内容は新しく勉強することになりました。 Windows API はゲームプログラミングを目的とする場合は最低限の知識で問題ないと思いますので、最後まで読んでみて良かったら紹介させていただきます。

猫でもシリーズだったら買ってもらって損しないと思うのですが、もし OpenGL や DirectX を使われるような場合に Windows API を学ぶための専門書となると選ぶのが難しいですね（個人的には知識として知っとくってのも悪くないと思いますが）。

Objective-C を使うのか、…と最初はとまどったのですが、 OpenGL でゲームがつくれるというのがとても便利そうです。もし、仕事で iPhone アプリのゲーム開発案件が来ても絶望しなくて済むかもしれません（過去の経験上、こう思ってると来ないです）。

余談なのですが、新しい技術を学ぶ際、もやもやしている概念の一般名がわかると、一気に理解度が増すことがあります。自分も、ここ９年くらいずっともやもやしていた考え方があるのですが、一般的に「ステートマシン」と呼ばれているそうです。 Google で検索したら良い文献がたくさん出てきました。もっと早く知ってれば DirectX を勉強するのも楽だったなぁ…

「作曲入門」と銘打っても、読んでみると前提知識が必要なことが多く、文面から「～なのはご存知かと思いますが」といったニュアンスを感じてしまうことがあります。でも、本当に入門したいときは「ご存知」ではないことがほとんどかと思います。結果、 Amazon なんかでよく見る「入門できない」という評価になってしまうのかもしれません。

たとえばコード進行があります。それ以前の話なのですが、コードって思いつくだけで 100 個以上あるのです。本当の入門者は次のことがわかりません。

• 全部覚えないといけないのか？
• 暗記しないといけないのか？
• １曲中にどれだけ使わないといけないのか？
• 逆に１曲中にどれだけ使えるのか？
• どうやって使うのか？

しかしながら、だいたいケアされているのが最後のひとつだけという場合がほとんどでした（自分が読んできた本では、ですが）。この辺、面白いので興味ある方は勉強していただくと良いと思いますが、曲によってはコードを１つだけで構成することもできます。平坦な曲（さして感動もない簡単な曲というか…）で良ければ５つくらいで曲になります（その５つはキーによって変わりますが）。こういった雰囲気だけでもわかってないと読み進めにくいとあっては「入門できない」という判断になっても仕方ないのかもしれません。

今後求められるのは、こういう目に見えない不安をいくつ拾えるかなんですが、まだまだ先の長い戦いになりそうです。

唐突ですが、自分が普段思っている考えを文脈無視で述べさせていただきたいと思います。先日、作曲のレッスンにて、今後のレッスンの方向性について自分の希望を述べさせていただきましたところ、「あ、唐突ですね」と返ってまいりました。すみません、いつもこんな感じです。

考えというのはゲームプログラミングについてなのですが、自分は中身がしっかりしていれば外見はいい加減で良いと思っております（テキトーというニュアンスではなく、いわゆる「いい、加減」というやつです）。

Windows アプリケーション構築でたとえると、コアロジック部分をしっかり作れば GUI はウィザードやジェネレータが作ったもので OK みたいなところがあります。

ここで言う、「しっかりしている」とは、少なくとも現状で想定できる範囲で変更に耐えるという点です。せっかくアイデアや改められるポイントをいただいても、「あ、今の設計じゃ、それはできんわ」となってしまわないように気を遣っています。変更には SDK のバージョンアップなんかも含まれます。

現在は DirectX によるゲーム制作を考えております（というか M-Project 第一作に関しては決定しております）が、ここで変に「あとで OpenGL にも対応できるようにしよう」と考えると、私の実力では設計することができなくなります。それをやるには DirectX と OpenGL の両方に精通していることと、ゲーム開発の要件をかなり深く理解していることが求められます。

ですので、現在は「これ以降、 DirectX などの技術に依存する部分が多く出てくる」と判断した段階で、生のインタフェース（ IDirect3DDevice など）を取得して API による直接的なランタイム操作を考えています（ちょうど昨年、 yomogi さんにいただいたゲームエンジンがこうなっておりまして、リンクできるように考えました）。

「この考えが実際にうまく働くかな？」というのが今年かもしれません。

こんな Byerkut ですが、本年もよろしくお願い申し上げます。

DirectX9必携

目次を見た限りなんですが、プールとかロック、また、量子化といったサウンド関係の項目も見受けられ、速攻で注文してしまいました。コンセプトやページ数などの関係からかと思われますが、ついつい飛ばされがちな項目でしたので楽しみです。良かったら改めて紹介させていただこうと思います。

パフォーマンスの最適化 (Direct3D 9)

ただ、こういった情報は計算量が多い 3D のようなゲームを想定してのものかと思われます。１フレーム（ 1/30 くらい）中に描画するポリゴン数が 30 で 256×256 程度のテクスチャ数が５枚くらいだったら、必要になったタイミングでステートやテクスチャを切り替えて差し支えないかと思います（どうやら今のゲームがそれくらいになりそうで…）。

これを確かめるためにはページ中にある「アプリケーションのパフォーマンスを絶えずテストする」が重要だと考えているのですが、解説の途中に結論みたいなお話が出てきてちょっと面白く感じました。

一応、制作中のクラス設計に反映しております。

矩形転送というのは、それを一気にやることです。四角形で一括転送するので矩形転送という呼び方なんだと思います。

絵を表示することが目的なのに転送という表現がわかりづらいかもしれませんが、絵のデータを VRAM にコピーすることによって、そのデータを（ディスプレイなどの）ピクセルに反映するわけですので、やってることは転送なんだと思います。

DirectX でこれをやる IDirect3DDevice9::UpdateSurface() というメソッドがありまして、これを使うと「絵を画面に表示する」というゲームの基本的な機能を実現することができるのですが、どうやらアルファブレンディングができないようです（実際だめでした）。

面倒ですが、テクスチャで絵書いた方が良いかもしれません。